Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Thu, Apr 5, 2018 at 1:53 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote:
>> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote:
>> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 01:10 PM, jacopo mondi wrote:
>> >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>>  On 03/27/2018 11:57 AM, jacopo mondi wrote:
>> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
>> >>> [...]
>> >>>
>> > Document Thine THC63LVD1024 LVDS decoder device tree
>> > bindings.
>> >
>> > Signed-off-by: Jacopo Mondi 
>> > Reviewed-by: Andrzej Hajda 
>> > Reviewed-by: Niklas Söderlund
>> > 
>> > ---
>> >
>> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
>> >   1 file changed, 66 insertions(+)
>> >   create mode 100644
>> >
>> > Documentation/devicetree/bindings/display/bridge/thine,thc63l
>> > vd1024.txt
>> > diff --git
>> > a/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > new file mode 100644
>> > index 000..8225c6a
>> > --- /dev/null
>> > +++
>> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > @@ -0,0 +1,66 @@
>> > +Thine Electronics THC63LVD1024 LVDS decoder
>> > +---
>> > +
>> > +The THC63LVD1024 is a dual link LVDS receiver designed to
>> > convert LVDS streams
>> > +to parallel data outputs. The chip supports single/dual
>> > input/output modes,
>> > +handling up to two two input LVDS stream and up to two
>> > digital CMOS/TTL outputs.
>> > +
>> > +Single or dual operation modes, output data mapping and DDR
>> > output modes are
>> > +configured through input signals and the chip does not
>> > expose any control bus.
>> > +
>> > +Required properties:
>> > +- compatible: Shall be "thine,thc63lvd1024"
>> > +
>> > +Optional properties:
>> > +- vcc-supply: Power supply for TTL output and digital
>> > circuitry
>> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>> > +- lvcc-supply: Power supply for LVDS inputs
>> > +- pvcc-supply: Power supply for PLL circuitry
>> 
>>  As explained in a comment to one of the previous versions of
>>  this series, I'm tempted to make vcc-supply mandatory and drop
>>  the three other power supplies for now, as I believe there's
>>  very little chance they will be connected to separately
>>  controllable regulators (all supplies use the same voltage). In
>>  the very unlikely event that this occurs in design we need to
>>  support in the future, the cvcc, lvcc and pvcc supplies can be
>>  added later as optional without breaking backward
>>  compatibility.
>> >>>
>> >>> I'm okay with that.
>> >>>
>>  Apart from that,
>> 
>>  Reviewed-by: Laurent Pinchart
>>  
>> 
>> > +- pdwn-gpios: Power down GPIO signal. Active low
>> >>>
>> >>> powerdown-gpios is the semi-standard name.
>> >>
>> >> right, I've also noticed it. If possible please avoid
>> >> shortenings in property names.
>> >
>> > It is not shortening, it just follow pin name from decoder's
>> > datasheet.
>> >
>> > +- oe-gpios: Output enable GPIO signal. Active high
>> > +
>> >>
>> >> And this one is also a not ever met property name, please
>> >> consider to rename it to 'enable-gpios', for instance display
>> >> panels define it.
>> >
>> > Again, it follows datasheet naming scheme. Has something changed
>> > in DT conventions?
>> 
>>  Seconded. My understanding is that the property name should
>>  reflect what reported in the the chip manual. For THC63LVD1024 the
>>  enable and power down pins are named 'OE' and 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Thu, Apr 5, 2018 at 1:53 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote:
>> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote:
>> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 01:10 PM, jacopo mondi wrote:
>> >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>>  On 03/27/2018 11:57 AM, jacopo mondi wrote:
>> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
>> >>> [...]
>> >>>
>> > Document Thine THC63LVD1024 LVDS decoder device tree
>> > bindings.
>> >
>> > Signed-off-by: Jacopo Mondi 
>> > Reviewed-by: Andrzej Hajda 
>> > Reviewed-by: Niklas Söderlund
>> > 
>> > ---
>> >
>> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
>> >   1 file changed, 66 insertions(+)
>> >   create mode 100644
>> >
>> > Documentation/devicetree/bindings/display/bridge/thine,thc63l
>> > vd1024.txt
>> > diff --git
>> > a/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > new file mode 100644
>> > index 000..8225c6a
>> > --- /dev/null
>> > +++
>> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
>> > 3lvd1024.txt
>> > @@ -0,0 +1,66 @@
>> > +Thine Electronics THC63LVD1024 LVDS decoder
>> > +---
>> > +
>> > +The THC63LVD1024 is a dual link LVDS receiver designed to
>> > convert LVDS streams
>> > +to parallel data outputs. The chip supports single/dual
>> > input/output modes,
>> > +handling up to two two input LVDS stream and up to two
>> > digital CMOS/TTL outputs.
>> > +
>> > +Single or dual operation modes, output data mapping and DDR
>> > output modes are
>> > +configured through input signals and the chip does not
>> > expose any control bus.
>> > +
>> > +Required properties:
>> > +- compatible: Shall be "thine,thc63lvd1024"
>> > +
>> > +Optional properties:
>> > +- vcc-supply: Power supply for TTL output and digital
>> > circuitry
>> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>> > +- lvcc-supply: Power supply for LVDS inputs
>> > +- pvcc-supply: Power supply for PLL circuitry
>> 
>>  As explained in a comment to one of the previous versions of
>>  this series, I'm tempted to make vcc-supply mandatory and drop
>>  the three other power supplies for now, as I believe there's
>>  very little chance they will be connected to separately
>>  controllable regulators (all supplies use the same voltage). In
>>  the very unlikely event that this occurs in design we need to
>>  support in the future, the cvcc, lvcc and pvcc supplies can be
>>  added later as optional without breaking backward
>>  compatibility.
>> >>>
>> >>> I'm okay with that.
>> >>>
>>  Apart from that,
>> 
>>  Reviewed-by: Laurent Pinchart
>>  
>> 
>> > +- pdwn-gpios: Power down GPIO signal. Active low
>> >>>
>> >>> powerdown-gpios is the semi-standard name.
>> >>
>> >> right, I've also noticed it. If possible please avoid
>> >> shortenings in property names.
>> >
>> > It is not shortening, it just follow pin name from decoder's
>> > datasheet.
>> >
>> > +- oe-gpios: Output enable GPIO signal. Active high
>> > +
>> >>
>> >> And this one is also a not ever met property name, please
>> >> consider to rename it to 'enable-gpios', for instance display
>> >> panels define it.
>> >
>> > Again, it follows datasheet naming scheme. Has something changed
>> > in DT conventions?
>> 
>>  Seconded. My understanding is that the property name should
>>  reflect what reported in the the chip manual. For THC63LVD1024 the
>>  enable and power down pins are named 'OE' and 'PDWN' respectively.
>> >>>
>> >>> But don't we need the vendor prefix in the prop names then, like
>> >>> "renesas,oe-gpios" then?
>> >>
>> 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Laurent Pinchart]

Hi Rob,

On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote:
> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote:
> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> >> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>  On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> >>> [...]
> >>> 
> > Document Thine THC63LVD1024 LVDS decoder device tree
> > bindings.
> > 
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund
> > 
> > ---
> > 
> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
> >   1 file changed, 66 insertions(+)
> >   create mode 100644
> > 
> > Documentation/devicetree/bindings/display/bridge/thine,thc63l
> > vd1024.txt
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc6
> > 3lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
> > 3lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
> > 3lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to
> > convert LVDS streams
> > +to parallel data outputs. The chip supports single/dual
> > input/output modes,
> > +handling up to two two input LVDS stream and up to two
> > digital CMOS/TTL outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR
> > output modes are
> > +configured through input signals and the chip does not
> > expose any control bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital
> > circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>  
>  As explained in a comment to one of the previous versions of
>  this series, I'm tempted to make vcc-supply mandatory and drop
>  the three other power supplies for now, as I believe there's
>  very little chance they will be connected to separately
>  controllable regulators (all supplies use the same voltage). In
>  the very unlikely event that this occurs in design we need to
>  support in the future, the cvcc, lvcc and pvcc supplies can be
>  added later as optional without breaking backward
>  compatibility.
> >>> 
> >>> I'm okay with that.
> >>> 
>  Apart from that,
>  
>  Reviewed-by: Laurent Pinchart
>  
>  
> > +- pdwn-gpios: Power down GPIO signal. Active low
> >>> 
> >>> powerdown-gpios is the semi-standard name.
> >> 
> >> right, I've also noticed it. If possible please avoid
> >> shortenings in property names.
> > 
> > It is not shortening, it just follow pin name from decoder's
> > datasheet.
> > 
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> >> 
> >> And this one is also a not ever met property name, please
> >> consider to rename it to 'enable-gpios', for instance display
> >> panels define it.
> > 
> > Again, it follows datasheet naming scheme. Has something changed
> > in DT conventions?
>  
>  Seconded. My understanding is that the property name should
>  reflect what reported in the the chip manual. For THC63LVD1024 the
>  enable and power down pins are named 'OE' and 'PDWN' respectively.
> >>> 
> >>> But don't we need the vendor prefix in the prop names then, like
> >>> "renesas,oe-gpios" then?
> >> 
> >> Seconded, with a 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Laurent Pinchart]

Hi Rob,

On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote:
> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote:
> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> >> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>  On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> >>> [...]
> >>> 
> > Document Thine THC63LVD1024 LVDS decoder device tree
> > bindings.
> > 
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund
> > 
> > ---
> > 
> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
> >   1 file changed, 66 insertions(+)
> >   create mode 100644
> > 
> > Documentation/devicetree/bindings/display/bridge/thine,thc63l
> > vd1024.txt
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc6
> > 3lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
> > 3lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc6
> > 3lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to
> > convert LVDS streams
> > +to parallel data outputs. The chip supports single/dual
> > input/output modes,
> > +handling up to two two input LVDS stream and up to two
> > digital CMOS/TTL outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR
> > output modes are
> > +configured through input signals and the chip does not
> > expose any control bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital
> > circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>  
>  As explained in a comment to one of the previous versions of
>  this series, I'm tempted to make vcc-supply mandatory and drop
>  the three other power supplies for now, as I believe there's
>  very little chance they will be connected to separately
>  controllable regulators (all supplies use the same voltage). In
>  the very unlikely event that this occurs in design we need to
>  support in the future, the cvcc, lvcc and pvcc supplies can be
>  added later as optional without breaking backward
>  compatibility.
> >>> 
> >>> I'm okay with that.
> >>> 
>  Apart from that,
>  
>  Reviewed-by: Laurent Pinchart
>  
>  
> > +- pdwn-gpios: Power down GPIO signal. Active low
> >>> 
> >>> powerdown-gpios is the semi-standard name.
> >> 
> >> right, I've also noticed it. If possible please avoid
> >> shortenings in property names.
> > 
> > It is not shortening, it just follow pin name from decoder's
> > datasheet.
> > 
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> >> 
> >> And this one is also a not ever met property name, please
> >> consider to rename it to 'enable-gpios', for instance display
> >> panels define it.
> > 
> > Again, it follows datasheet naming scheme. Has something changed
> > in DT conventions?
>  
>  Seconded. My understanding is that the property name should
>  reflect what reported in the the chip manual. For THC63LVD1024 the
>  enable and power down pins are named 'OE' and 'PDWN' respectively.
> >>> 
> >>> But don't we need the vendor prefix in the prop names then, like
> >>> "renesas,oe-gpios" then?
> >> 
> >> Seconded, with a correction to "thine,oe-gpios".
> > 
> > mmm, okay then...
> > 
> > A grep for that semi-standard properties 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart
 wrote:
> Hi Vladimir,
>
> On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
>> On 03/27/2018 01:10 PM, jacopo mondi wrote:
>> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
>> >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>>  On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
>> > [...]
>> >
>> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>> >>>
>> >>> Signed-off-by: Jacopo Mondi 
>> >>> Reviewed-by: Andrzej Hajda 
>> >>> Reviewed-by: Niklas Söderlund
>> >>> 
>> >>> ---
>> >>>
>> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66
>> >>>   +++
>> >>>   1 file changed, 66 insertions(+)
>> >>>   create mode 100644
>> >>>
>> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1
>> >>> 024.txt
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
>> >>> d1024.txt
>> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
>> >>> d1024.txt
>> >>> new file mode 100644
>> >>> index 000..8225c6a
>> >>> --- /dev/null
>> >>> +++
>> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
>> >>> d1024.txt
>> >>> @@ -0,0 +1,66 @@
>> >>> +Thine Electronics THC63LVD1024 LVDS decoder
>> >>> +---
>> >>> +
>> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to
>> >>> convert LVDS streams
>> >>> +to parallel data outputs. The chip supports single/dual
>> >>> input/output modes, +handling up to two two input LVDS stream
>> >>> and up to two digital CMOS/TTL outputs.
>> >>> +
>> >>> +Single or dual operation modes, output data mapping and DDR
>> >>> output modes are
>> >>> +configured through input signals and the chip does not expose
>> >>> any control bus.
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: Shall be "thine,thc63lvd1024"
>> >>> +
>> >>> +Optional properties:
>> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
>> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>> >>> +- lvcc-supply: Power supply for LVDS inputs
>> >>> +- pvcc-supply: Power supply for PLL circuitry
>> >>
>> >> As explained in a comment to one of the previous versions of this
>> >> series, I'm tempted to make vcc-supply mandatory and drop the
>> >> three other power supplies for now, as I believe there's very
>> >> little chance they will be connected to separately controllable
>> >> regulators (all supplies use the same voltage). In the very
>> >> unlikely event that this occurs in design we need to support in
>> >> the future, the cvcc, lvcc and pvcc supplies can be added later
>> >> as optional without breaking backward compatibility.
>> >
>> > I'm okay with that.
>> >
>> >> Apart from that,
>> >>
>> >> Reviewed-by: Laurent Pinchart 
>> >>
>> >>> +- pdwn-gpios: Power down GPIO signal. Active low
>> >
>> > powerdown-gpios is the semi-standard name.
>> 
>>  right, I've also noticed it. If possible please avoid shortenings
>>  in property names.
>> >>>
>> >>> It is not shortening, it just follow pin name from decoder's
>> >>> datasheet.
>> >>>
>> >>> +- oe-gpios: Output enable GPIO signal. Active high
>> >>> +
>> 
>>  And this one is also a not ever met property name, please consider
>>  to rename it to 'enable-gpios', for instance display panels define
>>  it.
>> >>>
>> >>> Again, it follows datasheet naming scheme. Has something changed in
>> >>> DT conventions?
>> >>
>> >> Seconded. My understanding is that the property name should reflect
>> >> what reported in the the chip manual. For THC63LVD1024 the enable and
>> >> power down pins are named 'OE' and 'PDWN' respectively.
>> >>
>> > But don't we need the vendor prefix in the prop names then, like
>> > "renesas,oe-gpios" then?
>> 
>>  Seconded, with a correction to "thine,oe-gpios".
>> >>>
>> >>> mmm, okay then...
>> >>>
>> >>> A grep for that semi-standard properties names in Documentation/
>> >>> returns only usage 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart
 wrote:
> Hi Vladimir,
>
> On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
>> On 03/27/2018 01:10 PM, jacopo mondi wrote:
>> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>> >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
>> >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>>  On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
>> > [...]
>> >
>> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>> >>>
>> >>> Signed-off-by: Jacopo Mondi 
>> >>> Reviewed-by: Andrzej Hajda 
>> >>> Reviewed-by: Niklas Söderlund
>> >>> 
>> >>> ---
>> >>>
>> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66
>> >>>   +++
>> >>>   1 file changed, 66 insertions(+)
>> >>>   create mode 100644
>> >>>
>> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1
>> >>> 024.txt
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
>> >>> d1024.txt
>> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
>> >>> d1024.txt
>> >>> new file mode 100644
>> >>> index 000..8225c6a
>> >>> --- /dev/null
>> >>> +++
>> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
>> >>> d1024.txt
>> >>> @@ -0,0 +1,66 @@
>> >>> +Thine Electronics THC63LVD1024 LVDS decoder
>> >>> +---
>> >>> +
>> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to
>> >>> convert LVDS streams
>> >>> +to parallel data outputs. The chip supports single/dual
>> >>> input/output modes, +handling up to two two input LVDS stream
>> >>> and up to two digital CMOS/TTL outputs.
>> >>> +
>> >>> +Single or dual operation modes, output data mapping and DDR
>> >>> output modes are
>> >>> +configured through input signals and the chip does not expose
>> >>> any control bus.
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: Shall be "thine,thc63lvd1024"
>> >>> +
>> >>> +Optional properties:
>> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
>> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>> >>> +- lvcc-supply: Power supply for LVDS inputs
>> >>> +- pvcc-supply: Power supply for PLL circuitry
>> >>
>> >> As explained in a comment to one of the previous versions of this
>> >> series, I'm tempted to make vcc-supply mandatory and drop the
>> >> three other power supplies for now, as I believe there's very
>> >> little chance they will be connected to separately controllable
>> >> regulators (all supplies use the same voltage). In the very
>> >> unlikely event that this occurs in design we need to support in
>> >> the future, the cvcc, lvcc and pvcc supplies can be added later
>> >> as optional without breaking backward compatibility.
>> >
>> > I'm okay with that.
>> >
>> >> Apart from that,
>> >>
>> >> Reviewed-by: Laurent Pinchart 
>> >>
>> >>> +- pdwn-gpios: Power down GPIO signal. Active low
>> >
>> > powerdown-gpios is the semi-standard name.
>> 
>>  right, I've also noticed it. If possible please avoid shortenings
>>  in property names.
>> >>>
>> >>> It is not shortening, it just follow pin name from decoder's
>> >>> datasheet.
>> >>>
>> >>> +- oe-gpios: Output enable GPIO signal. Active high
>> >>> +
>> 
>>  And this one is also a not ever met property name, please consider
>>  to rename it to 'enable-gpios', for instance display panels define
>>  it.
>> >>>
>> >>> Again, it follows datasheet naming scheme. Has something changed in
>> >>> DT conventions?
>> >>
>> >> Seconded. My understanding is that the property name should reflect
>> >> what reported in the the chip manual. For THC63LVD1024 the enable and
>> >> power down pins are named 'OE' and 'PDWN' respectively.
>> >>
>> > But don't we need the vendor prefix in the prop names then, like
>> > "renesas,oe-gpios" then?
>> 
>>  Seconded, with a correction to "thine,oe-gpios".
>> >>>
>> >>> mmm, okay then...
>> >>>
>> >>> A grep for that semi-standard properties names in Documentation/
>> >>> returns only usage examples and no actual definitions, so I assume this
>> >>> is why they are semi-standard.
>> >>
>> >> Here we have to be specific about a particular property, 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Rob,
sorry for pointing to you directly :)

On Mon, Apr 02, 2018 at 04:36:55PM +0300, Laurent Pinchart wrote:
> Hi Vladimir,
>
> On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> > On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> > >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:

[snip]

> > >>
> > >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > >
> > > powerdown-gpios is the semi-standard name.
> > 
> >  right, I've also noticed it. If possible please avoid shortenings
> >  in property names.
> > >>>
> > >>> It is not shortening, it just follow pin name from decoder's
> > >>> datasheet.
> > >>>
> > >>> +- oe-gpios: Output enable GPIO signal. Active high
> > >>> +
> > 
> >  And this one is also a not ever met property name, please consider
> >  to rename it to 'enable-gpios', for instance display panels define
> >  it.
> > >>>
> > >>> Again, it follows datasheet naming scheme. Has something changed in
> > >>> DT conventions?
> > >>
> > >> Seconded. My understanding is that the property name should reflect
> > >> what reported in the the chip manual. For THC63LVD1024 the enable and
> > >> power down pins are named 'OE' and 'PDWN' respectively.
> > >>
> > > But don't we need the vendor prefix in the prop names then, like
> > > "renesas,oe-gpios" then?
> > 
> >  Seconded, with a correction to "thine,oe-gpios".
> > >>>
> > >>> mmm, okay then...
> > >>>
> > >>> A grep for that semi-standard properties names in Documentation/
> > >>> returns only usage examples and no actual definitions, so I assume this
> > >>> is why they are semi-standard.
> > >>
> > >> Here we have to be specific about a particular property, let it be
> > >> 'oe-gpios' vs. 'enable-gpios' and let's collect some statistics:
> > >>
> > >> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
> > >> 0
> > >>
> > >> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
> > >> 86
> > >>
> > >> While 'thine,oe-gpios' would be correct, I see no reason to introduce a
> > >> vendor specific property to define a pin with a common and well
> > >> understood purpose.
> > >>
> > >> If you go forward with the vendor specific prefix, apparently you can set
> > >> the name to 'thine,oe-gpio' (single) or even to 'thine,oe', or does the
> > >> datasheet names the pin as "OE GPIO" or "OE connected to a GPIO"? I
> > >> guess no.
> > >
> > > Let me clarify I don't want to push for a vendor specific name or
> > > similar, I'm fine with using 'semi-standard' names, I'm just confused
> > > by the 'semi-standard' definition. I guess from your examples, the
> > > usage count makes a difference here.
> >
> > yes, in gneneral you can read "semi-standard" as "widely used", thus
> > collecting statistics is a good enough method to make a reasoning.
> >
> > Hopefully the next evolutionary step of "widely used" is "described in
> > standard".
> >
> > >> Standards do not define '-gpios' suffix, but partially the description is
> > >> found in Documentation/bindings/gpio/gpio.txt, still it is not a section
> > >> in any standard as far as I know.
> > >>
> > >>> Seems like there is some tribal knowledge involved in defining what
> > >>> is semi-standard and what's not, or are those properties documented
> > >>> somewhere?
> > >>
> > >> The point is that there is no formal standard which describes every IP,
> > >> every IC and every single their property, some device node names and
> > >> property names are recommended in ePAPR and Devicetree Specification
> > >> though.
> > >>
> > >> Think of a confusion if 'rst-gpios' (have you seen any ICs with an RST
> > >> pin?) and 'reset-gpios' are different. Same applies to 'pdwn-gpios' vs.
> > >> 'powerdown-gpios'.
> > >
> > > I see all your points and I agree with most of them. Anyway, if the
> > > chip manual describes a pin as 'RST' I would not find it confusing to
> > > have a 'rst-gpio' defined in bindings :)
> > >
> > > Let me be a bit pesky here: what if a chip defines a reset GPIO, which
> > > is definitely a reset, but names it, say "XYZ" ? Would you prefer to
> > > see it defined as "reset-gpios" for consistency with other bindings,
> > > or "xyz-gpios" for consistency with documentation?
> >
> > If a pin is definitely an IC reset as you said, then my preference is to see
> > it described under 'reset-gpios' property name, plus a comment in the IC
> > device tree documentation document about it. I can provide two reasons to
> > advocate my position:
> >
> > 1) developers spend significantly more time reading and editing the actual
> >DTSI/DTS board files rather than reading and editing documentation,
> >it makes sense to use common property names to 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Rob,
sorry for pointing to you directly :)

On Mon, Apr 02, 2018 at 04:36:55PM +0300, Laurent Pinchart wrote:
> Hi Vladimir,
>
> On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> > On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> > >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:

[snip]

> > >>
> > >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > >
> > > powerdown-gpios is the semi-standard name.
> > 
> >  right, I've also noticed it. If possible please avoid shortenings
> >  in property names.
> > >>>
> > >>> It is not shortening, it just follow pin name from decoder's
> > >>> datasheet.
> > >>>
> > >>> +- oe-gpios: Output enable GPIO signal. Active high
> > >>> +
> > 
> >  And this one is also a not ever met property name, please consider
> >  to rename it to 'enable-gpios', for instance display panels define
> >  it.
> > >>>
> > >>> Again, it follows datasheet naming scheme. Has something changed in
> > >>> DT conventions?
> > >>
> > >> Seconded. My understanding is that the property name should reflect
> > >> what reported in the the chip manual. For THC63LVD1024 the enable and
> > >> power down pins are named 'OE' and 'PDWN' respectively.
> > >>
> > > But don't we need the vendor prefix in the prop names then, like
> > > "renesas,oe-gpios" then?
> > 
> >  Seconded, with a correction to "thine,oe-gpios".
> > >>>
> > >>> mmm, okay then...
> > >>>
> > >>> A grep for that semi-standard properties names in Documentation/
> > >>> returns only usage examples and no actual definitions, so I assume this
> > >>> is why they are semi-standard.
> > >>
> > >> Here we have to be specific about a particular property, let it be
> > >> 'oe-gpios' vs. 'enable-gpios' and let's collect some statistics:
> > >>
> > >> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
> > >> 0
> > >>
> > >> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
> > >> 86
> > >>
> > >> While 'thine,oe-gpios' would be correct, I see no reason to introduce a
> > >> vendor specific property to define a pin with a common and well
> > >> understood purpose.
> > >>
> > >> If you go forward with the vendor specific prefix, apparently you can set
> > >> the name to 'thine,oe-gpio' (single) or even to 'thine,oe', or does the
> > >> datasheet names the pin as "OE GPIO" or "OE connected to a GPIO"? I
> > >> guess no.
> > >
> > > Let me clarify I don't want to push for a vendor specific name or
> > > similar, I'm fine with using 'semi-standard' names, I'm just confused
> > > by the 'semi-standard' definition. I guess from your examples, the
> > > usage count makes a difference here.
> >
> > yes, in gneneral you can read "semi-standard" as "widely used", thus
> > collecting statistics is a good enough method to make a reasoning.
> >
> > Hopefully the next evolutionary step of "widely used" is "described in
> > standard".
> >
> > >> Standards do not define '-gpios' suffix, but partially the description is
> > >> found in Documentation/bindings/gpio/gpio.txt, still it is not a section
> > >> in any standard as far as I know.
> > >>
> > >>> Seems like there is some tribal knowledge involved in defining what
> > >>> is semi-standard and what's not, or are those properties documented
> > >>> somewhere?
> > >>
> > >> The point is that there is no formal standard which describes every IP,
> > >> every IC and every single their property, some device node names and
> > >> property names are recommended in ePAPR and Devicetree Specification
> > >> though.
> > >>
> > >> Think of a confusion if 'rst-gpios' (have you seen any ICs with an RST
> > >> pin?) and 'reset-gpios' are different. Same applies to 'pdwn-gpios' vs.
> > >> 'powerdown-gpios'.
> > >
> > > I see all your points and I agree with most of them. Anyway, if the
> > > chip manual describes a pin as 'RST' I would not find it confusing to
> > > have a 'rst-gpio' defined in bindings :)
> > >
> > > Let me be a bit pesky here: what if a chip defines a reset GPIO, which
> > > is definitely a reset, but names it, say "XYZ" ? Would you prefer to
> > > see it defined as "reset-gpios" for consistency with other bindings,
> > > or "xyz-gpios" for consistency with documentation?
> >
> > If a pin is definitely an IC reset as you said, then my preference is to see
> > it described under 'reset-gpios' property name, plus a comment in the IC
> > device tree documentation document about it. I can provide two reasons to
> > advocate my position:
> >
> > 1) developers spend significantly more time reading and editing the actual
> >DTSI/DTS board files rather than reading and editing documentation,
> >it makes sense to use common property names to 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Laurent Pinchart]

Hi Vladimir,

On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>  On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> > 
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>> 
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund
> >>> 
> >>> ---
> >>> 
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66
> >>>   +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> 
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1
> >>> 024.txt
> >>> 
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
> >>> d1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
> >>> d1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
> >>> d1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to
> >>> convert LVDS streams
> >>> +to parallel data outputs. The chip supports single/dual
> >>> input/output modes, +handling up to two two input LVDS stream
> >>> and up to two digital CMOS/TTL outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR
> >>> output modes are
> >>> +configured through input signals and the chip does not expose
> >>> any control bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> 
> >> As explained in a comment to one of the previous versions of this
> >> series, I'm tempted to make vcc-supply mandatory and drop the
> >> three other power supplies for now, as I believe there's very
> >> little chance they will be connected to separately controllable
> >> regulators (all supplies use the same voltage). In the very
> >> unlikely event that this occurs in design we need to support in
> >> the future, the cvcc, lvcc and pvcc supplies can be added later
> >> as optional without breaking backward compatibility.
> > 
> > I'm okay with that.
> > 
> >> Apart from that,
> >> 
> >> Reviewed-by: Laurent Pinchart 
> >> 
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > 
> > powerdown-gpios is the semi-standard name.
>  
>  right, I've also noticed it. If possible please avoid shortenings
>  in property names.
> >>> 
> >>> It is not shortening, it just follow pin name from decoder's
> >>> datasheet.
> >>> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  
>  And this one is also a not ever met property name, please consider
>  to rename it to 'enable-gpios', for instance display panels define
>  it.
> >>> 
> >>> Again, it follows datasheet naming scheme. Has something changed in
> >>> DT conventions?
> >> 
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >> 
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
>  
>  Seconded, with a correction to "thine,oe-gpios".
> >>> 
> >>> mmm, okay then...
> >>> 
> >>> A grep for that semi-standard properties names in Documentation/
> >>> returns only usage examples and no actual definitions, so I assume this
> >>> is why they are semi-standard.
> >> 
> >> Here we have to be specific about a particular property, let it be
> >> 'oe-gpios' vs. 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Laurent Pinchart]

Hi Vladimir,

On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>  On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> > 
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>> 
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund
> >>> 
> >>> ---
> >>> 
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66
> >>>   +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> 
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1
> >>> 024.txt
> >>> 
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
> >>> d1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
> >>> d1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lv
> >>> d1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to
> >>> convert LVDS streams
> >>> +to parallel data outputs. The chip supports single/dual
> >>> input/output modes, +handling up to two two input LVDS stream
> >>> and up to two digital CMOS/TTL outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR
> >>> output modes are
> >>> +configured through input signals and the chip does not expose
> >>> any control bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> 
> >> As explained in a comment to one of the previous versions of this
> >> series, I'm tempted to make vcc-supply mandatory and drop the
> >> three other power supplies for now, as I believe there's very
> >> little chance they will be connected to separately controllable
> >> regulators (all supplies use the same voltage). In the very
> >> unlikely event that this occurs in design we need to support in
> >> the future, the cvcc, lvcc and pvcc supplies can be added later
> >> as optional without breaking backward compatibility.
> > 
> > I'm okay with that.
> > 
> >> Apart from that,
> >> 
> >> Reviewed-by: Laurent Pinchart 
> >> 
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > 
> > powerdown-gpios is the semi-standard name.
>  
>  right, I've also noticed it. If possible please avoid shortenings
>  in property names.
> >>> 
> >>> It is not shortening, it just follow pin name from decoder's
> >>> datasheet.
> >>> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  
>  And this one is also a not ever met property name, please consider
>  to rename it to 'enable-gpios', for instance display panels define
>  it.
> >>> 
> >>> Again, it follows datasheet naming scheme. Has something changed in
> >>> DT conventions?
> >> 
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >> 
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
>  
>  Seconded, with a correction to "thine,oe-gpios".
> >>> 
> >>> mmm, okay then...
> >>> 
> >>> A grep for that semi-standard properties names in Documentation/
> >>> returns only usage examples and no actual definitions, so I assume this
> >>> is why they are semi-standard.
> >> 
> >> Here we have to be specific about a particular property, let it be
> >> 'oe-gpios' vs. 'enable-gpios' and let's collect some statistics:
> >> 
> >> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 02:03:25PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > Hi Vladimir,
> >
> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> >> Hi Jacopo,
> >>
> >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> >>> Hi Vladimir,
> >>>
> >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>  Hi Sergei,
> 
>  On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>>
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund 
> >>> 
> >>> ---
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> >>> +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to 
> >>> convert LVDS
> >>> streams
> >>> +to parallel data outputs. The chip supports single/dual 
> >>> input/output modes,
> >>> +handling up to two two input LVDS stream and up to two digital 
> >>> CMOS/TTL
> >>> outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR 
> >>> output modes
> >>> are
> >>> +configured through input signals and the chip does not expose 
> >>> any control
> >>> bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> As explained in a comment to one of the previous versions of this 
> >> series, I'm
> >> tempted to make vcc-supply mandatory and drop the three other 
> >> power supplies
> >> for now, as I believe there's very little chance they will be 
> >> connected to
> >> separately controllable regulators (all supplies use the same 
> >> voltage). In the
> >> very unlikely event that this occurs in design we need to support 
> >> in the
> >> future, the cvcc, lvcc and pvcc supplies can be added later as 
> >> optional
> >> without breaking backward compatibility.
> > I'm okay with that.
> >
> >> Apart from that,
> >>
> >> Reviewed-by: Laurent Pinchart 
> >>
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > powerdown-gpios is the semi-standard name.
> >
>  right, I've also noticed it. If possible please avoid shortenings in
>  property names.
> >>>
> >>> It is not shortening, it just follow pin name from decoder's 
> >>> datasheet.
> >>>
> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  And this one is also a not ever met property name, please consider to
>  rename it to 'enable-gpios', for instance display panels define it.
> >>>
> >>>
> >>> Again, it follows datasheet naming scheme. Has something changed in DT
> >>> conventions?
> >>
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
> >
> 
>  Seconded, with a correction to "thine,oe-gpios".
> 
> >>>
> >>> mmm, okay then...
> >>>
> >>> A grep for that semi-standard properties names in Documentation/
> >>> returns only usage examples and no actual definitions, so I 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 02:03:25PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > Hi Vladimir,
> >
> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> >> Hi Jacopo,
> >>
> >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> >>> Hi Vladimir,
> >>>
> >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>  Hi Sergei,
> 
>  On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>>
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund 
> >>> 
> >>> ---
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> >>> +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to 
> >>> convert LVDS
> >>> streams
> >>> +to parallel data outputs. The chip supports single/dual 
> >>> input/output modes,
> >>> +handling up to two two input LVDS stream and up to two digital 
> >>> CMOS/TTL
> >>> outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR 
> >>> output modes
> >>> are
> >>> +configured through input signals and the chip does not expose 
> >>> any control
> >>> bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> As explained in a comment to one of the previous versions of this 
> >> series, I'm
> >> tempted to make vcc-supply mandatory and drop the three other 
> >> power supplies
> >> for now, as I believe there's very little chance they will be 
> >> connected to
> >> separately controllable regulators (all supplies use the same 
> >> voltage). In the
> >> very unlikely event that this occurs in design we need to support 
> >> in the
> >> future, the cvcc, lvcc and pvcc supplies can be added later as 
> >> optional
> >> without breaking backward compatibility.
> > I'm okay with that.
> >
> >> Apart from that,
> >>
> >> Reviewed-by: Laurent Pinchart 
> >>
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > powerdown-gpios is the semi-standard name.
> >
>  right, I've also noticed it. If possible please avoid shortenings in
>  property names.
> >>>
> >>> It is not shortening, it just follow pin name from decoder's 
> >>> datasheet.
> >>>
> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  And this one is also a not ever met property name, please consider to
>  rename it to 'enable-gpios', for instance display panels define it.
> >>>
> >>>
> >>> Again, it follows datasheet naming scheme. Has something changed in DT
> >>> conventions?
> >>
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
> >
> 
>  Seconded, with a correction to "thine,oe-gpios".
> 
> >>>
> >>> mmm, okay then...
> >>>
> >>> A grep for that semi-standard properties names in Documentation/
> >>> returns only usage examples and no actual definitions, so I assume this
> >>> is why they are semi-standard.
> >>
> >> Here we have to be specific about a particular property, let it be 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 01:10 PM, jacopo mondi wrote:
> Hi Vladimir,
> 
> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>> Hi Jacopo,
>>
>> On 03/27/2018 11:57 AM, jacopo mondi wrote:
>>> Hi Vladimir,
>>>
>>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
 Hi Sergei,

 On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> [...]
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> 
>>> ---
>>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>>> +++
>>>   1 file changed, 66 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
>>> LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual 
>>> input/output modes,
>>> +handling up to two two input LVDS stream and up to two digital 
>>> CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output 
>>> modes
>>> are
>>> +configured through input signals and the chip does not expose any 
>>> control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>> As explained in a comment to one of the previous versions of this 
>> series, I'm
>> tempted to make vcc-supply mandatory and drop the three other power 
>> supplies
>> for now, as I believe there's very little chance they will be 
>> connected to
>> separately controllable regulators (all supplies use the same 
>> voltage). In the
>> very unlikely event that this occurs in design we need to support in 
>> the
>> future, the cvcc, lvcc and pvcc supplies can be added later as 
>> optional
>> without breaking backward compatibility.
> I'm okay with that.
>
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> powerdown-gpios is the semi-standard name.
>
 right, I've also noticed it. If possible please avoid shortenings in
 property names.
>>>
>>> It is not shortening, it just follow pin name from decoder's datasheet.
>>>

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +
 And this one is also a not ever met property name, please consider to
 rename it to 'enable-gpios', for instance display panels define it.
>>>
>>>
>>> Again, it follows datasheet naming scheme. Has something changed in DT
>>> conventions?
>>
>> Seconded. My understanding is that the property name should reflect
>> what reported in the the chip manual. For THC63LVD1024 the enable and
>> power down pins are named 'OE' and 'PDWN' respectively.
>
> But don't we need the vendor prefix in the prop names then, like
> "renesas,oe-gpios" then?
>

 Seconded, with a correction to "thine,oe-gpios".

>>>
>>> mmm, okay then...
>>>
>>> A grep for that semi-standard properties names in Documentation/
>>> returns only usage examples and no actual definitions, so I assume this
>>> is why they are semi-standard.
>>
>> Here we have to be specific about a particular property, let it be 'oe-gpios'
>> vs. 'enable-gpios' and let's collect some statistics:
>>
>> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
>> 0
>>
>> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 01:10 PM, jacopo mondi wrote:
> Hi Vladimir,
> 
> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>> Hi Jacopo,
>>
>> On 03/27/2018 11:57 AM, jacopo mondi wrote:
>>> Hi Vladimir,
>>>
>>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
 Hi Sergei,

 On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> [...]
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> 
>>> ---
>>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>>> +++
>>>   1 file changed, 66 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
>>> LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual 
>>> input/output modes,
>>> +handling up to two two input LVDS stream and up to two digital 
>>> CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output 
>>> modes
>>> are
>>> +configured through input signals and the chip does not expose any 
>>> control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>> As explained in a comment to one of the previous versions of this 
>> series, I'm
>> tempted to make vcc-supply mandatory and drop the three other power 
>> supplies
>> for now, as I believe there's very little chance they will be 
>> connected to
>> separately controllable regulators (all supplies use the same 
>> voltage). In the
>> very unlikely event that this occurs in design we need to support in 
>> the
>> future, the cvcc, lvcc and pvcc supplies can be added later as 
>> optional
>> without breaking backward compatibility.
> I'm okay with that.
>
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> powerdown-gpios is the semi-standard name.
>
 right, I've also noticed it. If possible please avoid shortenings in
 property names.
>>>
>>> It is not shortening, it just follow pin name from decoder's datasheet.
>>>

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +
 And this one is also a not ever met property name, please consider to
 rename it to 'enable-gpios', for instance display panels define it.
>>>
>>>
>>> Again, it follows datasheet naming scheme. Has something changed in DT
>>> conventions?
>>
>> Seconded. My understanding is that the property name should reflect
>> what reported in the the chip manual. For THC63LVD1024 the enable and
>> power down pins are named 'OE' and 'PDWN' respectively.
>
> But don't we need the vendor prefix in the prop names then, like
> "renesas,oe-gpios" then?
>

 Seconded, with a correction to "thine,oe-gpios".

>>>
>>> mmm, okay then...
>>>
>>> A grep for that semi-standard properties names in Documentation/
>>> returns only usage examples and no actual definitions, so I assume this
>>> is why they are semi-standard.
>>
>> Here we have to be specific about a particular property, let it be 'oe-gpios'
>> vs. 'enable-gpios' and let's collect some statistics:
>>
>> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
>> 0
>>
>> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
>> 86
>>
>> While 'thine,oe-gpios' would be correct, I see no reason to introduce a 
>> vendor
>> specific property to 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > Hi Vladimir,
> >
> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> >> Hi Sergei,
> >>
> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> >>> Hello!
> >>>
> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> >>> [...]
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > 
> > ---
> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> > +++
> >   1 file changed, 66 insertions(+)
> >   create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> > LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual 
> > input/output modes,
> > +handling up to two two input LVDS stream and up to two digital 
> > CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output 
> > modes
> > are
> > +configured through input signals and the chip does not expose any 
> > control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>  As explained in a comment to one of the previous versions of this 
>  series, I'm
>  tempted to make vcc-supply mandatory and drop the three other power 
>  supplies
>  for now, as I believe there's very little chance they will be 
>  connected to
>  separately controllable regulators (all supplies use the same 
>  voltage). In the
>  very unlikely event that this occurs in design we need to support in 
>  the
>  future, the cvcc, lvcc and pvcc supplies can be added later as 
>  optional
>  without breaking backward compatibility.
> >>> I'm okay with that.
> >>>
>  Apart from that,
> 
>  Reviewed-by: Laurent Pinchart 
> 
> > +- pdwn-gpios: Power down GPIO signal. Active low
> >>> powerdown-gpios is the semi-standard name.
> >>>
> >> right, I've also noticed it. If possible please avoid shortenings in
> >> property names.
> >
> > It is not shortening, it just follow pin name from decoder's datasheet.
> >
> >>
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> >> And this one is also a not ever met property name, please consider to
> >> rename it to 'enable-gpios', for instance display panels define it.
> >
> >
> > Again, it follows datasheet naming scheme. Has something changed in DT
> > conventions?
> 
>  Seconded. My understanding is that the property name should reflect
>  what reported in the the chip manual. For THC63LVD1024 the enable and
>  power down pins are named 'OE' and 'PDWN' respectively.
> >>>
> >>> But don't we need the vendor prefix in the prop names then, like
> >>> "renesas,oe-gpios" then?
> >>>
> >>
> >> Seconded, with a correction to "thine,oe-gpios".
> >>
> >
> > mmm, okay then...
> >
> > A grep for that semi-standard properties names in Documentation/
> > returns only usage examples and no actual definitions, so I assume this
> > is why they are semi-standard.
>
> Here we have to be specific about a particular property, let it be 'oe-gpios'
> vs. 'enable-gpios' and let's collect some statistics:
>
> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
> 0
>
> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
> 86
>
> While 'thine,oe-gpios' would be correct, I see no reason to 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > Hi Vladimir,
> >
> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> >> Hi Sergei,
> >>
> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> >>> Hello!
> >>>
> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> >>> [...]
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > 
> > ---
> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> > +++
> >   1 file changed, 66 insertions(+)
> >   create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> > LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual 
> > input/output modes,
> > +handling up to two two input LVDS stream and up to two digital 
> > CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output 
> > modes
> > are
> > +configured through input signals and the chip does not expose any 
> > control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>  As explained in a comment to one of the previous versions of this 
>  series, I'm
>  tempted to make vcc-supply mandatory and drop the three other power 
>  supplies
>  for now, as I believe there's very little chance they will be 
>  connected to
>  separately controllable regulators (all supplies use the same 
>  voltage). In the
>  very unlikely event that this occurs in design we need to support in 
>  the
>  future, the cvcc, lvcc and pvcc supplies can be added later as 
>  optional
>  without breaking backward compatibility.
> >>> I'm okay with that.
> >>>
>  Apart from that,
> 
>  Reviewed-by: Laurent Pinchart 
> 
> > +- pdwn-gpios: Power down GPIO signal. Active low
> >>> powerdown-gpios is the semi-standard name.
> >>>
> >> right, I've also noticed it. If possible please avoid shortenings in
> >> property names.
> >
> > It is not shortening, it just follow pin name from decoder's datasheet.
> >
> >>
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> >> And this one is also a not ever met property name, please consider to
> >> rename it to 'enable-gpios', for instance display panels define it.
> >
> >
> > Again, it follows datasheet naming scheme. Has something changed in DT
> > conventions?
> 
>  Seconded. My understanding is that the property name should reflect
>  what reported in the the chip manual. For THC63LVD1024 the enable and
>  power down pins are named 'OE' and 'PDWN' respectively.
> >>>
> >>> But don't we need the vendor prefix in the prop names then, like
> >>> "renesas,oe-gpios" then?
> >>>
> >>
> >> Seconded, with a correction to "thine,oe-gpios".
> >>
> >
> > mmm, okay then...
> >
> > A grep for that semi-standard properties names in Documentation/
> > returns only usage examples and no actual definitions, so I assume this
> > is why they are semi-standard.
>
> Here we have to be specific about a particular property, let it be 'oe-gpios'
> vs. 'enable-gpios' and let's collect some statistics:
>
> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
> 0
>
> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
> 86
>
> While 'thine,oe-gpios' would be correct, I see no reason to introduce a vendor
> specific property to define a pin with a common and well understood purpose.
>
> If you go forward 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 11:57 AM, jacopo mondi wrote:
> Hi Vladimir,
> 
> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>> Hi Sergei,
>>
>> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>>> Hello!
>>>
>>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
>>> [...]
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> ---
>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> +++
>   1 file changed, 66 insertions(+)
>   create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..8225c6a
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,66 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output 
> modes,
> +handling up to two two input LVDS stream and up to two digital 
> CMOS/TTL
> outputs.
> +
> +Single or dual operation modes, output data mapping and DDR output 
> modes
> are
> +configured through input signals and the chip does not expose any 
> control
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
 As explained in a comment to one of the previous versions of this 
 series, I'm
 tempted to make vcc-supply mandatory and drop the three other power 
 supplies
 for now, as I believe there's very little chance they will be 
 connected to
 separately controllable regulators (all supplies use the same 
 voltage). In the
 very unlikely event that this occurs in design we need to support in 
 the
 future, the cvcc, lvcc and pvcc supplies can be added later as optional
 without breaking backward compatibility.
>>> I'm okay with that.
>>>
 Apart from that,

 Reviewed-by: Laurent Pinchart 

> +- pdwn-gpios: Power down GPIO signal. Active low
>>> powerdown-gpios is the semi-standard name.
>>>
>> right, I've also noticed it. If possible please avoid shortenings in
>> property names.
>
> It is not shortening, it just follow pin name from decoder's datasheet.
>
>>
> +- oe-gpios: Output enable GPIO signal. Active high
> +
>> And this one is also a not ever met property name, please consider to
>> rename it to 'enable-gpios', for instance display panels define it.
>
>
> Again, it follows datasheet naming scheme. Has something changed in DT
> conventions?

 Seconded. My understanding is that the property name should reflect
 what reported in the the chip manual. For THC63LVD1024 the enable and
 power down pins are named 'OE' and 'PDWN' respectively.
>>>
>>> But don't we need the vendor prefix in the prop names then, like
>>> "renesas,oe-gpios" then?
>>>
>>
>> Seconded, with a correction to "thine,oe-gpios".
>>
> 
> mmm, okay then...
> 
> A grep for that semi-standard properties names in Documentation/
> returns only usage examples and no actual definitions, so I assume this
> is why they are semi-standard.

Here we have to be specific about a particular property, let it be 'oe-gpios'
vs. 'enable-gpios' and let's collect some statistics:

% grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
0

$ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
86

While 'thine,oe-gpios' would be correct, I see no reason to introduce a vendor
specific property to define a pin with a common and well understood purpose.

If you go forward with the vendor specific prefix, apparently you can set the 
name
to 'thine,oe-gpio' (single) or even to 'thine,oe', or does the datasheet names
the pin as "OE GPIO" or "OE connected to a GPIO"? I guess no.

Standards do not define 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 11:57 AM, jacopo mondi wrote:
> Hi Vladimir,
> 
> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>> Hi Sergei,
>>
>> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>>> Hello!
>>>
>>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
>>> [...]
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> ---
>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> +++
>   1 file changed, 66 insertions(+)
>   create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..8225c6a
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,66 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output 
> modes,
> +handling up to two two input LVDS stream and up to two digital 
> CMOS/TTL
> outputs.
> +
> +Single or dual operation modes, output data mapping and DDR output 
> modes
> are
> +configured through input signals and the chip does not expose any 
> control
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
 As explained in a comment to one of the previous versions of this 
 series, I'm
 tempted to make vcc-supply mandatory and drop the three other power 
 supplies
 for now, as I believe there's very little chance they will be 
 connected to
 separately controllable regulators (all supplies use the same 
 voltage). In the
 very unlikely event that this occurs in design we need to support in 
 the
 future, the cvcc, lvcc and pvcc supplies can be added later as optional
 without breaking backward compatibility.
>>> I'm okay with that.
>>>
 Apart from that,

 Reviewed-by: Laurent Pinchart 

> +- pdwn-gpios: Power down GPIO signal. Active low
>>> powerdown-gpios is the semi-standard name.
>>>
>> right, I've also noticed it. If possible please avoid shortenings in
>> property names.
>
> It is not shortening, it just follow pin name from decoder's datasheet.
>
>>
> +- oe-gpios: Output enable GPIO signal. Active high
> +
>> And this one is also a not ever met property name, please consider to
>> rename it to 'enable-gpios', for instance display panels define it.
>
>
> Again, it follows datasheet naming scheme. Has something changed in DT
> conventions?

 Seconded. My understanding is that the property name should reflect
 what reported in the the chip manual. For THC63LVD1024 the enable and
 power down pins are named 'OE' and 'PDWN' respectively.
>>>
>>> But don't we need the vendor prefix in the prop names then, like
>>> "renesas,oe-gpios" then?
>>>
>>
>> Seconded, with a correction to "thine,oe-gpios".
>>
> 
> mmm, okay then...
> 
> A grep for that semi-standard properties names in Documentation/
> returns only usage examples and no actual definitions, so I assume this
> is why they are semi-standard.

Here we have to be specific about a particular property, let it be 'oe-gpios'
vs. 'enable-gpios' and let's collect some statistics:

% grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
0

$ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
86

While 'thine,oe-gpios' would be correct, I see no reason to introduce a vendor
specific property to define a pin with a common and well understood purpose.

If you go forward with the vendor specific prefix, apparently you can set the 
name
to 'thine,oe-gpio' (single) or even to 'thine,oe', or does the datasheet names
the pin as "OE GPIO" or "OE connected to a GPIO"? I guess no.

Standards do not define '-gpios' suffix, but partially the description is found
in Documentation/bindings/gpio/gpio.txt, still it is not a section 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> Hi Sergei,
>
> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>>
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund 
> >>> ---
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> >>> +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> >>> LVDS
> >>> streams
> >>> +to parallel data outputs. The chip supports single/dual input/output 
> >>> modes,
> >>> +handling up to two two input LVDS stream and up to two digital 
> >>> CMOS/TTL
> >>> outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR output 
> >>> modes
> >>> are
> >>> +configured through input signals and the chip does not expose any 
> >>> control
> >>> bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> As explained in a comment to one of the previous versions of this 
> >> series, I'm
> >> tempted to make vcc-supply mandatory and drop the three other power 
> >> supplies
> >> for now, as I believe there's very little chance they will be 
> >> connected to
> >> separately controllable regulators (all supplies use the same 
> >> voltage). In the
> >> very unlikely event that this occurs in design we need to support in 
> >> the
> >> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> >> without breaking backward compatibility.
> > I'm okay with that.
> >
> >> Apart from that,
> >>
> >> Reviewed-by: Laurent Pinchart 
> >>
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > powerdown-gpios is the semi-standard name.
> >
>  right, I've also noticed it. If possible please avoid shortenings in
>  property names.
> >>>
> >>> It is not shortening, it just follow pin name from decoder's datasheet.
> >>>
> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  And this one is also a not ever met property name, please consider to
>  rename it to 'enable-gpios', for instance display panels define it.
> >>>
> >>>
> >>> Again, it follows datasheet naming scheme. Has something changed in DT
> >>> conventions?
> >>
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
> >
>
> Seconded, with a correction to "thine,oe-gpios".
>

mmm, okay then...

A grep for that semi-standard properties names in Documentation/
returns only usage examples and no actual definitions, so I assume this
is why they are semi-standard. Seems like there is some tribal knowledge
involved in defining what is semi-standard and what's not, or are those
properties documented somewhere?

Thanks
   j


> If vendor agnostic properties are supposed to be used, then please follow
> the referenced by Rob semi-standard notations.
>
> --
> With best wishes,
> Vladimir


