[U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Simon Glass]

Hi,

On Thu, Aug 1, 2013 at 2:38 AM, Heiko Schocher <hs at denx.de> wrote:

> Hello Albert,
>
> Am 01.08.2013 08:53, schrieb Albert ARIBAUD:
>
>  Hi Heiko,
>>
>> On Thu, 01 Aug 2013 08:02:42 +0200, Heiko Schocher<hs at denx.de>  wrote:
>>
>>  I suppose you could. It seems conceptually /far/ simpler to just scan
>>>> the DT once up-front rather than having to defer all this stuff until
>>>>
>>>
>>> on the other hand we ring for every ms boot time ... and here we want
>>> to scan a complete dt with maybe a lot of nodes, we do not want to
>>> use?
>>>
>>
>> Scanning all of DT seems to imply it has no strict or standard
>> ordering. Could we mandate, suggest, of make it so that all entries in
>> the DT needed at _f time are put first, and even maybe place an "end of
>> _f" custom marker in DT to delimit them? (I assume that, for the sake of
>>
>
> I do not know, if this is possible, as I think the DT used in U-Boot
> should be the same as used in linux ... or?
>
>
>  Postel-ism, anything in DT which is not understandable is skipped, so
>> other users of the DT than us would not even be annoyed by such a
>> marker)
>>
>> This way, we'd avoid wasting time scanning most of the DT in this case.
>>
>
> Hmm.. why should we introduce such things, instead of scanning the
> node only if we need it?
>
> We have "only" the problem, that we could not write to data at this
> moment ... but this problem should be solved in a seperate topic.
> I2C is usable before relocation, the problem is in conjunction with
> dt, that we can not save for example the base address of the controller,
> which we get from the DT ... If I understand it correct!
>
> So we need an option when using dt, that we have (small ram) in which
> we can write some parameters parsed from dt ...
>
> I think this problem have all subsystems used before relocation.
> (for example: environment on a spi flash?)
>
>
I think using a small RAM is a good approach. At least it is better than
pretending there is no RAM at all. We currently have no facility to
allocate RAM before relocation, other than to use the .data section. We can
use global_data but that won't scale well for many drivers adding their own
stuff in there. Samsung's driver uses .data, I don't think it is a big deal.

One option I should mention is to decode the I2C FDT nodes each time it is
needed prior to relocation (i.e. to the stack), use it for the transaction,
and throw it away. This is quite painful IMO this it involves putting calls
in the driver to check if we are pre-reloc and have a stack space used
every time. On tegra20 this would be 130 bytes or so. I mention it because
console working this way for a while (decoding the console again on every
byte).

Options as I see it:

- just fudge it for now and use .data (deal with it later with driver model)
- change the meaning of board_init_f() such that memory may be available
(e.g. if run from SPL)
- decode the FDT nodes every time we need them (ick)
- adjust the ordering so that I2C normally happens post reloc except for
specific platforms with a CONFIG defined (Heiko, the difference as I
understand it is that with your patch CONFIG_HARD_I2C or CONFIG_SOFT_I2C
are now defined, and so I2C happens prior to reloc now)


>
> As Wolfgang said:
> "Agreed - actually we're entering an area hear that smells pretty
> strong like device model reorganization :-)"
>
> BTW: How is this problem solved with the device model approach?


More that we need to solve it, probably with a limited malloc() pre-reloc.

Regards,
Simon