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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Simon,

On Thu, 1 Aug 2013 08:22:55 -0600, Simon Glass <sjg@chromium.org> wrote:

> Hi,
> 
> On Thu, Aug 1, 2013 at 2:38 AM, Heiko Schocher <hs@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@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.

What about targets which do not have such a small RAM available?

> 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


Amicalement,
-- 
Albert.