signature.asc
Description: PGP signature

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> Hi Sergei,
>
> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>>
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund 
> >>> ---
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> >>> +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> >>> LVDS
> >>> streams
> >>> +to parallel data outputs. The chip supports single/dual input/output 
> >>> modes,
> >>> +handling up to two two input LVDS stream and up to two digital 
> >>> CMOS/TTL
> >>> outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR output 
> >>> modes
> >>> are
> >>> +configured through input signals and the chip does not expose any 
> >>> control
> >>> bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> As explained in a comment to one of the previous versions of this 
> >> series, I'm
> >> tempted to make vcc-supply mandatory and drop the three other power 
> >> supplies
> >> for now, as I believe there's very little chance they will be 
> >> connected to
> >> separately controllable regulators (all supplies use the same 
> >> voltage). In the
> >> very unlikely event that this occurs in design we need to support in 
> >> the
> >> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> >> without breaking backward compatibility.
> > I'm okay with that.
> >
> >> Apart from that,
> >>
> >> Reviewed-by: Laurent Pinchart 
> >>
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > powerdown-gpios is the semi-standard name.
> >
>  right, I've also noticed it. If possible please avoid shortenings in
>  property names.
> >>>
> >>> It is not shortening, it just follow pin name from decoder's datasheet.
> >>>
> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  And this one is also a not ever met property name, please consider to
>  rename it to 'enable-gpios', for instance display panels define it.
> >>>
> >>>
> >>> Again, it follows datasheet naming scheme. Has something changed in DT
> >>> conventions?
> >>
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
> >
>
> Seconded, with a correction to "thine,oe-gpios".
>

mmm, okay then...

A grep for that semi-standard properties names in Documentation/
returns only usage examples and no actual definitions, so I assume this
is why they are semi-standard. Seems like there is some tribal knowledge
involved in defining what is semi-standard and what's not, or are those
properties documented somewhere?

Thanks
   j


> If vendor agnostic properties are supposed to be used, then please follow
> the referenced by Rob semi-standard notations.
>
> --
> With best wishes,
> Vladimir


signature.asc
Description: PGP signature

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Sergei,

On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> Hello!
> 
> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> [...]
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> ---
>>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>>> +++
>>>   1 file changed, 66 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual input/output 
>>> modes,
>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output 
>>> modes
>>> are
>>> +configured through input signals and the chip does not expose any 
>>> control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>> As explained in a comment to one of the previous versions of this 
>> series, I'm
>> tempted to make vcc-supply mandatory and drop the three other power 
>> supplies
>> for now, as I believe there's very little chance they will be connected 
>> to
>> separately controllable regulators (all supplies use the same voltage). 
>> In the
>> very unlikely event that this occurs in design we need to support in the
>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
>> without breaking backward compatibility.
> I'm okay with that.
>
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> powerdown-gpios is the semi-standard name.
>
 right, I've also noticed it. If possible please avoid shortenings in
 property names.
>>>
>>> It is not shortening, it just follow pin name from decoder's datasheet.
>>>

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +
 And this one is also a not ever met property name, please consider to
 rename it to 'enable-gpios', for instance display panels define it.
>>>
>>>
>>> Again, it follows datasheet naming scheme. Has something changed in DT
>>> conventions?
>>
>> Seconded. My understanding is that the property name should reflect
>> what reported in the the chip manual. For THC63LVD1024 the enable and
>> power down pins are named 'OE' and 'PDWN' respectively.
> 
> But don't we need the vendor prefix in the prop names then, like 
> "renesas,oe-gpios" then?
> 

Seconded, with a correction to "thine,oe-gpios".

If vendor agnostic properties are supposed to be used, then please follow
the referenced by Rob semi-standard notations.

--
With best wishes,
Vladimir

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Sergei,

On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> Hello!
> 
> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> [...]
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> ---
>>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>>> +++
>>>   1 file changed, 66 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual input/output 
>>> modes,
>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output 
>>> modes
>>> are
>>> +configured through input signals and the chip does not expose any 
>>> control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>> As explained in a comment to one of the previous versions of this 
>> series, I'm
>> tempted to make vcc-supply mandatory and drop the three other power 
>> supplies
>> for now, as I believe there's very little chance they will be connected 
>> to
>> separately controllable regulators (all supplies use the same voltage). 
>> In the
>> very unlikely event that this occurs in design we need to support in the
>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
>> without breaking backward compatibility.
> I'm okay with that.
>
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> powerdown-gpios is the semi-standard name.
>
 right, I've also noticed it. If possible please avoid shortenings in
 property names.
>>>
>>> It is not shortening, it just follow pin name from decoder's datasheet.
>>>

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +
 And this one is also a not ever met property name, please consider to
 rename it to 'enable-gpios', for instance display panels define it.
>>>
>>>
>>> Again, it follows datasheet naming scheme. Has something changed in DT
>>> conventions?
>>
>> Seconded. My understanding is that the property name should reflect
>> what reported in the the chip manual. For THC63LVD1024 the enable and
>> power down pins are named 'OE' and 'PDWN' respectively.
> 
> But don't we need the vendor prefix in the prop names then, like 
> "renesas,oe-gpios" then?
> 

Seconded, with a correction to "thine,oe-gpios".

If vendor agnostic properties are supposed to be used, then please follow
the referenced by Rob semi-standard notations.

--
With best wishes,
Vladimir

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Sergei Shtylyov]

Hello!

On 3/27/2018 10:33 AM, jacopo mondi wrote:
[...]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
---
  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
  1 file changed, 66 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes
are
+configured through input signals and the chip does not expose any control
bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry

As explained in a comment to one of the previous versions of this series, I'm
tempted to make vcc-supply mandatory and drop the three other power supplies
for now, as I believe there's very little chance they will be connected to
separately controllable regulators (all supplies use the same voltage). In the
very unlikely event that this occurs in design we need to support in the
future, the cvcc, lvcc and pvcc supplies can be added later as optional
without breaking backward compatibility.

I'm okay with that.


Apart from that,

Reviewed-by: Laurent Pinchart 


+- pdwn-gpios: Power down GPIO signal. Active low

powerdown-gpios is the semi-standard name.


right, I've also noticed it. If possible please avoid shortenings in
property names.


It is not shortening, it just follow pin name from decoder's datasheet.




+- oe-gpios: Output enable GPIO signal. Active high
+

And this one is also a not ever met property name, please consider to
rename it to 'enable-gpios', for instance display panels define it.



Again, it follows datasheet naming scheme. Has something changed in DT
conventions?


Seconded. My understanding is that the property name should reflect
what reported in the the chip manual. For THC63LVD1024 the enable and
power down pins are named 'OE' and 'PDWN' respectively.


   But don't we need the vendor prefix in the prop names then, like 
"renesas,oe-gpios" then?



Thanks
j


MBR, Sergei

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Sergei Shtylyov]

Hello!

On 3/27/2018 10:33 AM, jacopo mondi wrote:
[...]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
---
  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
  1 file changed, 66 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes
are
+configured through input signals and the chip does not expose any control
bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry

As explained in a comment to one of the previous versions of this series, I'm
tempted to make vcc-supply mandatory and drop the three other power supplies
for now, as I believe there's very little chance they will be connected to
separately controllable regulators (all supplies use the same voltage). In the
very unlikely event that this occurs in design we need to support in the
future, the cvcc, lvcc and pvcc supplies can be added later as optional
without breaking backward compatibility.

I'm okay with that.


Apart from that,

Reviewed-by: Laurent Pinchart 


+- pdwn-gpios: Power down GPIO signal. Active low

powerdown-gpios is the semi-standard name.


right, I've also noticed it. If possible please avoid shortenings in
property names.


It is not shortening, it just follow pin name from decoder's datasheet.




+- oe-gpios: Output enable GPIO signal. Active high
+

And this one is also a not ever met property name, please consider to
rename it to 'enable-gpios', for instance display panels define it.



Again, it follows datasheet naming scheme. Has something changed in DT
conventions?


Seconded. My understanding is that the property name should reflect
what reported in the the chip manual. For THC63LVD1024 the enable and
power down pins are named 'OE' and 'PDWN' respectively.


   But don't we need the vendor prefix in the prop names then, like 
"renesas,oe-gpios" then?



Thanks
j


MBR, Sergei

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Andrzej,

On Tue, Mar 27, 2018 at 09:12:46AM +0200, Andrzej Hajda wrote:
> On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> > Hi Jacopo,
> >
> > On 03/27/2018 01:22 AM, Rob Herring wrote:
> >> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> >>> Hi Jacopo,
> >>>
> >>> (CC'ing Rob)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
>  Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
>  Signed-off-by: Jacopo Mondi 
>  Reviewed-by: Andrzej Hajda 
>  Reviewed-by: Niklas Söderlund 
>  ---
>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>  +++
>   1 file changed, 66 insertions(+)
>   create mode 100644
>  Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 
>  diff --git
>  a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  new file mode 100644
>  index 000..8225c6a
>  --- /dev/null
>  +++
>  b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  @@ -0,0 +1,66 @@
>  +Thine Electronics THC63LVD1024 LVDS decoder
>  +---
>  +
>  +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>  streams
>  +to parallel data outputs. The chip supports single/dual input/output 
>  modes,
>  +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>  outputs.
>  +
>  +Single or dual operation modes, output data mapping and DDR output modes
>  are
>  +configured through input signals and the chip does not expose any 
>  control
>  bus.
>  +
>  +Required properties:
>  +- compatible: Shall be "thine,thc63lvd1024"
>  +
>  +Optional properties:
>  +- vcc-supply: Power supply for TTL output and digital circuitry
>  +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>  +- lvcc-supply: Power supply for LVDS inputs
>  +- pvcc-supply: Power supply for PLL circuitry
> >>> As explained in a comment to one of the previous versions of this series, 
> >>> I'm
> >>> tempted to make vcc-supply mandatory and drop the three other power 
> >>> supplies
> >>> for now, as I believe there's very little chance they will be connected to
> >>> separately controllable regulators (all supplies use the same voltage). 
> >>> In the
> >>> very unlikely event that this occurs in design we need to support in the
> >>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> >>> without breaking backward compatibility.
> >> I'm okay with that.
> >>
> >>> Apart from that,
> >>>
> >>> Reviewed-by: Laurent Pinchart 
> >>>
>  +- pdwn-gpios: Power down GPIO signal. Active low
> >> powerdown-gpios is the semi-standard name.
> >>
> > right, I've also noticed it. If possible please avoid shortenings in
> > property names.
>
> It is not shortening, it just follow pin name from decoder's datasheet.
>
> >
>  +- oe-gpios: Output enable GPIO signal. Active high
>  +
> > And this one is also a not ever met property name, please consider to
> > rename it to 'enable-gpios', for instance display panels define it.
>
>
> Again, it follows datasheet naming scheme. Has something changed in DT
> conventions?

Seconded. My understanding is that the property name should reflect
what reported in the the chip manual. For THC63LVD1024 the enable and
power down pins are named 'OE' and 'PDWN' respectively.

Thanks
   j

>
> Regards
> Andrzej
>
> >
>  +The THC63LVD1024 video port connections are modeled according
>  +to OF graph bindings specified by
>  Documentation/devicetree/bindings/graph.txt
> > [snip]
> >
>  +
>  +port@2{
>  +reg = <2>;
>  +
>  +lvds_dec_out_2: endpoint {
>  +remote-endpoint = <_in>;
>  +};
>  +
> > Drop a surplus empty line above.
> >
>  +};
>  +
> > Drop a surplus empty line above.
> >
>  +};
>  +};
> > --
> > With best wishes,
> > Vladimir
> >
> >
> >
>

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Andrzej,

On Tue, Mar 27, 2018 at 09:12:46AM +0200, Andrzej Hajda wrote:
> On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> > Hi Jacopo,
> >
> > On 03/27/2018 01:22 AM, Rob Herring wrote:
> >> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> >>> Hi Jacopo,
> >>>
> >>> (CC'ing Rob)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
>  Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
>  Signed-off-by: Jacopo Mondi 
>  Reviewed-by: Andrzej Hajda 
>  Reviewed-by: Niklas Söderlund 
>  ---
>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>  +++
>   1 file changed, 66 insertions(+)
>   create mode 100644
>  Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 
>  diff --git
>  a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  new file mode 100644
>  index 000..8225c6a
>  --- /dev/null
>  +++
>  b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  @@ -0,0 +1,66 @@
>  +Thine Electronics THC63LVD1024 LVDS decoder
>  +---
>  +
>  +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>  streams
>  +to parallel data outputs. The chip supports single/dual input/output 
>  modes,
>  +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>  outputs.
>  +
>  +Single or dual operation modes, output data mapping and DDR output modes
>  are
>  +configured through input signals and the chip does not expose any 
>  control
>  bus.
>  +
>  +Required properties:
>  +- compatible: Shall be "thine,thc63lvd1024"
>  +
>  +Optional properties:
>  +- vcc-supply: Power supply for TTL output and digital circuitry
>  +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>  +- lvcc-supply: Power supply for LVDS inputs
>  +- pvcc-supply: Power supply for PLL circuitry
> >>> As explained in a comment to one of the previous versions of this series, 
> >>> I'm
> >>> tempted to make vcc-supply mandatory and drop the three other power 
> >>> supplies
> >>> for now, as I believe there's very little chance they will be connected to
> >>> separately controllable regulators (all supplies use the same voltage). 
> >>> In the
> >>> very unlikely event that this occurs in design we need to support in the
> >>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> >>> without breaking backward compatibility.
> >> I'm okay with that.
> >>
> >>> Apart from that,
> >>>
> >>> Reviewed-by: Laurent Pinchart 
> >>>
>  +- pdwn-gpios: Power down GPIO signal. Active low
> >> powerdown-gpios is the semi-standard name.
> >>
> > right, I've also noticed it. If possible please avoid shortenings in
> > property names.
>
> It is not shortening, it just follow pin name from decoder's datasheet.
>
> >
>  +- oe-gpios: Output enable GPIO signal. Active high
>  +
> > And this one is also a not ever met property name, please consider to
> > rename it to 'enable-gpios', for instance display panels define it.
>
>
> Again, it follows datasheet naming scheme. Has something changed in DT
> conventions?

Seconded. My understanding is that the property name should reflect
what reported in the the chip manual. For THC63LVD1024 the enable and
power down pins are named 'OE' and 'PDWN' respectively.

Thanks
   j

>
> Regards
> Andrzej
>
> >
>  +The THC63LVD1024 video port connections are modeled according
>  +to OF graph bindings specified by
>  Documentation/devicetree/bindings/graph.txt
> > [snip]
> >
>  +
>  +port@2{
>  +reg = <2>;
>  +
>  +lvds_dec_out_2: endpoint {
>  +remote-endpoint = <_in>;
>  +};
>  +
> > Drop a surplus empty line above.
> >
>  +};
>  +
> > Drop a surplus empty line above.
> >
>  +};
>  +};
> > --
> > With best wishes,
> > Vladimir
> >
> >
> >
>

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Andrzej Hajda]

On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:22 AM, Rob Herring wrote:
>> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
>>> Hi Jacopo,
>>>
>>> (CC'ing Rob)
>>>
>>> Thank you for the patch.
>>>
>>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
 Document Thine THC63LVD1024 LVDS decoder device tree bindings.

 Signed-off-by: Jacopo Mondi 
 Reviewed-by: Andrzej Hajda 
 Reviewed-by: Niklas Söderlund 
 ---
  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
 +++
  1 file changed, 66 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 new file mode 100644
 index 000..8225c6a
 --- /dev/null
 +++
 b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 @@ -0,0 +1,66 @@
 +Thine Electronics THC63LVD1024 LVDS decoder
 +---
 +
 +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
 streams
 +to parallel data outputs. The chip supports single/dual input/output 
 modes,
 +handling up to two two input LVDS stream and up to two digital CMOS/TTL
 outputs.
 +
 +Single or dual operation modes, output data mapping and DDR output modes
 are
 +configured through input signals and the chip does not expose any control
 bus.
 +
 +Required properties:
 +- compatible: Shall be "thine,thc63lvd1024"
 +
 +Optional properties:
 +- vcc-supply: Power supply for TTL output and digital circuitry
 +- cvcc-supply: Power supply for TTL CLOCKOUT signal
 +- lvcc-supply: Power supply for LVDS inputs
 +- pvcc-supply: Power supply for PLL circuitry
>>> As explained in a comment to one of the previous versions of this series, 
>>> I'm 
>>> tempted to make vcc-supply mandatory and drop the three other power 
>>> supplies 
>>> for now, as I believe there's very little chance they will be connected to 
>>> separately controllable regulators (all supplies use the same voltage). In 
>>> the 
>>> very unlikely event that this occurs in design we need to support in the 
>>> future, the cvcc, lvcc and pvcc supplies can be added later as optional 
>>> without breaking backward compatibility.
>> I'm okay with that.
>>
>>> Apart from that,
>>>
>>> Reviewed-by: Laurent Pinchart 
>>>
 +- pdwn-gpios: Power down GPIO signal. Active low
>> powerdown-gpios is the semi-standard name.
>>
> right, I've also noticed it. If possible please avoid shortenings in
> property names.

It is not shortening, it just follow pin name from decoder's datasheet.

>
 +- oe-gpios: Output enable GPIO signal. Active high
 +
> And this one is also a not ever met property name, please consider to
> rename it to 'enable-gpios', for instance display panels define it.


Again, it follows datasheet naming scheme. Has something changed in DT
conventions?

Regards
Andrzej

>
 +The THC63LVD1024 video port connections are modeled according
 +to OF graph bindings specified by
 Documentation/devicetree/bindings/graph.txt
> [snip]
>
 +
 +  port@2{
 +  reg = <2>;
 +
 +  lvds_dec_out_2: endpoint {
 +  remote-endpoint = <_in>;
 +  };
 +
> Drop a surplus empty line above.
>
 +  };
 +
> Drop a surplus empty line above.
>
 +  };
 +  };
> --
> With best wishes,
> Vladimir
>
>
>

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Andrzej Hajda]

On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:22 AM, Rob Herring wrote:
>> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
>>> Hi Jacopo,
>>>
>>> (CC'ing Rob)
>>>
>>> Thank you for the patch.
>>>
>>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
 Document Thine THC63LVD1024 LVDS decoder device tree bindings.

 Signed-off-by: Jacopo Mondi 
 Reviewed-by: Andrzej Hajda 
 Reviewed-by: Niklas Söderlund 
 ---
  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
 +++
  1 file changed, 66 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 new file mode 100644
 index 000..8225c6a
 --- /dev/null
 +++
 b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 @@ -0,0 +1,66 @@
 +Thine Electronics THC63LVD1024 LVDS decoder
 +---
 +
 +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
 streams
 +to parallel data outputs. The chip supports single/dual input/output 
 modes,
 +handling up to two two input LVDS stream and up to two digital CMOS/TTL
 outputs.
 +
 +Single or dual operation modes, output data mapping and DDR output modes
 are
 +configured through input signals and the chip does not expose any control
 bus.
 +
 +Required properties:
 +- compatible: Shall be "thine,thc63lvd1024"
 +
 +Optional properties:
 +- vcc-supply: Power supply for TTL output and digital circuitry
 +- cvcc-supply: Power supply for TTL CLOCKOUT signal
 +- lvcc-supply: Power supply for LVDS inputs
 +- pvcc-supply: Power supply for PLL circuitry
>>> As explained in a comment to one of the previous versions of this series, 
>>> I'm 
>>> tempted to make vcc-supply mandatory and drop the three other power 
>>> supplies 
>>> for now, as I believe there's very little chance they will be connected to 
>>> separately controllable regulators (all supplies use the same voltage). In 
>>> the 
>>> very unlikely event that this occurs in design we need to support in the 
>>> future, the cvcc, lvcc and pvcc supplies can be added later as optional 
>>> without breaking backward compatibility.
>> I'm okay with that.
>>
>>> Apart from that,
>>>
>>> Reviewed-by: Laurent Pinchart 
>>>
 +- pdwn-gpios: Power down GPIO signal. Active low
>> powerdown-gpios is the semi-standard name.
>>
> right, I've also noticed it. If possible please avoid shortenings in
> property names.

It is not shortening, it just follow pin name from decoder's datasheet.

>
 +- oe-gpios: Output enable GPIO signal. Active high
 +
> And this one is also a not ever met property name, please consider to
> rename it to 'enable-gpios', for instance display panels define it.


Again, it follows datasheet naming scheme. Has something changed in DT
conventions?

Regards
Andrzej

>
 +The THC63LVD1024 video port connections are modeled according
 +to OF graph bindings specified by
 Documentation/devicetree/bindings/graph.txt
> [snip]
>
 +
 +  port@2{
 +  reg = <2>;
 +
 +  lvds_dec_out_2: endpoint {
 +  remote-endpoint = <_in>;
 +  };
 +
> Drop a surplus empty line above.
>
 +  };
 +
> Drop a surplus empty line above.
>
 +  };
 +  };
