From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 13 Nov 2012 07:24:00 +0100 Subject: [U-Boot] [PATCH 2/2] WIP: tegra: i2c: Enable new CONFIG_SYS_I2C framework In-Reply-To: <509BE63F.8030701@wwwdotorg.org> References: <1351618133-14909-1-git-send-email-sjg@chromium.org> <1351618133-14909-2-git-send-email-sjg@chromium.org> <50905561.90602@wwwdotorg.org> <5090BE73.6050501@denx.de> <509146C5.8020301@wwwdotorg.org> <509150E4.2050206@wwwdotorg.org> <509227DF.9070107@denx.de> <5092AB68.6080801@wwwdotorg.org> <509B556A.1050808@denx.de> <509BE63F.8030701@wwwdotorg.org> Message-ID: <50A1E780.4090807@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 Stephen, On 08.11.2012 18:05, Stephen Warren wrote: > On 11/07/2012 11:47 PM, Heiko Schocher wrote: >> On 01.11.2012 18:03, Stephen Warren wrote: > ... >>> I'd suggest having a CONFIG_SYS_I2C_DRIVERS variable at most, and each >>> driver registers an arbitrary number of adapters and/or buses during its >>> initialization. >> >> Why should an i2c driver register buses? That is board specific. > > I don't entirely agree here. Certainly the information is > board-specific, but I don't believe that precludes bus registration > occurring from the I2C adapter drivers themselves, based on information > passed from a board file or device tree. > > If a particular adapter is instantiated by the board, then there is > clearly an I2C bus attached to that adapter. Hence, it's quite > reasonable for the adapter itself to register the bus directly attached > to it. But some i2c drivers have more than one instance... would you for all boards register all possible instances of a driver? ... A lot of boards do not use the multibus feature, and so they use only one i2c driver ... on this boards we would register maybe a lot of buses for nothing ... > Following on from there, if there's an I2C bus mux attached to some I2C > bus, then there are clearly I2C buses downstream from the bus mux, and > the bus mux driver knows exactly how many there are, and can register > those buses. Here again, why register all possible buses? We are just a bootloader ... > This can continue through a whole tree of I2C adapters/muxes/buses. > > The above model fits into device tree very well; in that case, you only > find out about the existence of downstream muxes etc. once you've > initialized the I2C adapter for the parent bus. > > Equally, I think this model can work very well for manually coded board > files; the board file can directly instantiate all top-level I2C > adapters, and pass information to the I2C driver for those adapters > indicating which I2C devices are attached to the buses. Then, if one of > those devices happens to be an I2C bus mux, it can instantiate further > I2C buses, which in turn instantiate more devices based on the > parameters passed to the I2C bus mux driver. Yep, possible ... but another approach ... >>> We could probably even get away without CONFIG_SYS_I2C_DRIVERS at all; >>> just have each driver define a structure that gets put into a special >>> linker section, so that the I2C core can iterate over all linked drivers >>> at boot time and call their initialization functions. >>> >>> Even if we don't get rid of CONFIG_SYS_I2C_ADAPTERS, I really think we >>> should get rid of CONFIG_SYS_I2C_BUSSES and do that dynamically. >> >> How do we this, for example on some powerpc boards, which boot from >> NOR flash and read a SPD EEprom data for RAM initialization (Note: we >> have here not a lot of stack, nor RAM)? Maybe we should wait with this >> hole patchserie until DM is ready? (And maybe rework it completly?) > > I'd expect SPD initialization to be a special case in a U-Boot SPL; > isn't that its purpose? We have boards which are booting from NOR flash and reading a SPD EEprom without using SPL ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany