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. -- Regards, Laurent Pinchart
