[RFC PATCH 0/7] add at91sam9 LCDC DRM driver

[Peter Rosin]

On 2018-08-15 17:04, Daniel Vetter wrote:
> On Wed, Aug 15, 2018 at 4:45 PM, Rob Herring <robh at kernel.org> wrote:
>> On Tue, Aug 14, 2018 at 10:48 PM Sam Ravnborg <sam at ravnborg.org> wrote:
>>>
>>
>> [...]
>>
>>>>> One DT related Q:
>>>>> The LCD Controller supports BGR565, but as this is less common some HW implmentations
>>>>> exchange R and B, expessed in the old binding as wiring-mode like this:
>>>>>
>>>>>     atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
>>>>>
>>>>> How can we express this wiring-mode in a generic way, both in DT and in code?
>>>>> Is it something that in DRM belongs to the panel, the encoder, the connector, or?
>>>>> And can any of the exisitng flags be used?
>>>>
>>>> I thought we had come up with a common definition, but I guess it didn't
>>>> make it upstream. It's definitely needed and I've been rejecting
>>>> anything new that's vendor specific.
>>> I found this: https://patchwork.ozlabs.org/patch/659570/
>>> The suggestion with a boolean seems simple and I will try that.
>>
>> That's really too simple to be common. There's been a few other
>> attempts[1][2][3] (for Atmel HLCDC in fact) with [3] probably being
>> the closest to merging. The binding looked fine to me, but looks like
>> the DRM implementation had some issues.
>>
>> Rob
>>
>> [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173089.html
>> [2] https://patchwork.kernel.org/patch/9965079/
>> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/568731.html
> 
> There's a standardized bus_format for drm_panel. IIrc there's been
> discussions to add something similar to drm_bridge, but didn't go all
> that far for reasons.
> 
> Lots of drivers just handle this internally in some way. So no idea
> why this all got stalled.

I stopped pushing that patch for reasons mentioned in
https://lkml.org/lkml/2018/4/9/108

However, since then, the component approach mentioned in that mail was
shot down and instead the tda998x driver is now a bridge (or soon, I expect
the series from Russell King that to land in 4.19-rc1) which means that the
binding from that series is back on the table. At least I guess so? However,
in that series the approach is that the bridge states its expected input and
the output then adjusts to what is needed. However, the "problem" is really in
the atmel-hlcdc output (it moves the MSB for the RGB colors around depending
on the output mode) so I no longer subscribe to all ideas in that series
and think it is cleaner to state the needed bus format closer to the atmel-
hlcdc endpoint as is done e.g. in this latest series:

https://lkml.org/lkml/2018/8/10/309

This latest series uses the media/video-interface approach and specifies
the bus-width in the endpoint. However, the bus-width is alone obviously not
enough to differentiate rgb565 and brg565, so will not help Sam (or is it
bgr565 that Sam needs? The above quoted text is ambiguous).

I think something like my bus-format binding in [3] is generic enough to
also help Sam.

Cheers,
Peter