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

[Liu Ying]

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?

> 
>> Number 3 actually describe the hardware connection. The only impact for
>> software is to know which bus format it should use.
> 
> I'm not opposed to this, but only if it provides *something* that option 
> 2 does not. I'm not seeing what that is.

Option 3 provides an intermediate bridge for both DT and OSes.  It makes
the DPI color coding manipulation transparent to source side and sink side.

> 
> Node or not, either case needs a format property. We already have a 
> variety of bus/pixel format related properties. I've rejected new ones 
> because we need something common here that's flexible enough to handle 
> any situation. That's either something that can describe any bit layout 
> or something enumerating the formats (as MEDIA_BUS_FMT_* does). The 
> former is hard to get right and there's always something else you can't 
> handle. I'm not opposed to just reusing MEDIA_BUS_FMT_ if that works.

Agree that the former is hard to get right.

Since this is all about DPI and we have that MIPI DPI standard document
which specifies color codings, maybe it's fine to start with those limited
color codings.

BTW, I'd admit that the artificial paddings are not described by this patch
set, though maybe no one cares about that.  The paddings could be floating/
low/high/other component bits.

> 
> Rob

-- 
Regards,
Liu Ying