From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751026AbeC0Ial (ORCPT ); Tue, 27 Mar 2018 04:30:41 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:50696 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751019AbeC0Iai (ORCPT ); Tue, 27 Mar 2018 04:30:38 -0400 Subject: Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder To: Sergei Shtylyov , jacopo mondi , Andrzej Hajda References: <1521213399-31947-1-git-send-email-jacopo+renesas@jmondi.org> <1521213399-31947-2-git-send-email-jacopo+renesas@jmondi.org> <4060923.7DxT9ae38L@avalon> <20180326222249.tvjiutyd4amlibpa@rob-hp-laptop> <1dd27170-153c-90f6-e13f-949ba7d0d4a9@samsung.com> <20180327073332.GI27746@w540> <70826dc1-d9ea-dc98-f591-c80f1904806a@cogentembedded.com> CC: Jacopo Mondi , Rob Herring , Laurent Pinchart , , , , , , , , , , , From: Vladimir Zapolskiy Message-ID: Date: Tue, 27 Mar 2018 11:30:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <70826dc1-d9ea-dc98-f591-c80f1904806a@cogentembedded.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [137.202.0.87] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 >>>>>> >>>>>>> +- 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