> --
> With best wishes,
> Vladimir
>
>
>

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 01:22 AM, Rob Herring wrote:
> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
>> Hi Jacopo,
>>
>> (CC'ing Rob)
>>
>> Thank you for the patch.
>>
>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> ---
>>>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
>>>  1 file changed, 66 insertions(+)
>>>  create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual input/output modes,
>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output modes
>>> are
>>> +configured through input signals and the chip does not expose any control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>>
>> As explained in a comment to one of the previous versions of this series, 
>> I'm 
>> tempted to make vcc-supply mandatory and drop the three other power supplies 
>> for now, as I believe there's very little chance they will be connected to 
>> separately controllable regulators (all supplies use the same voltage). In 
>> the 
>> very unlikely event that this occurs in design we need to support in the 
>> future, the cvcc, lvcc and pvcc supplies can be added later as optional 
>> without breaking backward compatibility.
> 
> I'm okay with that.
> 
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> 
> powerdown-gpios is the semi-standard name.
> 

right, I've also noticed it. If possible please avoid shortenings in
property names.

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +

And this one is also a not ever met property name, please consider to
rename it to 'enable-gpios', for instance display panels define it.

>>> +The THC63LVD1024 video port connections are modeled according
>>> +to OF graph bindings specified by
>>> Documentation/devicetree/bindings/graph.txt

[snip]

>>> +
>>> +   port@2{
>>> +   reg = <2>;
>>> +
>>> +   lvds_dec_out_2: endpoint {
>>> +   remote-endpoint = <_in>;
>>> +   };
>>> +

Drop a surplus empty line above.

>>> +   };
>>> +

Drop a surplus empty line above.

>>> +   };
>>> +   };

--
With best wishes,
Vladimir

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 01:22 AM, Rob Herring wrote:
> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
>> Hi Jacopo,
>>
>> (CC'ing Rob)
>>
>> Thank you for the patch.
>>
>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> ---
>>>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
>>>  1 file changed, 66 insertions(+)
>>>  create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual input/output modes,
>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output modes
>>> are
>>> +configured through input signals and the chip does not expose any control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>>
>> As explained in a comment to one of the previous versions of this series, 
>> I'm 
>> tempted to make vcc-supply mandatory and drop the three other power supplies 
>> for now, as I believe there's very little chance they will be connected to 
>> separately controllable regulators (all supplies use the same voltage). In 
>> the 
>> very unlikely event that this occurs in design we need to support in the 
>> future, the cvcc, lvcc and pvcc supplies can be added later as optional 
>> without breaking backward compatibility.
> 
> I'm okay with that.
> 
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> 
> powerdown-gpios is the semi-standard name.
> 

right, I've also noticed it. If possible please avoid shortenings in
property names.

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +

And this one is also a not ever met property name, please consider to
rename it to 'enable-gpios', for instance display panels define it.

>>> +The THC63LVD1024 video port connections are modeled according
>>> +to OF graph bindings specified by
>>> Documentation/devicetree/bindings/graph.txt

[snip]

>>> +
>>> +   port@2{
>>> +   reg = <2>;
>>> +
>>> +   lvds_dec_out_2: endpoint {
>>> +   remote-endpoint = <_in>;
>>> +   };
>>> +

Drop a surplus empty line above.

>>> +   };
>>> +

Drop a surplus empty line above.

>>> +   };
>>> +   };

--
With best wishes,
Vladimir

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
> 
> (CC'ing Rob)
> 
> Thank you for the patch.
> 
> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> > 
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
> >  1 file changed, 66 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output modes
> > are
> > +configured through input signals and the chip does not expose any control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
> 
> As explained in a comment to one of the previous versions of this series, I'm 
> tempted to make vcc-supply mandatory and drop the three other power supplies 
> for now, as I believe there's very little chance they will be connected to 
> separately controllable regulators (all supplies use the same voltage). In 
> the 
> very unlikely event that this occurs in design we need to support in the 
> future, the cvcc, lvcc and pvcc supplies can be added later as optional 
> without breaking backward compatibility.

I'm okay with that.

> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
> > +- pdwn-gpios: Power down GPIO signal. Active low

powerdown-gpios is the semi-standard name.

> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output

s/Port/port/

> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > +   thc63lvd1024: lvds-decoder {
> > +   compatible = "thine,thc63lvd1024";
> > +
> > +   vcc-supply = <_lvds_vcc>;
> > +   lvcc-supply = <_lvds_lvcc>;
> > +
> > +   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +
> > +   lvds_dec_in_0: endpoint {
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > +
> > +   port@2{
> > +   reg = <2>;
> > +
> > +   lvds_dec_out_2: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +
> > +   };
> > +
> > +   };
> > +   };
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
> 
> (CC'ing Rob)
> 
> Thank you for the patch.
> 
> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> > 
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
> >  1 file changed, 66 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output modes
> > are
> > +configured through input signals and the chip does not expose any control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
> 
> As explained in a comment to one of the previous versions of this series, I'm 
> tempted to make vcc-supply mandatory and drop the three other power supplies 
> for now, as I believe there's very little chance they will be connected to 
> separately controllable regulators (all supplies use the same voltage). In 
> the 
> very unlikely event that this occurs in design we need to support in the 
> future, the cvcc, lvcc and pvcc supplies can be added later as optional 
> without breaking backward compatibility.

I'm okay with that.

> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
> > +- pdwn-gpios: Power down GPIO signal. Active low

powerdown-gpios is the semi-standard name.

> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output

s/Port/port/

> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > +   thc63lvd1024: lvds-decoder {
> > +   compatible = "thine,thc63lvd1024";
> > +
> > +   vcc-supply = <_lvds_vcc>;
> > +   lvcc-supply = <_lvds_lvcc>;
> > +
> > +   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +
> > +   lvds_dec_in_0: endpoint {
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > +
> > +   port@2{
> > +   reg = <2>;
> > +
> > +   lvds_dec_out_2: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +
> > +   };
> > +
> > +   };
> > +   };
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Laurent,

On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> (CC'ing Rob)
>
> Thank you for the patch.
>
> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
> >  1 file changed, 66 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output modes
> > are
> > +configured through input signals and the chip does not expose any control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>
> As explained in a comment to one of the previous versions of this series, I'm
> tempted to make vcc-supply mandatory and drop the three other power supplies
> for now, as I believe there's very little chance they will be connected to
> separately controllable regulators (all supplies use the same voltage). In the
> very unlikely event that this occurs in design we need to support in the
> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> without breaking backward compatibility.

Fine, you and Andrzej both agree on this, and I actually do, as all
the supplies have the same voltage.

I'll make vcc the only and mandatory supply.

I'll keep Andrzej Reviwed-by as he suggested it, and add yours.

Thanks
   j

>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart 
>
> > +- pdwn-gpios: Power down GPIO signal. Active low
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output
> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > +   thc63lvd1024: lvds-decoder {
> > +   compatible = "thine,thc63lvd1024";
> > +
> > +   vcc-supply = <_lvds_vcc>;
> > +   lvcc-supply = <_lvds_lvcc>;
> > +
> > +   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +
> > +   lvds_dec_in_0: endpoint {
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > +
> > +   port@2{
> > +   reg = <2>;
> > +
> > +   lvds_dec_out_2: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +
> > +   };
> > +
> > +   };
> > +   };
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Laurent,

On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> (CC'ing Rob)
>
> Thank you for the patch.
>
> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
> >  1 file changed, 66 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output modes
> > are
> > +configured through input signals and the chip does not expose any control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>
> As explained in a comment to one of the previous versions of this series, I'm
> tempted to make vcc-supply mandatory and drop the three other power supplies
> for now, as I believe there's very little chance they will be connected to
> separately controllable regulators (all supplies use the same voltage). In the
> very unlikely event that this occurs in design we need to support in the
> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> without breaking backward compatibility.

Fine, you and Andrzej both agree on this, and I actually do, as all
the supplies have the same voltage.

I'll make vcc the only and mandatory supply.

I'll keep Andrzej Reviwed-by as he suggested it, and add yours.

Thanks
   j

>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart 
>
> > +- pdwn-gpios: Power down GPIO signal. Active low
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output
> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > +   thc63lvd1024: lvds-decoder {
> > +   compatible = "thine,thc63lvd1024";
> > +
> > +   vcc-supply = <_lvds_vcc>;
> > +   lvcc-supply = <_lvds_lvcc>;
> > +
> > +   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +
> > +   lvds_dec_in_0: endpoint {
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > +
> > +   port@2{
> > +   reg = <2>;
> > +
> > +   lvds_dec_out_2: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +
> > +   };
> > +
> > +   };
> > +   };
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Laurent Pinchart]

Hi Jacopo,

(CC'ing Rob)

Thank you for the patch.

On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
>  1 file changed, 66 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..8225c6a
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,66 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> outputs.
> +
> +Single or dual operation modes, output data mapping and DDR output modes
> are
> +configured through input signals and the chip does not expose any control
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry

As explained in a comment to one of the previous versions of this series, I'm 
tempted to make vcc-supply mandatory and drop the three other power supplies 
for now, as I believe there's very little chance they will be connected to 
separately controllable regulators (all supplies use the same voltage). In the 
very unlikely event that this occurs in design we need to support in the 
future, the cvcc, lvcc and pvcc supplies can be added later as optional 
without breaking backward compatibility.

Apart from that,

Reviewed-by: Laurent Pinchart 

> +- pdwn-gpios: Power down GPIO signal. Active low
> +- oe-gpios: Output enable GPIO signal. Active high
> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by
> Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <_lvds_vcc>;
> + lvcc-supply = <_lvds_lvcc>;
> +
> + pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };

-- 
Regards,

Laurent Pinchart

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Laurent Pinchart]

Hi Jacopo,

(CC'ing Rob)

Thank you for the patch.

On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
>  1 file changed, 66 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..8225c6a
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,66 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> outputs.
> +
> +Single or dual operation modes, output data mapping and DDR output modes
> are
> +configured through input signals and the chip does not expose any control
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry

As explained in a comment to one of the previous versions of this series, I'm 
tempted to make vcc-supply mandatory and drop the three other power supplies 
for now, as I believe there's very little chance they will be connected to 
separately controllable regulators (all supplies use the same voltage). In the 
very unlikely event that this occurs in design we need to support in the 
future, the cvcc, lvcc and pvcc supplies can be added later as optional 
without breaking backward compatibility.

Apart from that,

Reviewed-by: Laurent Pinchart 

> +- pdwn-gpios: Power down GPIO signal. Active low
> +- oe-gpios: Output enable GPIO signal. Active high
> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by
> Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <_lvds_vcc>;
> + lvcc-supply = <_lvds_lvcc>;
> +
> + pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };

-- 
Regards,

Laurent Pinchart

[PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++
 1 file changed, 66 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL 
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low
+- oe-gpios: Output enable GPIO signal. Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   lvcc-supply = <_lvds_lvcc>;
+
+   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
-- 
2.7.4

[PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++
 1 file changed, 66 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL 
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low
+- oe-gpios: Output enable GPIO signal. Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   lvcc-supply = <_lvds_lvcc>;
+
+   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
-- 
2.7.4