Hi Stephen,
On Wed, Oct 31, 2012 at 8:41 AM, Stephen Warren <swar...@wwwdotorg.org> wrote:
> On 10/31/2012 12:00 AM, Heiko Schocher wrote:
>> Hello Stephen,
>>
>> On 30.10.2012 23:32, Stephen Warren wrote:
>>> On 10/30/2012 11:28 AM, Simon Glass wrote:
>>>> (just for illustration, please don't merge)
>>>>
>>>> This enables CONFIG_SYS_I2C on Tegra, updating existing boards and
>>>> the Tegra
>>>> i2c driver to support this.
>>>
>>>> diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
>>>
>>>> +#ifdef CONFIG_TEGRA_I2C
>>>> +extern struct i2c_adapter tegra_i2c_adap[];
>>>> +#endif
>>>
>>> I'm not sure why that's needed if the config files have to put the
>>> adpater list into a #define:
>>>
>>>> diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h
>>>
>>>> +#define CONFIG_SYS_I2C
>>>> +#define CONFIG_SYS_I2C_ADAPTERS {&tegra_i2c_adap[0]}
>>>> +#define CONFIG_SYS_NUM_I2C_ADAPTERS TEGRA_I2C_NUM_CONTROLLERS
>>>
>>> But, why is CONFIG_SYS_I2C_ADAPTERS needed; can't the adapter init
>>> functions (which presumably would be called from board code or as a
>>> result of DT parsing) dynamically register themselves?
>>
>> This would not work, if we are running for example from flash on
>> powerpc before relocation. There some boards need to read RAM
>> infos from an SPD Eeprom through i2c ... so we must have very early
>> i2c bus ready and usable ...
>>
>> It maybe a good plus to add i2c busses/adapters dynamically after
>> relocation is done and we have enough RAM ... I tried such an
>> approach here:
>>
>> http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=ccb680c8cf9002232bc459e4003e3b47db5e1bf4
>>
>> but this is an old state (only rebased a long time),
>> but it is maybe a good base for doing such an feature
>> if it is needed ...
>
> I mainly ask because Simon is pushing to have Tegra's U-Boot completely
> driven by device tree. If we need to hard-code the list of enabled I2C
> adapters in the U-Boot config file, and don't also support dynamically
> added I2C drivers, then that will be incompatible with device tree.
Mostly, although with the serial console (which had a similar problem)
we just decoded the information onto the stack as needed. It was
inefficient, but worked fine for a small number of operations. We
might be able to do better with pre-relocation malloc() soon.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
