1. 18 Jan, 2017 1 commit
  2. 16 Dec, 2016 1 commit
  3. 15 Aug, 2016 2 commits
  4. 26 Jul, 2016 1 commit
  5. 17 May, 2016 3 commits
  6. 13 Apr, 2016 1 commit
  7. 24 Jan, 2016 1 commit
  8. 03 Sep, 2015 1 commit
  9. 13 Aug, 2015 1 commit
  10. 06 Aug, 2015 3 commits
    • Simon Glass's avatar
      cros_ec: Support the LDO access method used by spring · f48eaf01
      Simon Glass authored
      Add a driver to support the special LDO access used by spring. This is a
      custom method in the cros_ec protocol - it does not use an I2C
      There are two implementation choices:
      1. Write a special LDO driver which can talk across the EC. Duplicate all
      the logic from TPS65090 for retrying when the LDO fails to come up.
      2. Write a special I2C bus driver which pretends to be a TPS65090 and
      transfers reads and writes using the LDO message.
      Either is distasteful. The latter method is chosen since it results in less
      code duplication and a fairly simple (30-line) implementation of the core
      The crosec 'ldo' subcommand could be removed (since i2c md/mw will work
      instead) but is retained as a convenience.
      Signed-off-by: 's avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: cros_ec: Convert the I2C tunnel code to use driver model · cc456bd7
      Simon Glass authored
      The Chrome OS EC supports tunnelling through to an I2C bus on the EC. This
      currently uses a copy of the I2C command code and a special 'crosec'
      With driver model we can define an I2C bus which tunnels through to the EC,
      and use the normal 'i2c' command to access it. This simplifies the code and
      removes some duplication.
      Add an I2C driver which tunnels through to the EC. Adjust the EC code to
      support binding child devices so that it can be set up. Adjust the existing
      I2C xfer function to fit driver model better.
      For now the old code remains to allow things to still work. It will be
      removed in a later patch once the new flow is fully enabled.
      Signed-off-by: 's avatarSimon Glass <sjg@chromium.org>
    • Simon Glass's avatar
      dm: i2c: Add support for multiplexed I2C buses · 3d1957f0
      Simon Glass authored
      Add a new I2C_MUX uclass. Devices in this class can multiplex between
      several I2C buses, selecting them one at a time for use by the system.
      The multiplexing mechanism is left to the driver to decide - it may be
      controlled by GPIOs, for example.
      The uclass supports only two methods: select() and deselect().
      The current mux state is expected to be stored in the mux itself since
      it is the only thing that knows how to make things work. The mux can
      record the current state and then avoid switching unless it is necessary.
      So select() can be skipped if the mux is already in the correct state.
      Also deselect() can be made a nop if required.
      Signed-off-by: 's avatarSimon Glass <sjg@chromium.org>
  11. 30 May, 2015 1 commit
  12. 18 Apr, 2015 3 commits
  13. 19 Feb, 2015 1 commit
  14. 12 Feb, 2015 1 commit
  15. 30 Jan, 2015 3 commits
  16. 24 Sep, 2014 1 commit
  17. 30 Jul, 2014 1 commit
    • Masahiro Yamada's avatar
      kconfig: add board Kconfig and defconfig files · dd84058d
      Masahiro Yamada authored
      This commit adds:
       - arch/${ARCH}/Kconfig
          provide a menu to select target boards
       - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
          set CONFIG macros to the appropriate values for each board
       - configs/${TARGET_BOARD}_defconfig
          default setting of each board
      (This commit was automatically generated by a conversion script
      based on boards.cfg)
      In Linux Kernel, defconfig files are located under
      arch/${ARCH}/configs/ directory.
      It works in Linux Kernel since ARCH is always given from the
      command line for cross compile.
      But in U-Boot, ARCH is not given from the command line.
      Which means we cannot know ARCH until the board configuration is done.
      That is why all the "*_defconfig" files should be gathered into a
      single directory ./configs/.
      Signed-off-by: 's avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Acked-by: 's avatarSimon Glass <sjg@chromium.org>