Thread (92 messages) 92 messages, 25 authors, 2011-04-01

[GIT PULL] omap changes for v2.6.39 merge window

From: tony@atomide.com (Tony Lindgren)
Date: 2011-03-30 22:08:24
Also in: linux-omap, lkml

* Nicolas Pitre [off-list ref] [110330 13:39]:
Trying to rely on bootloaders doing things right is like saying that x86 
should always rely on the BIOS doing things right.  We have this chance 
in the OMAP case to have a manufacturer who is smart enough to document 
all those things so that the kernel can be autonomous and more reliable, 
and the BIOS joke avoided entirely. When something needs fixing it is 
much easier to update the kernel ourselves than waiting after any 
bootloader updates which are themselves much more risky to perform.

Granted, things could be structured in a better way so to minimize the 
risk of conflicts when clocks for unrelated drivers are updated at the 
same time.  Something like initcall tables or the like.
We are hitting a problem with these data files for omap2+ already
where the size of the kernel gets too bloated. So the device tree
approach would help making more distro friendly kernel.

If we want to keep the data in the kernel, they should be loadable
kernel modules except for the few core clocks etc needed to bring
up the system.

I guess an alternative to device thee could be place them under
drivers/firmware or something similar. That does not help with
per-board data though, it would only help with the clocks needed
by device drivers.
There is on-going work to bring device tree support to ARM.  Maybe that 
will be the way to go to move those clock details out of the kernel.  
And maybe that will become another unfixable PC BIOS fiasco. We'll see.  
I don't particularly like the idea of _more_ APIs between bootloaders 
and the kernel.  Keeping everything fixable in only one place is way 
more convenient than the burden of the occasional merge conflict.

Sure, something has to be done to minimize the pain, your pain, but not 
by increasing the pain elsewhere.  I think that you know pretty well 
already how painful dealing with BIOS data, or ACPI, or any other vendor 
controlled (sometimes closed source) config tables might be.  We've 
sidestepped that pain entirely on ARM so far and that really feels good.
Yeah the syncing up with the bootloader and patching kernel around
bootloader bugs is an issue. But the bloat issue might be hard to
work around otherwise.

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help