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

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

Hi Heiko,

On Thu, 01 Aug 2013 10:38:15 +0200, 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?

From the "we want to scan a complete dt with maybe a lot of nodes, we
do not want to use?" above, I inferred that one problem here was having
to waste time going through the whole DT looking only for info needed
at _f stage. This is why I made the suggestion above for that problem.
Sorry if I did not understand this properly.

> 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?)
> 
> 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?
> 
> > Note: I confess I don't even know at the moment how DT is structured, so
> > I may have talked complete nonsense above. If so, please forgive me and
> > point me to some DT 101 course for me to avoid shame (at least on this
> > topic) in the future.
> 
> bye,
> Heiko


Amicalement,
-- 
Albert.