[U-Boot] [u-boot v2] and i2c

[U-Boot] [u-boot v2] and i2c

[Heiko Schocher]

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:

- 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? What if we need the devices earlier?

  Maybe I overlooked something obvious?

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [u-boot v2] and i2c

[Sascha Hauer]

Hi Heiko,

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.

> 
> - 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

> 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
see no other way handling this. If done with care you can reuse most
of the driver code.
Once the framework is initialized the normal functions can be used.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] [u-boot v2] and i2c

[Heiko Schocher]

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