On 10/13/20 4:06 AM, Laurent Pinchart wrote: > 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. So, should the IPUv3 be fixed as well then ?
