Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad
 MPU
To:     Alexandre TORGUE <alexandre.torgue@foss.st.com>, arnd@arndb.de,
        robh+dt@kernel.org, jagan@amarulasolutions.com,
        Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
        Marcin Sloniewski <marcin.sloniewski@gmail.com>,
        Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc:     linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
        linux-stm32@st-md-mailman.stormreply.com,
        linux-kernel@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
        kuba@kernel.org
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-12-alexandre.torgue@foss.st.com>
 <3b39908b-a263-a5d4-f6ac-ac30ffb06269@denx.de>
 <36e9f0df-dfdb-e2f5-3d6e-ac32a1b8156e@foss.st.com>
 <fa3885df-8977-9540-f2af-d4095f519483@denx.de>
 <3961c9ae-41cc-5a15-2704-ffc0832f0fe8@foss.st.com>
From:   Marek Vasut <marex@denx.de>
Message-ID: <57a7f4bf-42e9-56fb-e898-2c5749f53c60@denx.de>
Date:   Thu, 15 Apr 2021 16:59:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <3961c9ae-41cc-5a15-2704-ffc0832f0fe8@foss.st.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 4/15/21 4:35 PM, Alexandre TORGUE wrote:
> 
> 
> On 4/15/21 4:30 PM, Marek Vasut wrote:
>> On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
>>> Hi Marek
>>
>> Hello Alexandre,
>>
>>>>> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts 
>>>>> b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>>> index 2bc92ef3aeb9..19ef475a48fc 100644
>>>>> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>>> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>>> @@ -82,9 +82,15 @@
>>>>>   };
>>>>>   &ltdc {
>>>>> -    status = "okay";
>>>>> -
>>>>>       port {
>>>>> +        #address-cells = <1>;
>>>>> +        #size-cells = <0>;
>>>>> +
>>>>> +        ltdc_ep0_out: endpoint@0 {
>>>>> +            reg = <0>;
>>>>> +            remote-endpoint = <&sii9022_in>;
>>>>> +        };
>>>>> +
>>>>>           ltdc_ep1_out: endpoint@1 {
>>>>>               reg = <1>;
>>>>>               remote-endpoint = <&dsi_in>;
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi 
>>>>> b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>>> index 64dca5b7f748..e7f10975cacf 100644
>>>>> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>>> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>>> @@ -277,11 +277,7 @@
>>>>>       status = "okay";
>>>>>       port {
>>>>> -        #address-cells = <1>;
>>>>> -        #size-cells = <0>;
>>>>> -
>>>>> -        ltdc_ep0_out: endpoint@0 {
>>>>> -            reg = <0>;
>>>>> +        ltdc_ep0_out: endpoint {
>>>>>               remote-endpoint = <&adv7513_in>;
>>>>>           };
>>>>>       };
>>>>
>>>> I think this is wrong, the AV96 can have two displays connected to 
>>>> two ports of the LTDC, just like DK2 for example.
>>>
>>> As for dk2 address/size cells are added only if there are 2 
>>> endpoints. It is for this reason I moved endpoint0 definition from 
>>> stm32mp15xx-dkx to stm32mp151a-dk1.dts (dk1 has only one endpoint).
>>>
>>> Here it's the same, if you have second endpoint then adress/size will 
>>> have to be added.
>>
>> That's a bit problematic. Consider either the use case of DTO which 
>> adds the other display, or even a custom board DTS. Without your 
>> patch, this works:
>>
>> arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>> &ltdc {
>>    ...
>>    ports {
>>      ltdc_ep0_out: endpoint@0 {
>>        remote-endpoint = <&adv7513_in>;
>>      };
>>    };
>> };
>>
>> board-with-display.dts or board-overlay.dts
>> &ltdc {
>>    ports {
>>      endpoint@1 { // just add another endpoint@1, no problem
>>        remote-endpoint = <&display>;
>>      };
>>    };
>> };
>>
>> With your patch, the DTS would have to modify the "endpoint" node to 
>> be "endpoint@0" probably with a whole lot of /detele-node/ etc. magic 
>> (DTO cannot do that, so that's a problem, and I do use DTOs on AV96 
>> extensively for the various expansion cards) and then add the 
>> endpoint@1. That becomes real complicated in custom board DT, and 
>> impossible with DTO.
> 
> Yes I agree that it'll be problematic. So maybe so solution would be to 
> not detect a warning for the initial case (only one endpoint with a reg)

That looks OK. Or even better, if the checker warned only on IPs which 
cannot have more than one endpoint, but have endpoint@N in DT (where N 
in 0..+inf) . On IPs which can have one or more endpoints, the warning 
should not be emitted.