From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Fri, 20 Jan 2012 07:50:53 +0100 Subject: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support In-Reply-To: <4F186554.5060904@freescale.com> References: <1326784345-19953-1-git-send-email-sjg@chromium.org> <1326784345-19953-2-git-send-email-sjg@chromium.org> <20120119053636.3018F188E691@gemini.denx.de> <4F17B9B5.2040303@denx.de> <20120119112020.3508D188E691@gemini.denx.de> <4F186554.5060904@freescale.com> Message-ID: <4F190ECD.6070007@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 Timur, Timur Tabi wrote: > Wolfgang Denk wrote: >> As mentioned before, this is what we currently have as "device model" >> in U-Boot - not only I2C: we have the same "current device" concept >> with IDE, USB, ... > > The difference is that I2C operations are typically done internally by > other code, whereas IDE, USB, etc are done by the user on the command > line. It's not unusual for boot code to access multiple I2C devices on > different buses, so we're switching I2C buses a lot. People generally > don't try to access two networks or two USB devices back-to-back, but > that's exactly what we do with I2C. > > The other problem is that I2C operations are necessary prior to > relocation, but IDE, USB, etc generally are not. That's why we have this: > > static unsigned int i2c_bus_num __attribute__ ((section (".data"))) = > CONFIG_SYS_SPD_BUS_NUM; Yep, correct. For that case, I need the "trickery" with the "cur_i2c_adap" pointer in gd_t in the "new" framework, as gd_t is writeable before relocation ... > We need to initialize i2c_bus_num to the I2C bus that SPD is on, because > i2c_bus_num is not writable until after relocation, and DDR initialization > requires I2C. > > A board that has SPD on two different I2C buses could not be supported by > U-Boot today. ... and so with the "new" framework, it should be possible to switch to other i2c busses (incl. i2c muxes on that), before relocation. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany