From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Wed, 19 Nov 2014 14:08:10 +0100 Subject: [U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra In-Reply-To: <20141119172751.93F7.AA925319@jp.panasonic.com> References: <1415727993-22032-1-git-send-email-sjg@chromium.org> <20141119172751.93F7.AA925319@jp.panasonic.com> Message-ID: <546C963A.9030403@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Masahiro, Am 19.11.2014 09:27, schrieb Masahiro Yamada: > Hi Simon, > > > > On Tue, 11 Nov 2014 10:46:16 -0700 > Simon Glass 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 ... > If platform data is supported someday, that's OK. Patches welcome ... I have this on my ToDo list, but find currently no time ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany