On Mon, 9 Mar 2020 21:23:06 +0200 Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
On Mon, Mar 09, 2020 at 11:50:59AM +0100, Philipp Zabel wrote:
On Thu, 2019-11-14 at 14:17 +0100, Marek Vasut wrote:
The bus_flags and bus_format handling logic does not seem to cover all potential usecases. Specifically, this seems to fail with an "edt,etm0700g0edh6" display attached to an 24bit display interface, with interface-pix-fmt = "rgb24" set in DT.
interface-pix-fmt is a legacy property that was never intended to be used as an override for the panel bus format. The bus flags were supposed to be set from the display-timings node, back when there was no of-graph connected panel at all.
That being said, there isn't really a proper alternative that allows to override the bus format requested by the panel driver in the device tree to account for weird wiring. We could reuse the bus-width endpoint property documented in [1], but that wouldn't completely specify how the RGB components are to be mapped onto the parallel bus.
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
Things are funny sometimes, I've run into the exact same problem with a different display controller today.
Shouldn't we use the data-shift property from [1] to specify this ? Combined with Boris' bus format negotiation for bridges, I think we would have all the components in place to solve this problem properly.
I wonder if we shouldn't take more complex pin mappings into account now and go directly for a data-mapping property describing those mappings using a string. This way we'd have a single property that would work for both fully parallel buses (DPI/RGB) and serial (or partially parallel) ones (LVDS).