1. 13 Oct, 2017 1 commit
  2. 26 Sep, 2017 1 commit
  3. 19 Aug, 2017 1 commit
  4. 24 Jun, 2017 1 commit
  5. 20 Jun, 2017 1 commit
  6. 26 May, 2016 1 commit
  7. 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
  8. 24 Mar, 2016 1 commit
  9. 21 Mar, 2016 1 commit
  10. 04 Feb, 2016 1 commit
    • Naveen Krishna Chatradhi's avatar
      Kunimitsu/Lars: Workaround for silego unable to see EC reset · ac2b89a9
      Naveen Krishna Chatradhi authored
      On skylake boards the silego chip is unable to see EC resets and
      clear the latch on EC_IN_RW state.  This means that FAFT is unable
      to switch to developer mode because VbExTrustEC() will always fail.
      
      This only matters for FAFT because entering recovery mode with the
      keyboard still works properly and this VbExTrustEC() callback is
      only ever used in the developer mode transition screen.
      
      As such, use the existing FAFT override GBB flag that is used for
      similar workarounds in the firmware to enable FAFT testing.
      
      This is a bit messy, using an overridden flag to check at runtime,
      because GBB flags are not available in the board_setup() function
      as they have not been read yet and due to the structure of RO/RW
      depthcharge it is not convenient to change that behavior.
      
      This is a port for Kunimitsu and lars boards following CL for
      https://chromium-review.googlesource.com/#/c/319245/
      
      
      
      BUG=chrome-os-partner:47648
      BRANCH=none
      TEST=manual testing (in additon to FAFT)
      1) set GBB flag 0x300
      2) enter recovery mode with: dut-control power_state:rec
      3) press Ctrl+D on keyboard to transition to developer mode
      4) also verify that when the GBB flag is not set that if the
      EC is in RW and steps 2-3 are executed that it does not allow
      entry into developer mode
      5) also verify that keyboard controlled recovery mode does clear
      the EC_IN_RW flag properly and does not need GBB flag to be set.
      
      Change-Id: Icd120cbff4d19b51f193c5ed9c40ec3098820f5e
      Signed-off-by: default avatarNaveen Krishna Chatradhi <naveenkrishna.ch@intel.com>
      Reviewed-on: https://chromium-review.googlesource.com/319208
      
      
      Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
      Tested-by: default avatarDivagar Mohandass <divagar.mohandass@intel.com>
      Reviewed-by: default avatarDuncan Laurie <dlaurie@chromium.org>
      ac2b89a9
  11. 13 Jan, 2016 1 commit
  12. 03 Dec, 2015 1 commit
  13. 09 Oct, 2015 1 commit
  14. 10 Sep, 2015 1 commit
  15. 27 Aug, 2015 2 commits
  16. 21 Aug, 2015 1 commit
  17. 14 Aug, 2015 1 commit
  18. 27 May, 2015 1 commit
  19. 04 Apr, 2015 1 commit
  20. 11 Mar, 2015 1 commit
  21. 11 Feb, 2015 1 commit
  22. 02 Dec, 2014 1 commit
    • Julius Werner's avatar
      sysinfo: Allow GPIOs to be passed from coreboot to depthcharge · 139dc0e2
      Julius Werner authored
      
      
      We have always had a 'port' field in struct cb_gpio that contains some
      kind of platform specific description of the GPIO, but until now we have
      never made use of it. Instead, depthcharge just relies on the values
      coreboot read and pretends they never change. For some GPIOs (especially
      those which aren't actually GPIOs anymore like the dev switch), this
      behavior makes sense... but for others like the power button, it
      absolutely doesn't. In these cases depthcharge boards always had to
      override the flag manually with another flag_replace() after
      sysinfo_install_flags(), which is easy to forget. In addition, these
      GPIOs often like to change with board revisions, requiring developers to
      not only specify them twice (in coreboot and depthcharge) but also
      remember to apply all changes on new board revisions to both
      repositories.
      
      This patch redesigns the sysinfo GPIO API. Boards can now pass a
      platform-specific converter function that can create a depthcharge
      GPIO from the description passed in the coreboot table. It
      implements exemplary support for the new feature on Tegra- and
      Rockchip-based boards, while all others will still work the old way
      (emitting a warning). Over time, all current platforms should change to
      the new model and redundant GPIO definitions should become a thing of
      the past. (Also fix rush_ryu's explicit use of the sysinfo GPIO API to
      work with the new functions, and implement a stopgap wrapper for Storm.
      It's not yet possible to add full support to Storm since the Qualcomm
      drivers don't support the basic depthcharge GPIO API.)
      
      CQ-DEPEND=CL:231222
      BRANCH=None
      BUG=None
      TEST=Booted on Veyron_Pinky, Nyan_Blaze and Falco. Made sure that the
      power button shuts the system down from depthcharge. Compiled for Storm
      and Rush_Ryu.
      
      Change-Id: I532ff1e5cb0912bd2c0764deedd8448ae81023d0
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/231250
      
      
      Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      139dc0e2
  23. 23 Jan, 2014 1 commit
  24. 22 Jan, 2014 1 commit
  25. 04 Dec, 2013 1 commit
  26. 20 Sep, 2013 2 commits
  27. 11 Sep, 2013 1 commit
  28. 04 Sep, 2013 2 commits
    • Gabe Black's avatar
      storage: Simplify the storage driver interface. · c180e947
      Gabe Black authored
      
      
      Instead of having an init callback and a refresh callback, there is now an
      update call back which is called if need_update is set to 1. Controllers that
      have fixed media attached to them will set need_update when their drivers are
      initially set up and clear it after the first update. Controllers that might
      have removable media attached will leave need_update turned on. Both will call
      their own init function when necessary, probably the first time update is
      called.
      
      Also, to avoid initializing controllers which aren't attached to the types of
      media we're concerned with, the single block_dev_controller list is split into
      two lists, one for controllers that have fixed media and one for those that
      could have removable media. The lists are not mutually exclusive, and the
      same mechanism which determines when to initialize the controller on a single
      list will prevent a controller for being initialized for each list it occurs
      on.
      
      BUG=None
      TEST=Built for all boards. Built and booted from emmc and sd card on snow and
      pit. Booted from ahci and usb on link. Booted from USB on kirby.
      BRANCH=None
      
      Change-Id: I134c207c61fa553a759bd54dcacbf5d93efb12e4
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://chromium-review.googlesource.com/168044
      
      
      Reviewed-by: default avatarron minnich <rminnich@chromium.org>
      Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      Commit-Queue: Gabe Black <gabeblack@chromium.org>
      c180e947
    • Gabe Black's avatar
      Storage: Change the storage drivers to use structures of function pointers. · cf805fb9
      Gabe Black authored
      
      
      Switch the storage drivers (AHCI, USB, both types of MMC) over to using
      structures of function pointers like most of the other drivers. This change
      touches all boards and heavily affects the MMC drivers, but the other drivers
      were fairly straightforward to port over.
      
      BUG=None
      TEST=Built for all boards, built and booted on Falco, pit, and snow.
      BRANCH=None
      
      Change-Id: I4d5c9259e7f97eebe9b82a3bdbe112b2e2625d34
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://chromium-review.googlesource.com/168043
      
      
      Reviewed-by: default avatarron minnich <rminnich@chromium.org>
      Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      Commit-Queue: Gabe Black <gabeblack@chromium.org>
      cf805fb9
  29. 31 Jul, 2013 1 commit
    • Gabe Black's avatar
      sound: Turn the sound drivers into structures with function pointers. · 3352dfb6
      Gabe Black authored
      
      
      Also introduce a wrapper class which represents the path audio takes through
      the system called a SoundRoute. When you play a sound through the SoundRoute,
      it first makes sure all of its components are enabled which would typically
      include the codec, and then it calls through to the underlying sound source.
      
      BUG=chrome-os-partner:19420
      TEST=Built and booted on link and snow and verified that the developer mode
      beep still works and the proceeded to the kernel. Built and booted on Falco
      and saw consistent messages about not finding a beep node. Built for all other
      platforms other than bolt. Built and booted on pit with no audio set up and
      saw that it could still get through to the kernel with appropriate error
      messages from the firmware.
      BRANCH=none
      
      Change-Id: Ifbe7909cfb632c70e6a03c2ab47f0444fdef22a9
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit.chromium.org/gerrit/63545
      
      
      Reviewed-by: default avatarHung-Te Lin <hungte@chromium.org>
      Commit-Queue: Gabe Black <gabeblack@chromium.org>
      Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      3352dfb6
  30. 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
  31. 16 Jul, 2013 1 commit
  32. 10 Jul, 2013 1 commit
    • Gabe Black's avatar
      Change the GPIO drivers into structures of function pointers. · e846f1b9
      Gabe Black authored
      
      
      Reduce the generic GPIO interface to get and set functions, consolidate the
      sysinfo functions into that interface, simplify the flag management code,
      move the now extraneous GPIO functions into the driver specific driver
      structures, and adjust the exynos5250 I2C driver to use the new interface.
      Also, since there isn't a global and necessarily available GPIO API which can
      only be implemented once, it doesn't need to be a "choice" type config option.
      Since there doesn't need to be a default, inert choice any more, the stub
      driver has been deleted.
      
      BUG=None
      TEST=Built and booted on link, snow, and peach pit, built for bolt, falco,
      peppy and slippy.
      BRANCH=None
      
      Change-Id: Icb70b250417765ac857c8b0a7943b4e22587bf37
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit.chromium.org/gerrit/60984
      
      
      Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      Commit-Queue: Gabe Black <gabeblack@chromium.org>
      Tested-by: default avatarGabe Black <gabeblack@chromium.org>
      e846f1b9
  33. 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
  34. 26 Feb, 2013 2 commits
    • 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
    • Gabe Black's avatar
      depthcharge: Change the timer driver API. · 320c9f02
      Gabe Black authored
      
      
      Change the names of the timer driver API so that they have the prefix "timer"
      at their start. It also introduces a new function called "timer_hz" to
      seperate the idea of CPU frequency and the frequency of the system timer.
      
      BUG=chrome-os-partner:17340
      TEST=Built for Link and Daisy.
      BRANCH=None
      
      Change-Id: I526c6e4922653a6632fd3caabb408bfcef516a3f
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32857
      
      
      Reviewed-by: default avatarStefan Reinauer <reinauer@google.com>
      320c9f02
  35. 11 Feb, 2013 1 commit