Re: [PATCH v3 2/4] dt-bindings: display: add new bus-format property for panel-dpi

[Marek Vasut]

On 8/8/22 15:56, Max Krummenacher wrote:
> Hi Marek

Hello Max,

[...]

> > > +        properties:
> > > +          bus-format:
> > > +            $ref: /schemas/types.yaml#/definitions/uint32
> > > +            minimum: 0x1001
> > > +            maximum: 0x1fff
> > > +            description: |
> > > +              Describes how the display panel is connected to the display interface.
> > > +              Valid values are defined in <dt-bindings/display/dt-media-bus-format.h>.
> > > +              The mapping between the color/significance of the panel lines to the
> > > +              parallel data lines are defined in:
> > > +              https://www.kernel.org/doc/html/v5.17/userspace-api/media/v4l/subdev-formats.html#packed-rgb-formats
> >
> > I am not sure whether I should re-open this discussion, but I still
> > wonder, wouldn't it be better to describe the DPI bus color channel
> > ordering (RGB, BGR, ...), width of each color channel in bits, pixel
> > format (RGB, YUV, ...) instead of using specific constants for the
> > entire format ?
>
> > From a system view it would be hard to define that structure which
> will catch any and all future requirements. Assume that there will be
> 3D panels and they will need an additional depth field.

You can very much say you have panels which require Y/U/V color channels 
instead of R/G/B , and then just add more color channels as needed. But 
that -- color channel, their order, offset, bit width, can be described 
rather easily, something like:

color-channel-names = "R", "G", "B";
color-channel-width = <8 8 8>;
color-channel-shift = <16 8 0>;

> Or in
> in addition to RGB data there will be a fourth color component. Or
> whatever the panel manufacturers might come up with...
> Or consider the Tegra 30 example I brought up in this thread. Tegras can
> output RGB666 for 18bit panels, and then use the next 8 bits to extend
> to 24bit (Maybe RGB666RGB222 ?).

I think there are two options here:

1) Look at 'data-lanes' property on DSI ? Both the DSI host and DSI
   device define the 'data-lanes' property per endpoint and they might
   not be the same.

But with DPI, the better option might be:

2) Implement something like LVDS codec, some sort of transparent DPI
   bridge driver which can be defined in DT and represent the "glue"
   wiring adapter between the mismatched DPI source and sink formats.

> https://lore.kernel.org/all/71ef1b35301330d0bbb64844247b6c4c2237ad1c.camel@xxxxxxxxx/
> If such requirements pop up the enumeration can be extended with a new
> value without changing the binding in any way, with a structured
> approach this will require changed bindings, maybe even with issues
> in backward compatibility.

If we have 2) which would describe how the DPI wires were connected, 
like "channel R got shifted by two bits, bottom two bits got replicated, 
etc.", then maybe we can avoid introducing new non-standard formats 
altogether ?

> > From an implementation perspective for Linux the busformat in code is
> currently an enumeration. So one would have to take the device tree
> structured busformat and run it through a potentially complicated
> function to get to the Linux busformat enumeration value. The final
> consumer has no advantage over what is there today.
>
> IMHO a change away from one enumeration value to a structured approach
> creates some drawbacks without any obvious advantages.
>
> Comments, other views on that?

See above.