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