Hi Simon,
On Tue, 11 Nov 2014 10:46:16 -0700 Simon Glass <[email protected]> wrote: > > This series adds 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_chip > which 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() and i2c_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 for i2c_init_all(), i2c_init(), > i2c_init_board(), i2c_board_late_init() and board_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 This statement implies that platform data will (should) be supported in the future, I think. As you know, I have a strong belief that device tree should be left optional. If platform data is supported someday, that's OK. Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
