Hi Marek On Wed, Aug 3, 2022 at 10:21 AM Marek Vasut <marex@xxxxxxx> wrote: > > On 6/28/22 20:18, Max Krummenacher wrote: > > Hello Max, > > [...] > > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > index dae0676b5c6e..52f5db03b6a8 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml > > @@ -26,7 +26,28 @@ properties: > > height-mm: true > > label: true > > panel-timing: true > > - port: true > > + > > + port: > > + $ref: /schemas/graph.yaml#/$defs/port-base > > + description: > > + Input port node, receives the panel data. > > + > > + properties: > > + endpoint: > > + $ref: /schemas/graph.yaml#/$defs/endpoint-base > > + > > + 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. 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 ?). 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. >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? Regards Max
