On 24/02/16 12:46, Russell King - ARM Linux wrote: > On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote: >> My opinion is that the bootloader should be responsible for telling the >> kernel what hardware there is on the board. For busses like PCI we have >> proper probing mechanism with global unique identifiers for the devices, >> and nothing is needed from the bootloader. > > Exactly, but that is _NOT_ the case here, because we're not talking > about an on-board display. Ok, what is it then? I'm not familiar with the boards in question. When does a display become an on-board display? All the panels I have can be disconnected quite easily, but I still consider them as on-board displays. >> In the Versatile case the panels are kind of probeable, but not in the >> same sense as PCI: all that can be probed on Versatile is a board >> specific ID, which in itself doesn't tell what kind of panel there is. >> In addition to the ID we need board specific tables listing the details >> of the panels. > > That argument does not stack up. Just because you've plugged in a > network device does not mean that the kernel can drive it: the kernel > needs a device specific driver, which is determined by looking at the > IDs. There is no standard network driver PCI interface. Yes, but you can connect the network device to any board with a PCI bus and it works. Here, if I'm not mistaken, the displays are built for this single board, making them board specific. So sure, someone could build boards with the same connector, allowing you to connect the same displays. If that's the case, then CLCD should be taken out of this picture, as the board could have something else than CLCD as the display controller. >> I think one of the core questions here is: do we want to start adding >> board specific drivers to the kernel, instead of dealing with it in the >> bootloader when possible? My understanding is that we've been trying to >> reduce board specific code from the kernel. > > That's not really the question, because that question assumes that it > isn't already present, which is not true. The code is already present. > The question is how to deal with this from the DT perspective. Yes. As I commented in this (or the other thread), I'm looking for a proper generic solution which can be recommended for all new boards. When we know what that is, we can see if and how that could fit into Versatile's case. Versatile is not the only board with the exact same problem. I wouldn't be at all surprised if the final solution is to just go with Linus' current patches for Versatile, as everything else would break compatibility or be overly complex. But I cannot accept that as a general solution for all similar cases going forward, especially when moving to DRM world, that's just bad SW design. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
