On Tue, Feb 23, 2016 at 11:56:34AM +0000, Peter Maydell wrote: > On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > I'm not quite sure how it works if, as in versatile display case, there > > are multiple DT overlays of which one has to be enabled. I hope there's > > support to choose which one to use via kernel cmdline or similar. > > > > I would personally like it much more if the bootloader would either > > compose a final dtb from DT fragments and pass it to the kernel, or > > alternatively the bootloader would pass the base dtb image and a bunch > > of DT overlays to the kernel, and the kernel would deal with the DT > > overlays. > > Speaking as somebody who's written the "bootloader" code that's > used for what I guess are the majority of versatile kernel boots, > i.e. the one in QEMU, I think that requiring the bootloader to do this > would be a significant worsening from the current state. > > Right now the bootloader doesn't need to do much at all with device > trees, except pass the kernel the DT that the user gave us, which > is just the kernel's own data structures in a separate file for > convenience. You need to do some very minor tweaks to the /chosen > node, but these can be handled the same way for any board and aren't > hardware specific. There's no need to worry about dt fragments > either for the bootloader or for the user. Imposing a new requirement > for the bootloader to have to probe hardware which it otherwise > has no need to even care about, and then edit and update the DT > in a board-specific manner, or have board-specific DT fragments, > seems like a totally unnecessary imposition on both bootloader > authors and end-users, and of course it would break booting newer > kernels on the great mass of already existing boot loaders and > QEMU installs. > > The kernel is in a position to probe the display hardware and determine > what is there, and do the right thing, and that's exactly what it > does today. The kernel should continue to do this. > The advantage of DT is that it allows moving information about > non-probeable hardware that was previously hardwired in the kernel > C sources into a separate data structure, but the versatile displays > are not non-probeable. I can see no benefit at all from hardwiring into > the dt something which the kernel has previously been successfully > dynamically getting right without any bootloader intervention -- it just > makes the kernel less flexible and less user-friendly. +1. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
