| Message ID | 20230330095941.428122-4-francesco@dolcini.it (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/bridge: tc358768: Improve parallel RGB input configuration | expand |
On 30/03/2023 11:59, Francesco Dolcini wrote: > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > Add new toshiba,input-rgb-mode property to describe the actual signal > connection on the parallel RGB input interface. > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > --- > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > index 8f22093b61ae..2638121a2223 100644 > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > @@ -42,6 +42,21 @@ properties: > clock-names: > const: refclk > > + toshiba,input-rgb-mode: > + description: | > + Parallel Input (RGB) Mode. > + > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > + and in the table below. > + > + 0 = R[7:0], G[7:0], B[7:0] RGB888? > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] Isn't this RGB565? Don't we have already properties like this? e.g. colorspace? Best regards, Krzysztof
On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > On 30/03/2023 11:59, Francesco Dolcini wrote: > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > connection on the parallel RGB input interface. > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > --- > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > index 8f22093b61ae..2638121a2223 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > @@ -42,6 +42,21 @@ properties: > > clock-names: > > const: refclk > > > > + toshiba,input-rgb-mode: > > + description: | > > + Parallel Input (RGB) Mode. > > + > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > + and in the table below. > > + > > + 0 = R[7:0], G[7:0], B[7:0] > > RGB888? Or anything else - like a RGB666 - just connecting to GND the unused pins. > > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] > > Isn't this RGB565? > > Don't we have already properties like this? e.g. colorspace? It's not really the colorspace this property. tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input line. The way this lines are connected is configurable with this parameter, if you look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a RGB565 mapping. This just configure some internal mux, it's not strictly about the RGB mode. The description for mode 2 was copied from the datasheet, and I agree this is really about having a RGB565 on the first 16 parallel input pins. Honestly I do not know what is going to happen with PD[23-16] if they are not connected to GND, given that the component does not know the parallel input bus width it might as well sample those pins in some un-documented way. Francesco
On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > connection on the parallel RGB input interface. > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > --- > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > 1 file changed, 15 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > index 8f22093b61ae..2638121a2223 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > @@ -42,6 +42,21 @@ properties: > > > clock-names: > > > const: refclk > > > > > > + toshiba,input-rgb-mode: > > > + description: | > > > + Parallel Input (RGB) Mode. > > > + > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > + and in the table below. > > > + > > > + 0 = R[7:0], G[7:0], B[7:0] > > > > RGB888? > > Or anything else - like a RGB666 - just connecting to GND the unused > pins. If the bridge is configured for RGB666, then that's fine. If not, the unused pins should be driven with either the MSB of each component. Otherwise, you'd can't fully saturate the colors. > > > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > > > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] > > > > Isn't this RGB565? > > > > Don't we have already properties like this? e.g. colorspace? > > It's not really the colorspace this property. > > tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input > line. > > The way this lines are connected is configurable with this parameter, if you > look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a > RGB565 mapping. This just configure some internal mux, it's not strictly > about the RGB mode. This is the same as other cases. There's a need for describing the interface. It keeps coming up and I keep saying to go create something common. Rob
On Mon, Apr 03, 2023 at 04:01:17PM -0500, Rob Herring wrote: > On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > > connection on the parallel RGB input interface. > > > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > --- > > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > > 1 file changed, 15 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > index 8f22093b61ae..2638121a2223 100644 > > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > @@ -42,6 +42,21 @@ properties: > > > > clock-names: > > > > const: refclk > > > > > > > > + toshiba,input-rgb-mode: > > > > + description: | > > > > + Parallel Input (RGB) Mode. > > > > + > > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > > + and in the table below. > > > > + > > > > + 0 = R[7:0], G[7:0], B[7:0] > > > > > > RGB888? > > > > Or anything else - like a RGB666 - just connecting to GND the unused > > pins. > > If the bridge is configured for RGB666, then that's fine. If not, the > unused pins should be driven with either the MSB of each component. > Otherwise, you'd can't fully saturate the colors. > > > > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > > > > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] > > > > > > Isn't this RGB565? > > > > > > Don't we have already properties like this? e.g. colorspace? > > > > It's not really the colorspace this property. > > > > tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input > > line. > > > > The way this lines are connected is configurable with this parameter, if you > > look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a > > RGB565 mapping. This just configure some internal mux, it's not strictly > > about the RGB mode. > > This is the same as other cases. There's a need for describing the > interface. It keeps coming up and I keep saying to go create something > common. I am not aware of other discussion on the topic, do you have any pointer I can look at? What I'd like to re-iterate here once more is that this configuration is about how the external 24-bit parallel RGB lines are mapped withing this bridge. It's not mapping the linux media bus format (e.g. not MEDIA_BUS_FMT_RBG888_1X24 or alike). This bridge allow for a limited set of combination (3) as described in this binding. Francesco
On Mon, Apr 03, 2023 at 04:01:17PM -0500, Rob Herring wrote: > On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > > connection on the parallel RGB input interface. > > > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > --- > > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > > 1 file changed, 15 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > index 8f22093b61ae..2638121a2223 100644 > > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > @@ -42,6 +42,21 @@ properties: > > > > clock-names: > > > > const: refclk > > > > > > > > + toshiba,input-rgb-mode: > > > > + description: | > > > > + Parallel Input (RGB) Mode. > > > > + > > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > > + and in the table below. > > > > + > > > > + 0 = R[7:0], G[7:0], B[7:0] > > > > > > RGB888? > > > > Or anything else - like a RGB666 - just connecting to GND the unused > > pins. > > If the bridge is configured for RGB666, then that's fine. If not, the > unused pins should be driven with either the MSB of each component. > Otherwise, you'd can't fully saturate the colors. maybe a detail and maybe not really relevant, but this specific bridge has no know-how on the actual RGB inputs width. While I understand what you are saying here, in the end this is about the actual hardware design that can be in any way, including having pins to gnd and have the issue you just described. Francesco
Hello Rob and Krzysztof On Mon, Apr 03, 2023 at 04:01:17PM -0500, Rob Herring wrote: > On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > > connection on the parallel RGB input interface. > > > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > --- > > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > > 1 file changed, 15 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > index 8f22093b61ae..2638121a2223 100644 > > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > @@ -42,6 +42,21 @@ properties: > > > > clock-names: > > > > const: refclk > > > > > > > > + toshiba,input-rgb-mode: > > > > + description: | > > > > + Parallel Input (RGB) Mode. > > > > + > > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > > + and in the table below. > > > > + > > > > + 0 = R[7:0], G[7:0], B[7:0] > > tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input > > line. > > > > The way this lines are connected is configurable with this parameter, if you > > look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a > > RGB565 mapping. This just configure some internal mux, it's not strictly > > about the RGB mode. > > This is the same as other cases. There's a need for describing the > interface. It keeps coming up and I keep saying to go create something > common. Rob, Krzysztof: you both had concerns on this change and I am not sure how to progress. Let me summarize my current understanding. 1. I do not think that this change is related to the media bus format topic, this is more like the internal bridge RGB pins mux configuration. This `input-rgb-mode` field I am proposing here is orthogonal to the bus format (e.g. linux media-bus-format.h). I can change the name, if we think this is the reason of the confusion, I just used something similar to the words used in the datasheet. Do we have agreement on that or not? 2. Rob asked for a generic solution, since according to him this is a recurring need. I would appreciate some pointer where to look at so I can propose something more generic. Thanks, Francesco
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index 8f22093b61ae..2638121a2223 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -42,6 +42,21 @@ properties: clock-names: const: refclk + toshiba,input-rgb-mode: + description: | + Parallel Input (RGB) Mode. + + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet + and in the table below. + + 0 = R[7:0], G[7:0], B[7:0] + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] + 2 = 8’b0, R[4:0], G[5:0], B[4:0] + + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2 ] + default: 0 + ports: $ref: /schemas/graph.yaml#/properties/ports