Re: [PATCH 3/5] dt-bindings: display: simple-bridge: Document DPI color encoder

Maxime Ripard
2025-03-06T11:35:52Z

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

On Thu, Mar 06, 2025 at 03:02:41PM +0800, Liu Ying wrote:
> On 03/06/2025, Rob Herring wrote:
> > On Wed, Mar 05, 2025 at 10:35:26AM +0100, Alexander Stein wrote:
> >> Hi,
> >>
> >> Am Dienstag, 4. März 2025, 16:23:20 CET schrieb Rob Herring:
> >>> On Tue, Mar 04, 2025 at 06:15:28PM +0800, Liu Ying wrote:
> >>>> A DPI color encoder, as a simple display bridge, converts input DPI color
> >>>> coding to output DPI color coding, like Adafruit Kippah DPI hat[1] which
> >>>> converts input 18-bit pixel data to 24-bit pixel data(with 2 low padding
> >>>> bits in every color component though). Document the DPI color encoder.
> >>>
> >>> Why do we need a node for this? Isn't this just wired how it is wired
> >>> and there's nothing for s/w to see or do? I suppose if you are trying to
> >>> resolve the mode with 24-bit on one end and 18-bit on the other end, you
> >>> need to allow that and not require an exact match. You still might need
> >>> to figure out which pins the 18-bit data comes out on, but you have that
> >>> problem with an 18-bit panel too. IOW, how is this any different if you
> >>> have an 18-bit panel versus 24-bit panel?
> >>
> >> Especially panel-simple.c has a fixed configuration for each display, such as:
> >>> .bus_format = MEDIA_BUS_FMT_RGB666_1X18
> >>
> >> How would you allow or even know it should be addressed as
> >> MEDIA_BUS_FMT_RGB888_1X24 instead? I see different ways:
> >> 1. Create a new display setting/compatible
> >> 2. Add an overwrite property to the displays
> >> 3. Use a (transparent) bridge (this series)
> >>
> >> Number 1 is IMHO out of question.
> >
> > Agreed.
> >
> >> I personally don't like number 2 as this
> >> feels like adding quirks to displays, which they don't have.
> >
> > This is what I would do except apply it to the controller side. We know
> > the panel side already. This is a board variation, so a property makes
> > sense. I don't think you need any more than knowing what's on each end.
>
> With option 2, no matter putting a property in source side or sink side,
> impacted display drivers and DT bindings need to be changed, once a board
> manipulates the DPI color coding. This adds burdens and introduces new
> versions of those DT bindings. Is this what we want?

There's an option 4: make it a property of the OF graph endpoints. In
essence, it's similar to properties that are already there like
lane-mapping, and it wouldn't affect the panel drivers, or create an
intermediate bridge.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]