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.
