Hi Heiko, On 19 November 2014 13:08, Heiko Schocher <h...@denx.de> wrote: > Hello Masahiro, > > Am 19.11.2014 09:27, schrieb Masahiro Yamada: > >> Hi Simon, >> >> >> >> On Tue, 11 Nov 2014 10:46:16 -0700 >> Simon Glass <s...@chromium.org> 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. > > > There was a discussion on the ELCE2014 and I think, I thought such > a thread also on the list, if we should only support device tree with > DM ... > >> As you know, I have a strong belief that device tree should be left >> optional. > > > Yes, I think in this direction too ... as I do not know, if > all archs ever support DT ... and in the SPL case we should > have a memory friendlier option too ...
My feeling is that if Linux uses FDT for a platform (e.g. ARM) we should do so in U-Boot. > >> If platform data is supported someday, that's OK. > > > Patches welcome ... I have this on my ToDo list, but find currently > no time ... I'm going to play around with a PPC board at some point, so will see what happens there. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot