From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 31 Jul 2013 13:31:57 -0600 Subject: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework In-Reply-To: <51F8A4CA.7070702@denx.de> References: <1367668903-29653-1-git-send-email-hs@denx.de> <1367668903-29653-9-git-send-email-hs@denx.de> <51F6946F.8010500@wwwdotorg.org> <51F740FD.4080505@denx.de> <51F81261.7020008@wwwdotorg.org> <51F81B51.6010305@wwwdotorg.org> <51F83104.5090508@wwwdotorg.org> <51F83570.1010909@wwwdotorg.org> <51F8A4CA.7070702@denx.de> Message-ID: <51F9662D.1070602@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/30/2013 11:46 PM, Heiko Schocher wrote: ... > Hmm.. each i2c adapter has its own init function ... why the tegra > driver do not use it? And do the necessary inits in it? So we > initialize an adapater only if we use it, which is also a rule > for u-boot ... > > I have no hw, but it should be possible to add to process_nodes() > a parameter "controller_number" and call > process_nodes(controller_number, ...) from the i2c drivers init > function ... There are two steps to initializing I2C on a Tegra system: 1) Parsing the DT to determine which/how-many I2C adapters exist in the SoC. This will yield information such as the register address of the I2C adapters, which clock/reset signal they rely on, perhaps the max bus clock rate, etc. This is a single global operation that needs to happen one single time before anything else. This stage initializes the i2c_controllers[] array, since that's what stores all the data parsed from DT. 2) Actually initializing or using the I2C HW. That could certainly be part of the per-I2C-controller init() function you mention. Now, I think the big disconnect here is that historically, the U-Boot binary has hard-coded all the details that step (1) above parses out of DT, so that step (1) did not need to exist. However, Simon has been pushing Tegra towards not hard-coding any of this information, but instead having a single binary that can work on arbitrary Tegra boards and even across different Tegra SoCs which have a different number of I2C controllers at different register addresses. This is quite fundamentally different to how U-Boot has worked in the past, and evidently has some problems fitting into the typical U-Boot initialization sequence.