[U-Boot] [RFC PATCH v2 1/6] fdt: ARM: Add device tree control of U-Boot (CONFIG_OF_CONTROL)

[Simon Glass]

Hi Wolfgang,

On Tue, Sep 13, 2011 at 2:47 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ at mail.gmail.com> you wrote:
>>
>> I would love to, yes. To some extent there is a bit of this already,
>> at least for specific subsystems. Clearly the fdt would work better if
>> we could just hand U-Boot the fdt and say 'init yourself'. It would
>> then scan the tree and init all the drivers for all active devices.
>
> No, it would definitely not do that.
>
> U-Boot shall not initialize all possible available devices, but always
> only those that it needs itself to perform it's task, which usually is
> just to load and start an OS.  It makes no sense to initialize all
> network interfaces (and eventually wait for the link to come up), to
> initialize all attached disk drives (and wait for them to spin up) or
> to scan the whole USB bus and initialize all attached devices when we
> don't need any of these to boot the OS.
>
> Suchinitializations shall always be done on demand only, i. e. when a
> command is run that accesses any such device.

Yes thanks for pointing that out. I am really thinking of the init
sequence in board_init_r() where we init NAND, MMC and the like. So
yes it makes no sense to blindly init everything we can find. The fdt
can provide a list of available options for each device type (although
in practice often it will provide only one option, perhaps with
multiple instances).

>
>> However, we can achieve most of the aims using something along the
>> lines of what I have proposed, where the existing call (say to
>> nand_init()) can look up the fdt for its node, and then get the
>> information it needs. The only really difference is the explicit
>> hard-coded call to nand_init, rather than a general purpose routine to
>> find a nand node and then locate a driver for it.
>
> I can;t parse that.  Why cannot nand_init() do exactly what you
> suggest, i. e. find a nand node and then locate a driver for it?
> OK, by then it will probably be something like driver_init("nand") or
> the like, but that's just a detail.

That's certainly the current approach, yes. It does work well I think,
and has the virtue of being simple, with minimal changes required to
code.

>
>> To some extent that way of doing things would invert the way U-Boot
>> currently works. It would also introduce questions about dealing with
>> multiple devices of the same type (e.g. two different i2c controllers
>> (not just instances) or driving two displays. These sorts of things
>> are tricky in U-Boot at the moment.
>
> Keep in mind that devices are always accessedonly on demand, so you
> will have the needed information which device needs to be opened.

Yes, that's true and we mustn't do anything which blurs or weakens
that link. When I think of multiple LCD support for example, while
there is hardware support for it, do we have a need for it? Sometimes
this sort of thing is a solution looking for a problem. Yes it would
be easier to implement this feature with a unified driver model,
but...

On the other hand I think serial could benefit from a unified driver
model quite nicely :-)

>
>> So overall I think a unified driver model is a separate problem, and
>> one that we should discuss and perhaps move forward on separately.
>
> Agreed.

OK good. There seem to be a lot of different activities going on, as
Graeme says in the other thread.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> If you want strict real-time behavior, run in the real  time  schedu-
> ling class.  But there are no seatbelts or airbags;  main(){for(;;);}
> can hard hang your system.                          -- Bart Smaalders
>