On 17/02/16 23:32, Russell King - ARM Linux wrote:
> On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
>> As Russell points out: it's a register that contains a number saying what
>> panel is connected.
>>
>> So it is plug-n-play and I want to preserve this in the patch.
>>
>> The alternative is to make one DTS per display type connected, but that is
>> loosing all the nice plug'n'play :(
> 
> That's totally insane: we're talking about what's plugged in through
> an external connector.  It's not an "internal" device connector.
> These displays are external separate boxes to the board.
> 
> We don't have separate DT files just because we plugged in a USB device
> to a board., or a SDIO card, or an external HDD.

That's because USB, SDIO, HDD are all standard piece of HW, and any
probing can be done via the bus.

For panels we need DT fragments. The question is where these fragments
are and, possibly, who who loads them.

>> But if an overlay can do the same, I'm game for it.
> 
> That's rather eww, because that means you need to either build the
> overlay into the kernel (which IIRC then ties the base DT file to
> that exact kernel) or it needs to sit in userland, which means no
> LCD display until userland is up and running.  It doesn't sound very
> satisfactory, IMHO.

I don't think there are any satisfactory solutions to this.

For me the eww'est option is what this patch does, adding lots of panels
to the .dts, even if the panels are not connected, and having a board
specific fbdev driver. On the other hand, it's easy solution.

One a bit more general question here is: who should know the details of
the board? Is it the bootloader, kernel or userspace? I think the aim
has been to make the kernel drivers generic, not board specific. If so,
it hints either towards the bootloader or userspace. If userspace, the
panels will only be enabled later, when userspace is up.

In my opinion the best option would be to use DT overlays, but so that
the bootloader would supply them, or construct the dtb. But afaik that's
not possible at the moment. And perhaps I think that's the best option
only because I don't work with the bootloaders =).

So, I don't like this, but I don't have a good suggestion how to do it
better with the infrastructure in place at the moment.

We (TI) are struggling with the same problem at the moment (we don't
even have detection capability in all cases), and so far I've refused to
start adding board specific hacks to the display drivers. So I'm very
interested to find a good solution to this too.

 Tomi