[U-Boot] [PATCH 2/2] WIP: tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/31/2012 09:56 AM, Simon Glass wrote:
> Hi Stephen,
> 
> On Wed, Oct 31, 2012 at 8:41 AM, Stephen Warren <swarren@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:
...
>>>>> 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?
...
>> 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.

It's more complex than that.

If we use DT, we must be able to:

a) Configure exactly which I2C instances the board uses from DT.
b) Provide configuration (e.g. max clock rate) for those instances from DT.

If all in-use I2C adapters must be specified statically in
CONFIG_SYS_I2C_ADAPTERS, then since a board's DT could enable any
arbitrary subset of Tegra's I2C adapters, then we must always set
CONFIG_SYS_I2C_ADAPTERS to the list of all Tegra's I2C adapters. If we
put some subset into CONFIG_SYS_I2C_ADAPTERS, then we're pre-defining
the maximal set of I2C adapters that a board can enable, which means DT
isn't specifying that, but rather the board config file is, and hence
it's pointless to even use DT for this purpose.

Now, most boards won't use all I2C adapters, so presumably the Tegra I2C
init routine will look for status="disabled" (or the inverse) in DT, and
only initialize if the DT node for the adapter is present and enabled.
However, this will leave entries in CONFIG_SYS_I2C_ADAPTERS that are not
enabled, which will presumably influence the I2C bus numbering in the
U-Boot shell; there will be I2C busses that exist but cannot be used. Is
this what we want? Perhaps it is in fact a good idea to always make the
U-Boot shell's I2C bus IDs be the same as the HW's, and hence leave gaps
when some ports aren't enabled? That would be a departure from the way
USB is handled today though.