[v3,02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation
diff mbox series

Message ID 20190528141234.15425-3-laurent.pinchart+renesas@ideasonboard.com
State New
Delegated to: Kieran Bingham
Headers show
Series
  • R-Car DU: LVDS dual-link mode support
Related show

Commit Message

Laurent Pinchart May 28, 2019, 2:12 p.m. UTC
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
dual-link. In dual-link mode both input ports are used to carry even-
and odd-numbered pixels separately. Document this in the DT bindings,
along with the related rules governing port and usage.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Kieran Bingham June 7, 2019, 10:15 p.m. UTC | #1
Hi Laurent,

On 28/05/2019 15:12, Laurent Pinchart wrote:
> The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
> dual-link. In dual-link mode both input ports are used to carry even-
> and odd-numbered pixels separately. Document this in the DT bindings,
> along with the related rules governing port and usage.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> index 37f0c04d5a28..d17d1e5820d7 100644
> --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -28,6 +28,12 @@ Optional video port nodes:
>  - port@1: Second LVDS input port
>  - port@3: Second digital CMOS/TTL parallel output
>  
> +The device can operate in single-link mode or dual-link mode. In single-link
> +mode, all pixels are received on port@0, and port@1 shall not contain any
> +endpoint. In dual-link mode, even-numbered pixels are received on port@0 and
> +odd-numbered pixels on port@1, and both port@0 and port@1 shall contain
> +endpoints.
> +

Your cover letter details 4 different modes of operation for this part.

Do you anticipate the other combinations {Single-in, dual-out; dual-in,
dual-out} being supported? Perhaps that would be defined by the relevant
endpoints being connected or not ?


You state that in dual-link mode, both port@0, and port@1 shall contain
endpoints, so that implies that you only expect to support dual-in with
the 'dual-link' property. If that is correct, should it be stated
explicitly?


Otherwise,

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>


>  Example:
>  --------
>  
>
Laurent Pinchart June 7, 2019, 10:30 p.m. UTC | #2
Hi Kieran,

On Fri, Jun 07, 2019 at 11:15:06PM +0100, Kieran Bingham wrote:
> On 28/05/2019 15:12, Laurent Pinchart wrote:
> > The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
> > dual-link. In dual-link mode both input ports are used to carry even-
> > and odd-numbered pixels separately. Document this in the DT bindings,
> > along with the related rules governing port and usage.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > index 37f0c04d5a28..d17d1e5820d7 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -28,6 +28,12 @@ Optional video port nodes:
> >  - port@1: Second LVDS input port
> >  - port@3: Second digital CMOS/TTL parallel output
> >  
> > +The device can operate in single-link mode or dual-link mode. In single-link
> > +mode, all pixels are received on port@0, and port@1 shall not contain any
> > +endpoint. In dual-link mode, even-numbered pixels are received on port@0 and
> > +odd-numbered pixels on port@1, and both port@0 and port@1 shall contain
> > +endpoints.
> > +
> 
> Your cover letter details 4 different modes of operation for this part.
> 
> Do you anticipate the other combinations {Single-in, dual-out; dual-in,
> dual-out} being supported? Perhaps that would be defined by the relevant
> endpoints being connected or not ?

I expect that someone might need those modes at some point, but I
haven't specified them on purpose, as I don't like writing DT bindings
that can't be tested. I however expoect that those additional modes can
be derived from the connected endpoints.

> You state that in dual-link mode, both port@0, and port@1 shall contain
> endpoints, so that implies that you only expect to support dual-in with
> the 'dual-link' property. If that is correct, should it be stated
> explicitly?

What do you mean by the 'dual-link' property ? The patch series defines
no such property.

> Otherwise,
> 
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> 
> >  Example:
> >  --------
> >
Kieran Bingham June 7, 2019, 10:36 p.m. UTC | #3
Hi Laurent,

On 07/06/2019 23:30, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Fri, Jun 07, 2019 at 11:15:06PM +0100, Kieran Bingham wrote:
>> On 28/05/2019 15:12, Laurent Pinchart wrote:
>>> The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
>>> dual-link. In dual-link mode both input ports are used to carry even-
>>> and odd-numbered pixels separately. Document this in the DT bindings,
>>> along with the related rules governing port and usage.
>>>
>>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>> ---
>>>  .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> index 37f0c04d5a28..d17d1e5820d7 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -28,6 +28,12 @@ Optional video port nodes:
>>>  - port@1: Second LVDS input port
>>>  - port@3: Second digital CMOS/TTL parallel output
>>>  
>>> +The device can operate in single-link mode or dual-link mode. In single-link
>>> +mode, all pixels are received on port@0, and port@1 shall not contain any
>>> +endpoint. In dual-link mode, even-numbered pixels are received on port@0 and
>>> +odd-numbered pixels on port@1, and both port@0 and port@1 shall contain
>>> +endpoints.
>>> +
>>
>> Your cover letter details 4 different modes of operation for this part.
>>
>> Do you anticipate the other combinations {Single-in, dual-out; dual-in,
>> dual-out} being supported? Perhaps that would be defined by the relevant
>> endpoints being connected or not ?
> 
> I expect that someone might need those modes at some point, but I
> haven't specified them on purpose, as I don't like writing DT bindings
> that can't be tested. I however expoect that those additional modes can
> be derived from the connected endpoints.
> 
>> You state that in dual-link mode, both port@0, and port@1 shall contain
>> endpoints, so that implies that you only expect to support dual-in with
>> the 'dual-link' property. If that is correct, should it be stated
>> explicitly?
> 
> What do you mean by the 'dual-link' property ? The patch series defines
> no such property.

Aha, my imagination is creating something from all the references to the
word 'dual-link' :-D

Ok - so it is just the existence of the endpoints which will
enable//configure the various modes of operation.

I guess that will become more clear when I get down to the driver patches :)



> 
>> Otherwise,
>>
>> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>>
>>>  Example:
>>>  --------
>>>  
>

Patch
diff mbox series

diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
index 37f0c04d5a28..d17d1e5820d7 100644
--- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -28,6 +28,12 @@  Optional video port nodes:
 - port@1: Second LVDS input port
 - port@3: Second digital CMOS/TTL parallel output
 
+The device can operate in single-link mode or dual-link mode. In single-link
+mode, all pixels are received on port@0, and port@1 shall not contain any
+endpoint. In dual-link mode, even-numbered pixels are received on port@0 and
+odd-numbered pixels on port@1, and both port@0 and port@1 shall contain
+endpoints.
+
 Example:
 --------