[U-Boot] [RFC PATCH v2 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)

[Jason]

Simon,

On Wed, Sep 14, 2011 at 01:24:31PM -0700, Simon Glass wrote:
> On Wed, Sep 14, 2011 at 1:16 PM, Jason <u-boot at lakedaemon.net> wrote:
> > On Wed, Sep 14, 2011 at 01:05:58PM -0700, Simon Glass wrote:
...
> >> Yes, ideally I would like to keep SOC-specific things out of it at
> >> this stage, but I was asked for an example and had to choose
> >> something! My hope is that we can have the base patch and then a
> >> couple of architecture patches.
> >
> > Yes, I don't like putting fdt_decode_i2c() or fdt_decode_rtc() in
> > common/fdt_decode.c ...  The current implementation of fdt...i2c() is
> > arch specific, and fdt...rtc() I know will only work for the simple
> > integrated rtc with two registers.
> 
> This is one of the things to resolve. I think we need an fdt_decode to
> lighten the load of finding aliases, decoding addresses and the like,
> but a bigger question is whether we want the various i2c drivers to
> share decode logic. It will help make the drivers more similar, but
> clearly means that they have to follow the lowest common denominator.
> This is a bit like CONFIG_ works at present - and we are replacing the
> CONFIG_ items. For i2c the configs might be CONFIG_SYS_I2C_SPEED and
> the controller address (and maybe CONFIG_SYS_I2C_SLAVE). But we don't
> deal with particular i2c config like pinmux settings etc. which are
> not common across a lot of boards. So fdt_decode would deal with these
> few common settings and leave specific drivers to do the rest.
> 
> But if people are happy with the idea of fdt decode code bleeding more
> into each driver, then fdt_decode just becomes a low-level helper
> library, and does not have specific functions for decoding an i2c
> node, a uart, etc.

After working with it a little, this seems more natural.  Clearly
delineated.

> That is perhaps more pure - my main concerns with
> this are uptake (too hard to swtich a board over to fdt) and
> consistency (everyone will use their own way of doing the same thing -
> and we have enough of that in U-Boot already :-)

If it becomes a problem, we can address it later.  I much prefer a clean
boundary to start with.

thx,

Jason.