Re: (EXT) Re: [RFC][PATCH] Revert "drm/panel-simple: drop use of data-mapping property"

From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>,
	linux-arm-kernel@lists.infradead.org,
	dri-devel@lists.freedesktop.org, Marek Vasut <marex@denx.de>,
	Sam Ravnborg <sam@ravnborg.org>,
	Maxime Ripard <mripard@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: (EXT) Re: [RFC][PATCH] Revert "drm/panel-simple: drop use of data-mapping property"
Date: Thu, 03 Feb 2022 09:01:56 +0100	[thread overview]
Message-ID: <3046941.irdbgypaU6@steina-w> (raw)
In-Reply-To: <YfsXt1lU6l9cSctX@pendragon.ideasonboard.com>

Hi Laurent,

Am Donnerstag, 3. Februar 2022, 00:45:59 CET schrieb Laurent Pinchart:
> [...]
> You're right that there's an issue, but a revert isn't the right option.
> The commit you're reverting never made it in a stable release, because
> it was deemed to not be a good enough option.
> 
> First of all, any attempt to fix this should include an update to the DT
> binding. Second, as this is about DPI panels, the LVDS option should be
> dropped. Finally, I've shared some initial thoughts in [1], maybe you
> can reply to that e-mail to continue the discussion there ?
> 
> https://lore.kernel.org/all/20200303185531.GJ11333@pendragon.ideasonboard.co
> m/

At first I thought, this is a different issue than the one I currently have, 
but after reading this post, I think it's somewhat related.

> If a panel expects RGB888 and receives RGB666 with the two LSBs of each
> component hardwired to GND on the PCB, should DT report RGB888 or RGB666
> on the panel side ? I'm tempted by the former, and specifying the latter
> on the transmitting side.

My situation is the other way around. My panel (cdtech,s070swv29hg-dc44) has a 
MEDIA_BUS_FMT_RGB666_1X18 bus format (see panel-simple.c). Unfortunately for 
one mainboard the connection is like that:

i.MX -- Panel  (Blue and green is identical)
R7   --  R5
R6   --  R4
...
R2   --  R0
R1  dont care
R0  dont care

So the 8 bpc (imx) and 6 bps (panel) are MSB aligned. The 2 LSB are completely 
ignored.
The fast hacked fix is to use an additional panel description with bus format 
set to MEDIA_BUS_FMT_RGB888_1X24, keeping everything else the same. But that 
is cumbersome.
IMHO a straight forward solution is to use a, yet to be written, simple bridge 
which just converts the bus format transparently, assuming the electrical 
connection is actually correct.
This way the panel can set the native bus format, regardless of actual 
connections.
Christoph's problem should disappear as well if going that way, as the bus 
format is set for the <imx> -> <bridge> connection.
Nevertheless the panel bus format should be available in the end.

Regards,
Alexander

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