[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C944CCDB-C1F5-4D6A-901A-B66D8B473E1B@goldelico.com>
Date: Thu, 9 Apr 2020 14:41:40 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Sam Ravnborg <sam@...nborg.org>
Cc: Paul Cercueil <paul@...pouillou.net>,
Paul Boddie <paul@...die.org.uk>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Ralf Baechle <ralf@...ux-mips.org>,
Paul Burton <paulburton@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Andi Kleen <ak@...ux.intel.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Kees Cook <keescook@...omium.org>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-mips@...r.kernel.org, linux-gpio@...r.kernel.org,
mips-creator-ci20-dev@...glegroups.com,
letux-kernel@...nphoenux.org
Subject: Re: [RFC v3 1/8] dt-bindings: display: convert ingenic, lcd.txt to ingenic, lcd.yaml
Hi Sam,
> Am 09.04.2020 um 14:20 schrieb Sam Ravnborg <sam@...nborg.org>:
>
> Hi Nikolaus.
>
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/clock/jz4725b-cgu.h>
>>>> +
>>>> + panel {
>>>> + compatible = "sharp,ls020b1dd01d";
>>>> +
>>>> + backlight = <&backlight>;
>>>> + power-supply = <&vcc>;
>>>> +
>>>> + port {
>>>> + panel_input: endpoint {
>>>> + remote-endpoint = <&panel_output>;
>>>> + };
>>>> + };
>>>> + };
>>> The panel part is not needed - better to drop it.
>>
>> Well, it is needed to fulfill the remote-endpoint below.
>
> Examples may have phandle that are not defined.
> So the example will work fine without it.
> See other similar examples.
Ok.
>
>>
>>>
>>>
>>>> +
>>>> + lcd: lcd-controller@...50000 {
>>>> + compatible = "ingenic,jz4725b-lcd";
>>>> + reg = <0x13050000 0x1000>;
>>>> +
>>>> + interrupt-parent = <&intc>;
>>>> + interrupts = <31>;
>>>> +
>>>> + clocks = <&cgu JZ4725B_CLK_LCD>;
>>>> + clock-names = "lcd", "lcd_pclk";
>>>> +
>>>> + port {
>>>> + panel_output: endpoint {
>>>> + remote-endpoint = <&panel_input>;
>>>> + };
>>>> + };
>>>> + };
>>> We know this example will not pass the check, as there is only
>>> one clock specified.
>>> I suggest to drop this example.
>>> If it later turns out that jz4725b only have one clock,
>>
>> Paul already reported that it only wants to see one clock.
>>
>>> then the binding
>>> needs to be updated.
>>
>> Yes, I have that on my to-do list to update the binding to reflect
>> this minItems/maxItems thing but I am not yet sure about how
>> to handle the clock-names in that case. I.e. make "lcd" optional
>> and enforce "lcd_pclk" only.
> Look forward to next version.
>
>>
>>> But the best guess is that the example is wrong.
>>>
>>> The example below for jz4780-lcd cover all relevant parts - so
>>> just keep it as the only example.
>>>
>>>> +
>>>> + - |
>>>> + #include <dt-bindings/clock/jz4780-cgu.h>
>>>> +
>>>> + lcdc0: lcdc0@...50000 {
>>> Name this lcdc
>>> And drop "lcdc0@...50000" as this is not relevant for this example.
>>>
>>> Remember - the examples exist to explain the binding. They are
>>> just examples.
>>>
>>>> + compatible = "ingenic,jz4780-lcd";
>>>> + reg = <0x13050000 0x1800>;
>>>> +
>>>> + clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
>>>> + clock-names = "lcd", "lcd_pclk";
>>>> +
>>>> + interrupt-parent = <&intc>;
>>>> + interrupts = <31>;
>>>> +
>>>> + jz4780_lcd_out: port {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + jz4780_out_hdmi: endpoint@0 {
>>>> + reg = <0>;
>>>> + remote-endpoint = <&hdmi_in_lcd>;
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>
>>> And drop this as it does not add anything extra.
>>
>> Well, it demonstrates how to add a second lcdc which is disabled.
> The purpose of the example is to show an example of the
> binding specified in this file.
> Adding a second disabled lcdc is a general thing, and not
> something we want in all the individual examples.
This is contrary to what I have expected. My assumption is
that the example is some piece of code that you (and me and
other readers of the bindings documentation) can easily
understand and even copy&paste into a DTS. Like an example
in a training book. This is how I always have used the
.txt bindings when writing new DTS. This ease of use is
lost if the examples are incomplete and show only part
of what is needed to get a working DTS. If not here, where
can one get the required information from?
Or do you see this as unit-test-cases for the formal bindings
definitions? Then, it should IMHO not be named "example".
> Also the actual content, for example register values can be
> random as they are not part of the binding.
> This is not a documentation of the HW but a binding example.
Here it is the bindings for a very specific SoC and the
register values are well defined and there is no choice at
all.
So I'll simplify it for v4 although I don't like the concept
behind.
BR and thanks,
Nikolaus
>
> Sam
>
>>
>> Showing that it is possible to do so is IMHO the most important
>> part of the example because it is not at all obvious.
>>
>> I have also added both SoC to show how differently they can
>> and should be.
>>
>>>> + lcdc1: lcdc1@...a0000 {
>>>> + compatible = "ingenic,jz4780-lcd";
>>>> + reg = <0x130a0000 0x1800>;
>>>> +
>>>> + clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD1PIXCLK>;
>>>> + clock-names = "lcd", "lcd_pclk";
>>>> +
>>>> + interrupt-parent = <&intc>;
>>>> + interrupts = <31>;
>>>> +
>>>> + status = "disabled";
>>>> + };
>>>
>>> Sam
>>
>> BR and thanks,
>> Nikolaus
>>
Powered by blists - more mailing lists