Re: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree

On 24/02/16 12:46, Russell King - ARM Linux wrote:

On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:

quoted

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.

quoted

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.

quoted

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