| Message ID | 20201007012438.27970-4-laurent.pinchart@ideasonboard.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm: mxsfb: Allow overriding bus width | expand |
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
On Wed, 07 Oct 2020 04:24:34 +0300, Laurent Pinchart wrote: > When the PCB routes the display data signals in an unconventional way, > the output bus width may differ from the bus width of the connected > panel or encoder. 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], the output bus width is 24 instead of 18 when the > signals are routed to LCD_DATA[5:0], LCD_DATA[11:6] and LCD_DATA[17:12]. > > Add a bus-width property to describe this data routing. > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > --- > Changes since v1: > > - Fix property name in binding > --- > .../devicetree/bindings/display/fsl,lcdif.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > Reviewed-by: Rob Herring <robh@kernel.org>
Hi Marek, 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).
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.
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.
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 ?
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 404bd516b7f5..14b6103a9bd1 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -58,6 +58,18 @@ properties: type: object properties: + 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. + remote-endpoint: $ref: /schemas/types.yaml#/definitions/phandle
When the PCB routes the display data signals in an unconventional way, the output bus width may differ from the bus width of the connected panel or encoder. 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], the output bus width is 24 instead of 18 when the signals are routed to LCD_DATA[5:0], LCD_DATA[11:6] and LCD_DATA[17:12]. Add a bus-width property to describe this data routing. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- Changes since v1: - Fix property name in binding --- .../devicetree/bindings/display/fsl,lcdif.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+)