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-b...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot