On 04/03/2011 04:25 PM, Somebody in the thread at some point said:
Hi -
Think of the DT as a way of probing a bus that doesn't have probe
capabilities. This gives you a way to dynamically load drivers from
initrd if you want. For example we dynamically loaded drivers for I2C
devices that were previously always built in.
Understood.
I haven't been following the ARM DT work, but a scheme that might work
on ARM is to build DTs into the kernel corresponding to each ARM
machine ID supported by the kernel image. Use the machine ID to
Sounds reasonable.
The bootloader must bring up enough prerequisites for the kernel to run,
so it has to 'know' / identify what it is running on enough at least to
configure the SDRAM and operate the source that is providing the kernel
image, eg, right MMC controller code at the right place in memory. If
it absolutely must know that much, it's reasonable that it passes in the
machine ID ATAG (or otherwise tell the kernel which DT is appropriate)
like it does at the moment, it kind of had to know that much to do the
prerequisites.
select the correct one and discard the rest. As ARM bootloaders are
modified to directly support DTs slowly get rid of the in-kernel DTs.
I didn't really understand the value of ending up with the bootloader in
change of providing DT data and DT data sitting as external files. It
seems to me that since the kernel is the guy that is consuming that
data, it's the kernel that it should be bound into. That must be
particularly true when it's such early days for DT and the code parsing
it and the data in the trees will be in flux for quite a while, and
getting them out of step versioning-wise will cause hard to reproduce or
understand failure for the user.
I just don't see people tweaking DT tables by package update and leaving
the kernel package unchanged, I do see wrong version DT tables getting
pulled in, bootloader environments pointing to the wrong place or NAND
or default environments coming in and causing DT load failure, and
serious issues coming from trying to manage boot.scr via package. I
don't see we should want people writing their own customized boot.scr to
point the same kernel to different DT tables, as this also is going to
make bug reports nondeterministic.
(It was suggested also on that lkml thread to cast DT stuff out into a
module, but that's not going to fly since the information presumably
that will be part of DT like where the mmc controller is, what mux
settings for the balls are needed, clock tree for it are in the module
that you need on mmc, for example. So it seems to me it needs to be
built-in.)
A key concept: think of the DT as a way of probing a bus that doesn't
have probe capabilities. You can argue that C code can produce the
same effect as DTs which is true. But that board specific setup code
tends to grow and stick its fingers into everything. DTs mitigate that
simply because they aren't C code. DTs encourage the development of
generic device setup code instead of one-off platform specific code.
I'm only arguing against sticking what is fragile, changing data
critical for operation on a platform outside of the kernel, and arguing
for binding the intended version of data to the intended version of the
code that's going to use it in-kernel. If it's going to become uber
critical to any kind of kernel operation it had better be under the
auspices of the kernel itself.
-Andy
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
