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 <jacopo+renesas@xxxxxxxxxx> >>>>>>> Reviewed-by: Andrzej Hajda <a.hajda@xxxxxxxxxxx> >>>>>>> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx> >>>>>>> --- >>>>>>> .../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 0000000..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 <laurent.pinchart@xxxxxxxxxxxxxxxx> >>>>>> >>>>>>> +- 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
