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

[Laurent Pinchart]

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