1. 13 Oct, 2017 1 commit
  2. 26 Sep, 2017 1 commit
  3. 03 May, 2016 1 commit
    • Julius Werner's avatar
      cros_ec: Change EC interface to be fully object-oriented · 3c697995
      Julius Werner authored
      
      
      Depthcharge's current cros_ec code doesn't really match the
      object-oriented one-instance-per-device design of its other drivers.
      Instead, it is a singleton design with hardcoded support for only up to
      one additional chip by passing devidx=1 to certain functions. In
      addition, the vboot callback implementations for EC software sync are
      tightly interwoven with the cros_ec driver.
      
      This patch changes that code to be more in line with depthcharge's other
      drivers. EC and PD chips are represented as separate objects (sharing
      the same bus object), and the connection to vboot callbacks is
      abstracted in a VbootEcOps superclass. This is intended to make it
      easier to hook up other embedded controllers that don't run the Chrome
      EC embedded OS to vboot's software sync mechanism, such as the ANX7688
      used on Elm. (This is intended to be the first step. We may or may not
      decide that it makes sense to also make changes to vboot code and the
      callback interface later.)
      
      Also try to clean up namespacing a bit (cros_ec_... only for exported
      functions), only export functions that are really needed by other files,
      and remove some unused code.
      
      BUG=chrome-os-partner:52434
      TEST=FAFT on Oak. Manually triggered software sync both after cold
      reboot and when the EC was already in RW.
      
      Change-Id: I6666c4382ef40d1211995101c97a52346963fa4a
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/341542
      
      Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      3c697995
  4. 08 Mar, 2016 1 commit
  5. 26 Feb, 2016 1 commit
  6. 18 Dec, 2015 1 commit
  7. 28 Aug, 2015 1 commit
  8. 27 Aug, 2015 1 commit
  9. 21 Aug, 2015 1 commit
  10. 13 Jun, 2015 1 commit
  11. 27 May, 2015 1 commit
  12. 11 Feb, 2015 1 commit
  13. 16 Dec, 2014 1 commit
  14. 30 Aug, 2014 1 commit
    • Julius Werner's avatar
      net: Enable all USB dongle drivers unconditionally · 7e11da67
      Julius Werner authored
      
      
      Like all drivers, USB dongles currently need to be activated in the
      defconfig. This repeatedly causes issues because drivers are forgotten
      when creating or merging a new board.
      
      There is no good reason to ever not activate these options: since they
      are USB devices, any dongle can be connected to a port on any board, so
      every board with USB support (which is all of them by definition, even
      in the latest ChromeOS Core design docs) will want to have them.
      
      BUG=None
      TEST=Compiled on Blaze, confirmed that dev images still had ASIX and
      SMSC driver code in the binary, and normal images still hadn't.
      
      Change-Id: Ic98b042e37e5adc1e598328481b671b5861f17ba
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/215498
      
      Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      7e11da67
  15. 26 Aug, 2014 2 commits
  16. 09 Aug, 2014 1 commit
  17. 12 Nov, 2013 1 commit
  18. 04 Oct, 2013 1 commit
  19. 23 Jul, 2013 2 commits
    • Gabe Black's avatar
      flash: spi: Restructure the drivers. · d5e9febe
      Gabe Black authored
      
      
      Separate the Exynos SPI driver from the flash drivers. The ICH drivers are
      still flash drivers since they can't really be used for anything else, and
      there's now a flash driver which calls into an underlying SPI driver for the
      actual bus transactions.
      
      The ICH flash, memory mapped flash, SPI flash, and exynos SPI drivers are now
      all organized as structures of function pointers who's parameters are set when
      structure is set up.
      
      Also, the interface to SPI drivers is more in line with what's provided by the
      hardware, so the code in the exynos SPI driver needed to be redistributed. In
      the process the transfer function can now send, receive, or both, and it
      decides whether to use 4 byte packets or not based on whether the total size
      divides evenly by 4.
      
      To keep the SPI bus running with 4 byte packets when loading from flash, the
      SPI flash wrapper rounds the region being requested outward (start down, end
      up) to ensure that the size is a multiple of 4 and you're getting at least the
      data you're asking for. Ideally the driver would keep track of what it's
      already loaded and not load it again, but that's not implemented as of now.
      
      BUG=chrome-os-partner:19420
      TEST=Built for all platforms except bolt. Booted on snow with the exynos SPI
      driver, on Link with the memory mapped flash driver and also the ICH SPI flash
      driver, booted RW on Link, and booted on Lumpy.
      BRANCH=None
      
      Change-Id: Ib0348bd468896a569288d3ca2dfca534569195b9
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit.chromium.org/gerrit/62537
      
      Reviewed-by: default avatarDavid Hendricks <dhendrix@chromium.org>
      Commit-Queue: Gabe Black <gabeblack@chromium.org>
      Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      d5e9febe
    • Gabe Black's avatar
      EC: Rename anything called mkbp cros_ec if it's not keyboard related. · cb4e0579
      Gabe Black authored
      
      
      The term MKBP actually refers to the keyboard protocol implemented by the
      ChromeOS EC, but it ended up being used for all ChromeOS EC related bits.
      
      BUG=chrome-os-partner:19420
      TEST=Built for all supported boards.
      BRANCH=None
      
      Change-Id: Ic275fc3ce990695c6da0a0329911b3f79fcb7cde
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit.chromium.org/gerrit/62080
      
      Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      Commit-Queue: Gabe Black <gabeblack@chromium.org>
      cb4e0579
  20. 09 Jul, 2013 1 commit
    • Gabe Black's avatar
      Add board specific directories/files. · 8979e082
      Gabe Black authored
      
      
      The idea is that the board.c in each of these directories will have an init
      func in it which will instantiate and interconnect driver instances which fit
      with that particular board. That will make things more flexible for drivers,
      and avoid having to have hacks and board specifics wedged into drivers to
      support specific boards.
      
      For instance, on snow, one of the I2C busses is shared with the EC, and is
      arbitrated using a request/grant pair of GPIOs. Instead of having the driver
      know about that arbitration mechanism and which bus it goes with and which
      GPIOs to use, the GPIOs could be instantiated as instances of the exynos GPIO
      driver, the I2C driver can drive the most busses directly, and a wrapper which
      handles the arbitration can be implemented which is called into by the device
      driver on the I2C bus and which, after arbitration, then calls into the
      generic driver.
      
      Another example would be if there are two different types of I2C busses like
      on both Exynos chips. There actually are two types of busses on both those
      chips, but we've been able to ignore that by either turning off one type, or
      only attaching devices to one type. If we can't or don't want to work around
      the problem any more, we could implement drivers for both types of controller
      and then pass the right instance to the right driver for the devices on those
      busses.
      
      BUG=None
      TEST=Built for all supported boards. Booted on Link.
      BRANCH=None
      
      Change-Id: I349ebf4df1fc8d5763aa7d49fd70c85cc333c9f3
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit.chromium.org/gerrit/60983
      
      Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      Commit-Queue: Gabe Black <gabeblack@chromium.org>
      Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      8979e082
  21. 28 Jun, 2013 1 commit
  22. 23 May, 2013 1 commit
  23. 30 Apr, 2013 1 commit
  24. 14 Mar, 2013 1 commit
    • Gabe Black's avatar
      Modularize setting up data for crossystem. · 04430a2d
      Gabe Black authored
      
      
      Setting up the crossystem data isn't always necessary, and exactly how it
      works can vary from system to system.
      
      BUG=chrome-os-partner:16688
      TEST=Built and booted on Link and ran crossystem to verify that the data
      looked reasonable.
      BRANCH=None
      
      Change-Id: I3e56573f901c7d5c5d15f1a02ab154fbed1ba0fb
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      04430a2d
  25. 07 Mar, 2013 1 commit
  26. 26 Feb, 2013 1 commit
    • Gabe Black's avatar
      depthcharge: Generalize and redistribute timekeeping code. · a99b8f4d
      Gabe Black authored
      
      
      The timekeeping code in libpayload was dependent on rdtsc, and when it was
      split up by arch, that code was duplicated even though it was mostly the same.
      This change factors out actually reading the count from the timer and the
      speed of the timer and puts the definitions of ndelay, udelay, mdelay and
      delay into generic code. Then, in x86, the timer_hz and timer_get_raw_value
      functions which used to be in depthcharge were moved over to libpayload's
      arch/x86/timer.c. In ARM where there isn't a single, canonical timer, those
      functions are omitted with the intention that they'll be implemented by a
      specific timer driver chosen elsewhere.
      
      BUG=chrome-os-partner:17340
      BUG=chrome-os-partner:17334
      TEST=Built and booted depthcharge on Link and Daisy.
      BRANCH=None
      
      CQ-DEPEND=CL:*32858
      
      Change-Id: If1b18658deb9fffd38c70920e2b16f8e184e410d
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32894
      
      Reviewed-by: default avatarStefan Reinauer <reinauer@google.com>
      a99b8f4d
  27. 21 Feb, 2013 2 commits
  28. 12 Feb, 2013 2 commits
    • Gabe Black's avatar
      depthcharge: Hook the FMAP code into the new flash driver interface. · 715d6bbe
      Gabe Black authored
      
      
      Now initialize the FMAP code on demand as well.
      
      BUG=chrome-os-partner:16683
      TEST=Built and booted on Link.
      BRANCH=None
      
      Change-Id: I39526c17bfad0070ff08886d32790ee347ddad82
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32361
      
      Reviewed-by: default avatarRonald G. Minnich <rminnich@google.com>
      715d6bbe
    • Gabe Black's avatar
      depthcharge: Create a "driver" interface for accessing flash contents. · dabe2d42
      Gabe Black authored
      
      
      On our x86 systems flash is memory mapped which makes it convenient to get to.
      Because it's so convenient, there hasn't been a need for a more formal
      interface to get at data stored there, you just had to compute a pointer and
      grab what you wanted.
      
      To support systems without memory mapped flash, and to facilitate better
      performance if using the programmer interface directly is faster, this change
      creates an interface which abstracts out exactly how flash is read or where
      the contents are stored.
      
      The new interface supports a single function, flash_read, which takes the
      offset into the flash and a size and returns a pointer to the requested data
      in memory. If the flash is memory mapped, the "driver" is just computing the
      pointer which points to the data you want and tells you to access it in
      place. If the driver actually goes out and reads the flash, it should put the
      data into a buffer which will act as a cache and return a pointer to that.
      
      A memory mapped flash driver and a dummy driver are provided as well.
      
      BUG=chrome-os-partner:16683
      TEST=With this and other changes, moved over to using this interface to access
      flash. Built and booted on Link, built for Daisy, Lumpy and Haswell.
      BRANCH=None
      
      Change-Id: I455ea6edca3987b38fbb9580286158e8272f5391
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32350
      
      Reviewed-by: default avatarRonald G. Minnich <rminnich@google.com>
      dabe2d42
  29. 06 Feb, 2013 2 commits
  30. 30 Jan, 2013 1 commit
    • Gabe Black's avatar
      depthcharge: Make ps/2 keyboard and USB input selectable drivers. · 83791c0c
      Gabe Black authored
      
      
      ARM systems generally won't have a PS/2 compatible keyboard controller, so
      we need to be able to disable support for them. While we're at it, make the
      USB keyboard input selectable as well. There will need to be an MKBP adapter
      driver at some point too.
      
      BUG=chrome-os-partner:17340
      TEST=Built for Haswell and Lumpy. Built for Daisy and saw some linker errors
      go away. Built and booted on Link and verified that local and USB keyboard
      input still work.
      BRANCH=None
      
      Change-Id: I4e2517b648e55473696279f99842fb54b8498be9
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/31661
      83791c0c
  31. 29 Jan, 2013 4 commits
  32. 08 Dec, 2012 1 commit