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.
