On Tue, 25 Feb 2020 07:15:43 +0100 Sam Ravnborg sam@ravnborg.org wrote:
Hi Boris/Laurent.
- err = of_property_read_u32(np, "bus-width", &input_bus_width);
- of_node_put(np);
- if (err) {
lvds_codec->input_fmt = MEDIA_BUS_FMT_FIXED;- } else if (input_bus_width == 18) {
lvds_codec->input_fmt = MEDIA_BUS_FMT_RGB666_1X18;- } else if (input_bus_width == 24) {
lvds_codec->input_fmt = MEDIA_BUS_FMT_RGB888_1X24;- } else {
dev_dbg(dev, "unsupported bus-width value %u on port 0\n",input_bus_width);return -ENOTSUPP;ENOTSUPP is "Operation not supported", I'd go for -EINVAL.
- }
Doesn't this apply to LVDS encoders only ? For LVDS decoders I don't think we want to report an RGB format on the input.
In panel-lvds we use the property "data-mapping" for the same purpose. To specify the MEDIA_BUS format.
I started with data-mapping, and was told (by Laurent IIRC) that bus-width would be more appropriate for a DPI (AKA RGB) bus. I think it has to do with the fact that fully-parallel buses always have one color bit per-signal, while serial or partially-parallel buses can have several color-bits per-signal, the assignment being described by this 'data-mapping' property. This being said, I can see a case where data-mapping would be needed for DPI buses => RGB component ordering. A 24bit bus does not distinguish between RGB888 and BGR888.
It would be good to standardize on the same property, and maybe have the same binding descriptions for all.
As for the standardization, I'm all for it, but let's do that in a second step, please.