1. 01 7月, 2020 1 次提交
  2. 04 6月, 2020 1 次提交
  3. 31 5月, 2020 2 次提交
    • S
      i2c: designware: Add Baikal-T1 System I2C support · fcb82a93
      Serge Semin 提交于
      Baikal-T1 System Controller is equipped with a dedicated I2C Controller
      which functionality is based on the DW APB I2C IP-core, the only
      difference in a way it' registers are accessed. There are three access
      register provided in the System Controller registers map, which indirectly
      address the normal DW APB I2C registers space. So in order to have the
      Baikal-T1 System I2C Controller supported by the common DW APB I2C driver
      we created a dedicated Dw I2C controller model quirk, which retrieves the
      syscon regmap from the parental dt node and creates a new regmap based on
      it.
      Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@kernel.org>
      fcb82a93
    • S
      i2c: designware: Convert driver to using regmap API · 0daede80
      Serge Semin 提交于
      Seeing the DW I2C driver is using flags-based accessors with two
      conditional clauses it would be better to replace them with the regmap
      API IO methods and to initialize the regmap object with read/write
      callbacks specific to the controller registers map implementation. This
      will be also handy for the drivers with non-standard registers mapping
      (like an embedded into the Baikal-T1 System Controller DW I2C block, which
      glue-driver is a part of this series).
      
      As before the driver tries to detect the mapping setup at probe stage and
      creates a regmap object accordingly, which will be used by the rest of the
      code to correctly access the controller registers. In two places it was
      appropriate to convert the hand-written read-modify-write and
      read-poll-loop design patterns to the corresponding regmap API
      ready-to-use methods.
      
      Note the regmap IO methods return value is checked only at the probe
      stage. The rest of the code won't do this because basically we have
      MMIO-based regmap so non of the read/write methods can fail (this also
      won't be needed for the Baikal-T1-specific I2C controller).
      Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      [wsa: fix type of 'rx_valid' and remove outdated kdoc var description]
      Signed-off-by: NWolfram Sang <wsa@kernel.org>
      0daede80
  4. 30 5月, 2020 2 次提交
  5. 13 5月, 2020 1 次提交
  6. 26 4月, 2020 1 次提交
  7. 19 4月, 2020 1 次提交
  8. 23 1月, 2020 2 次提交
  9. 16 1月, 2020 2 次提交
  10. 26 11月, 2019 1 次提交
  11. 25 11月, 2019 1 次提交
  12. 12 11月, 2019 1 次提交
    • P
      i2c: pxa: migrate to new i2c_slave APIs · 4d51b4ce
      Patrick Williams 提交于
      The i2c subsystem was enhanced circa 2015 to support operating as
      an i2c-slave device.  Prior to that, the i2c-pxa driver supported
      an i2c-slave but had its own APIs.  There are no existing in-kernel
      drivers or platforms that utilize the i2c-pxa APIs.
      
      Migrate the i2c-pxa driver to the general i2c-slave APIs so that
      existing drivers, such as the i2c-slave-eeprom, can be used.
      
      This has been tested with a Marvell EspressoBin, using i2c-pxa and
      i2c-slave-eeprom, acting as a slave, and a RaspeberryPi 3, using the
      at24 driver, acting as a master.
      Signed-off-by: NPatrick Williams <alpawi@amazon.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      4d51b4ce
  13. 25 10月, 2019 1 次提交
  14. 02 9月, 2019 1 次提交
  15. 30 8月, 2019 3 次提交
  16. 14 8月, 2019 1 次提交
  17. 07 8月, 2019 1 次提交
  18. 01 8月, 2019 1 次提交
  19. 06 7月, 2019 1 次提交
  20. 26 6月, 2019 1 次提交
  21. 22 6月, 2019 1 次提交
  22. 28 5月, 2019 2 次提交
  23. 21 5月, 2019 1 次提交
  24. 03 5月, 2019 1 次提交
  25. 04 4月, 2019 1 次提交
  26. 25 3月, 2019 2 次提交
  27. 21 3月, 2019 1 次提交
  28. 10 11月, 2018 2 次提交
  29. 05 10月, 2018 1 次提交
  30. 05 8月, 2018 1 次提交
  31. 01 8月, 2018 1 次提交