Message-ID: <ca0417b2-fddf-cec5-c3b6-0ec80958d4c0@samsung.com>
Date:   Fri, 30 Oct 2020 13:29:07 +0100
From:   Sylwester Nawrocki <s.nawrocki@...sung.com>
To:     Georgi Djakov <georgi.djakov@...aro.org>,
        Rob Herring <robh@...nel.org>
Cc:     cw00.choi@...sung.com, krzk@...nel.org, devicetree@...r.kernel.org,
        a.swigon@...sung.com, myungjoo.ham@...sung.com,
        inki.dae@...sung.com, sw0312.kim@...sung.com,
        b.zolnierkie@...sung.com, m.szyprowski@...sung.com,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation
 for interconnect properties

Hi Georgi,

On 15.09.2020 23:40, Georgi Djakov wrote:
> On 9/9/20 17:47, Sylwester Nawrocki wrote:
>> On 09.09.2020 11:07, Georgi Djakov wrote:
>>> On 8/28/20 17:49, Sylwester Nawrocki wrote:
>>>> On 30.07.2020 14:28, Sylwester Nawrocki wrote:
>>>>> On 09.07.2020 23:04, Rob Herring wrote:
>>>>>> On Thu, Jul 02, 2020 at 06:37:19PM +0200, Sylwester Nawrocki wrote:
>>>>>>> Add documentation for new optional properties in the exynos bus nodes:
>>>>>>> samsung,interconnect-parent, #interconnect-cells, bus-width.
>>>>>>> These properties allow to specify the SoC interconnect structure which
>>>>>>> then allows the interconnect consumer devices to request specific
>>>>>>> bandwidth requirements.

>>>>>>> Signed-off-by: Artur Świgoń <a.swigon@...sung.com>
>>>>>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@...sung.com>

>>>>>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt

>>>> Actually we could do without any new property if we used existing interconnect
>>>> consumers binding to specify linking between the provider nodes. I think those
>>>> exynos-bus nodes could well be considered both the interconnect providers 
>>>> and consumers. The example would then be something along the lines 
>>>> (yes, I know the bus node naming needs to be fixed):
>>>>
>>>> 	soc {
>>>> 		bus_dmc: bus_dmc {
>>>> 			compatible = "samsung,exynos-bus";
>>>> 			/* ... */
>>>> 			samsung,data-clock-ratio = <4>;
>>>> 			#interconnect-cells = <0>;
>>>> 		};
>>>>
>>>> 		bus_leftbus: bus_leftbus {
>>>> 			compatible = "samsung,exynos-bus";
>>>> 			/* ... */
>>>> 			interconnects = <&bus_leftbus &bus_dmc>;
>>>> 			#interconnect-cells = <0>;
>>>> 		};
>>>>
>>>> 		bus_display: bus_display {
>>>> 			compatible = "samsung,exynos-bus";
>>>> 			/* ... */
>>>> 			interconnects = <&bus_display &bus_leftbus>;
>>>
>>> Hmm, bus_display being a consumer of itself is a bit odd? Did you mean:
>>>  			interconnects = <&bus_dmc &bus_leftbus>;
>>
>> Might be, but we would need to swap the phandles so <source, destination>
>> order is maintained, i.e. interconnects = <&bus_leftbus &bus_dmc>;
> 
> Ok, i see. Thanks for clarifying! Currently the "interconnects" property is
> defined as a pair of initiator and target nodes. You can keep it also as
> interconnects = <&bus_display &bus_dmc>, but you will need to figure out
> during probe that there is another node in the middle and defer. I assume
> that if a provider is also an interconnect consumer, we will link it to
> whatever nodes are specified in the "interconnects" property?

My apologies for the delay.

Yes, the "interconnect" property would be used (only) to determine what
links should be created.

>> My intention here was to describe the 'bus_display -> bus_leftbus' part 
>> of data path 'bus_display -> bus_leftbus -> bus_dmc', bus_display is
>> really a consumer of 'bus_leftbus -> bus_dmc' path.
>>
>> I'm not sure if it is allowed to specify only single phandle (and 
>> interconnect provider specifier) in the interconnect property, that would
>> be needed for the bus_leftbus node to define bus_dmc as the interconnect 
>> destination port. There seems to be such a use case in arch/arm64/boot/
>> dts/allwinner/sun50i-a64.dtsi.
> 
> In the general case you have to specify pairs. The "dma-mem" is a reserved
> name for devices that perform DMA through another bus with separate address
> translation rules.

I see, thanks for clarifying.

>>> I can't understand the above example with bus_display being it's own consumer.
>>> This seems strange to me. Could you please clarify it?
>>
>>> Otherwise the interconnect consumer DT bindings are already well established
>>> and i don't see anything preventing a node to be both consumer and provider.
>>> So this should be okay in general.
>>
>> Thanks, below is an updated example according to your suggestions. 
>> Does it look better now?
>>
>> ---------------------------8<------------------------------
>> soc {
>> 	bus_dmc: bus_dmc {
>> 		compatible = "samsung,exynos-bus";
>> 		/* ... */
>> 		samsung,data-clock-ratio = <4>;
>> 		#interconnect-cells = <0>;
>> 	};
>>
>> 	bus_leftbus: bus_leftbus {
>> 		compatible = "samsung,exynos-bus";
>> 		/* ... */
>> 		interconnects = <&bus_dmc>;
>> 		#interconnect-cells = <0>;
>> 	};
>>
>> 	bus_display: bus_display {
>> 		compatible = "samsung,exynos-bus";
>> 		/* ... */
>> 		interconnects = <&bus_leftbus &bus_dmc>;
>> 		#interconnect-cells = <0>;
>> 	};
>>
>> 	&mixer {
>> 		compatible = "samsung,exynos4212-mixer";
>> 		interconnects = <&bus_display &bus_dmc>;
>> 		/* ... */
>> 	};
>> };
>> ---------------------------8<------------------------------
> 
> It's difficult to have a common way to describe all the different kinds of
> topologies in DT, as some SoCs are very complex, having multi-tiered topologies
> with hundreds of nodes, with multiple links between them etc. Currently, the
> idea is to have the topology as platform data, but i guess that you want to
> avoid this. I hope that we will be able to describe simpler topologies in DT in
> the future, but we don't have such support in the framework yet.
> 
> So maybe we could try your proposal and see how it will work for exynos.

I suppose for any new Exynos SoCs with more complex interconnects exposed
for software control an approach with topology definition as platform data 
would also be used. The generic interconnect driver would likely only be 
used on existing platforms where the interconnects are somewhat abstracted 
by the devfreq.   

-- 
Regards,
Sylwester

Powered by blists - more mailing lists