RFC RFC: dm: Add I2C support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest2 of 12 patches 0 repliesNew
2 of 12 patches are in this archive. The cover letter announces 12.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 3/12 | dm: i2c: Add a uclass for I2C | +0 | 0 replies | |
| 4/12 | dm: i2c: Implement driver model support in the i2c command | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [RFC PATCH 0/12] RFC: dm: Add I2C support
Hello Tom,
Am 24.10.2014 17:03, schrieb Tom Rini:
Quoted 40 lines · Simon Glass
Quoted 39 lines
(Note this is RFC since the uclass interface needs discussion and also because only sandbox is implemented so far. But I thought it best to get this out there as soon as I wrote it as it may influence the PMIC library, etc.)
This series is an initial attempt to add I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion.
Several changes are made from the original I2C implementations.
Firstly It is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct
dm_i2c_chipwhich is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call.Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model
i2c_set_bus_num()andi2c_get_bus_num()are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back.Thirdly initialisation is handled by driver model's normal
probe()method on each device so there should be no need fori2c_init_all(),i2c_init(),i2c_init_board(),i2c_board_late_init()andboard_i2c_init().I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later.
Platform data is not yet supported either, only device tree. The
U_BOOT_I2C_MKENT_COMPLETE()andU_BOOT_I2C_ADAP_COMPLETE()macros are not used. Also structi2c_adapteris not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree.
Quoted 3 lines
Quoted 1 line
This series is available at u-boot-dm/i2c-working.
Nothing jumped out at me. Heiko?
Looking in this patches soon... sorry for the delay.
bye,
Heiko
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany