From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Fri, 21 Nov 2014 08:27:22 +0100 Subject: [U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra In-Reply-To: References: <1415727993-22032-1-git-send-email-sjg@chromium.org> <20141119172751.93F7.AA925319@jp.panasonic.com> <546C963A.9030403@denx.de> Message-ID: <546EE95A.50700@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 Simon, Am 20.11.2014 18:31, schrieb Simon Glass: > Hi Heiko, > > On 19 November 2014 13:08, Heiko Schocher 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 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. Yes, but we have architectures without FDT support yet ... and we boot also non linux OSes ... >>> 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. Great, but powerpc should work with DT too... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany