Re: [PATCH] drm/imx: parallel-display: Adjust bus_flags and bus_format handling

From: Boris Brezillon <boris.brezillon@collabora.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Marek Vasut <marex@denx.de>, David Airlie <airlied@linux.ie>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	dri-devel@lists.freedesktop.org,
	NXP Linux Team <linux-imx@nxp.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] drm/imx: parallel-display: Adjust bus_flags and bus_format handling
Date: Mon, 9 Mar 2020 20:55:59 +0100	[thread overview]
Message-ID: <20200309205559.3c860aae@collabora.com> (raw)
In-Reply-To: <20200309192306.GA20358@pendragon.ideasonboard.com>

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).

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel