On 2018-08-15 17:04, Daniel Vetter wrote: > On Wed, Aug 15, 2018 at 4:45 PM, Rob Herring <robh@xxxxxxxxxx> wrote: >> On Tue, Aug 14, 2018 at 10:48 PM Sam Ravnborg <sam@xxxxxxxxxxxx> 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
