From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 28 Apr 2009 12:07:30 +0200 Subject: [U-Boot] [u-boot v2] and i2c In-Reply-To: <20090428094710.GC3696@pengutronix.de> References: <49F6B20E.9070502@denx.de> <20090428094710.GC3696@pengutronix.de> Message-ID: <49F6D562.9030907@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 Sascha, Sascha Hauer wrote: > On Tue, Apr 28, 2009 at 09:36:46AM +0200, Heiko Schocher wrote: >> Hello Sascha, >> >> I actually looked in the u-boot-v2.git in the i2c branch, >> because I wanted to look how things in v2 work, specially >> I2C Subsystem ... and I have a first question: > > Note that the I2C branch is out of date and probably needs some > updating. That does not affect your current problem though. Yep, I know. >> - In ppc area, we start running from flash and have to relocate >> code. Before setting up RAM, we maybe have to read SPD EEprom >> over I2C for this. How could this work in v2? I see in >> drivers/i2c/i2c-core.c in i2c_register_adapter () an >> INIT_LIST_HEAD(&adap->clients); >> >> This could not work, when running from Flash, because we have no >> usable RAM ... >> So I looked how this device approach globally works, and found in >> lib/driver.c in register_device() also: >> >> 107 >> 108 list_add_tail(&new_device->list, &device_list); >> 109 INIT_LIST_HEAD(&new_device->children); >> 110 >> >> so would this device_driver approach in v2 actually only work, >> if running from RAM? > > Yes Hmm... :-( >> What if we need the devices earlier? > > You would need portions of the driver which bypass the I2C framework. > I did something similar for the console (see > drivers/serial/serial_mpc5xxx.c). This is not particularly nice but I :-( Ok, thanks for the info. bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany