Re: [PATCH v2 3/7] dt-bindings: display: mxsfb: Add a bus-width endpoint property

Hi Marek,

On Sat, Oct 10, 2020 at 10:47:05AM +0200, Marek Vasut wrote:

On 10/10/20 1:58 AM, Laurent Pinchart wrote:

...

Hi Marek,

Hi,

...

On Wed, Oct 07, 2020 at 10:40:26AM +0200, Marek Vasut wrote:

...

On 10/7/20 3:24 AM, Laurent Pinchart wrote:

[...]

...

•      bus-width:
  

•        enum: [16, 18, 24]
  

•        description: |
  

•          The output bus width. This value overrides the configuration
  

•          derived from the connected device (encoder or panel). It should
  

•          only be specified when PCB routing of the data signals require a
  

•          different bus width on the LCDIF and the connected device. For
  

•          instance, when a 18-bit RGB panel has its R[5:0], G[5:0] and
  

•          B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] and
  

•          LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] and
  

•          LCD_DATA[17:12], bus-width should be set to 24.
  

The iMX6 IPUv3 uses interface-pix-fmt which is a bit more flexible, but I'm not sure whether it's the right way to go about this, see: Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt

I think specifying the bus with is better. It's a standard property, but more than that, a given bus width can carry different formats. For instance, a 24-bus could carry RGB666 data (with dithering for the LSBs).

I think that's exactly what the interface-pix-fmt was trying to solve for the IPUv3, there you could have e.g. both RGB666 and LVDS666 , which were different.

My point is that the driver should support multiple formats that can be carried over a given bus width, with the actual format to be used queried from the sink (usually a panel) instead of being hardcoded in DT.