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>
From:   Marek Vasut <marex@denx.de>
Message-ID: <fa3885df-8977-9540-f2af-d4095f519483@denx.de>
Date:   Thu, 15 Apr 2021 16:30:38 +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: <36e9f0df-dfdb-e2f5-3d6e-ac32a1b8156e@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 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.