diff mbox series

[v1,3/6] dt-bindings: display: bridge: toshiba, tc358768: add parallel input mode

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

Commit Message

Francesco Dolcini March 30, 2023, 9:59 a.m. UTC
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(+)

Comments

Krzysztof Kozlowski March 31, 2023, 8:48 a.m. UTC | #1
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
Francesco Dolcini March 31, 2023, 9:40 a.m. UTC | #2
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
Rob Herring April 3, 2023, 9:01 p.m. UTC | #3
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
Francesco Dolcini April 3, 2023, 9:10 p.m. UTC | #4
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
Francesco Dolcini April 3, 2023, 9:20 p.m. UTC | #5
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
Francesco Dolcini April 14, 2023, 8:42 a.m. UTC | #6
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 mbox series

Patch

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