This patchset adds interconnect API support for the Exynos SoC "samsung,
exynos-bus" compatible devices, which already have their corresponding
exynos-bus driver in the devfreq subsystem. Complementing the devfreq
driver with an interconnect functionality allows to ensure the QoS
requirements of devices accessing the system memory (e.g. video processing
devices) are fulfilled and aallows to avoid issues like the one discussed
in thread [1].
This patch series adds implementation of the interconnect provider per each
"samsung,exynos-bus" compatible DT node, with one interconnect node per
provider. The interconnect code which was previously added as a part of
the devfreq driver has been converted to a separate platform driver.
In the devfreq a corresponding virtual child platform device is registered.
Integration of devfreq and interconnect frameworks is achieved through
the PM QoS API.
A sample interconnect consumer for exynos-mixer is added in patches 5/6,
6/6, it is currently added only for exynos4412 and allows to address the
mixer DMA underrun error issues [1].
Main changes since v5 [3] is an addition of "bus-width: DT property, which
specifies data width of the interconnect bus (patches 1...2/6 and addition
of synchronization of the interconnect bandwidth setting with VSYNC
(patch 6/6).
The series has been tested on Odroid U3 board. It is based on icc-next
branch, which already includes required patches [2]:
26c205e interconnect: Allow inter-provider pairs to be configured
0db4ee05 interconnect: Relax requirement in of_icc_get_from_provider()
6998a7c interconnect: Export of_icc_get_from_provider()
--
Regards,
Sylwester
Changes since v3 [4] (v4 skipped to align with patchset [1]), detailed
changes are listed in each patch:
- conversion to a separate interconnect (platform) driver,
- an update of the DT binding documenting new optional properties:
#interconnect-cells, samsung,interconnect-parent in "samsung,exynos-bus"
nodes,
- new DT properties added to the SoC, rather than to the board specific
files.
Changes since v2 [5]:
- Use icc_std_aggregate().
- Implement a different modification of apply_constraints() in
drivers/interconnect/core.c (patch 03).
- Use 'exynos,interconnect-parent-node' in the DT instead of
'devfreq'/'parent', depending on the bus.
- Rebase on DT patches that deprecate the 'devfreq' DT property.
- Improve error handling, including freeing generated IDs on failure.
- Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent().
Changes since v1 [6]:
- Rebase on coupled regulators patches.
- Use dev_pm_qos_*() API instead of overriding frequency in
exynos_bus_target().
- Use IDR for node ID allocation.
- Reverse order of multiplication and division in
mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow.
References:
[1] https://patchwork.kernel.org/patch/10861757/ (original issue)
[2] https://www.spinics.net/lists/linux-samsung-soc/msg70014.html
[3] https://www.spinics.net/lists/arm-kernel/msg810722.html
[4] https://lore.kernel.org/linux-pm/[email protected]
[5] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
[6] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC)
Artur Świgoń (1):
ARM: dts: exynos: Add interconnects to Exynos4412 mixer
Sylwester Nawrocki (5):
dt-bindings: exynos-bus: Add documentation for interconnect properties
interconnect: Add generic interconnect driver for Exynos SoCs
PM / devfreq: exynos-bus: Add registration of interconnect child
device
ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
drm: exynos: mixer: Add interconnect support
.../devicetree/bindings/devfreq/exynos-bus.txt | 68 +++++++-
arch/arm/boot/dts/exynos4412.dtsi | 7 +
drivers/devfreq/exynos-bus.c | 17 ++
drivers/gpu/drm/exynos/exynos_mixer.c | 150 +++++++++++++++-
drivers/interconnect/Kconfig | 1 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/exynos/Kconfig | 6 +
drivers/interconnect/exynos/Makefile | 4 +
drivers/interconnect/exynos/exynos.c | 192 +++++++++++++++++++++
9 files changed, 436 insertions(+), 10 deletions(-)
create mode 100644 drivers/interconnect/exynos/Kconfig
create mode 100644 drivers/interconnect/exynos/Makefile
create mode 100644 drivers/interconnect/exynos/exynos.c
--
2.7.4
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ń <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
---
Changes for v6:
- added dts example of bus hierarchy definition and the interconnect
consumer,
- added new bus-width property.
Changes for v5:
- exynos,interconnect-parent-node renamed to samsung,interconnect-parent
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 68 +++++++++++++++++++++-
1 file changed, 66 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index e71f752..4035e3e 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -51,6 +51,13 @@ Optional properties only for parent bus device:
- exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
+Optional properties for interconnect functionality (QoS frequency constraints):
+- samsung,interconnect-parent: phandle to the parent interconnect node; for
+ passive devices should point to same node as the exynos,parent-bus property.
+- #interconnect-cells: should be 0.
+- bus-width: the interconnect bus width in bits, default value is 8 when this
+ property is missing.
+
Detailed correlation between sub-blocks and power line according to Exynos SoC:
- In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC
@@ -135,7 +142,7 @@ Detailed correlation between sub-blocks and power line according to Exynos SoC:
|--- PERIC (Fixed clock rate)
|--- FSYS (Fixed clock rate)
-Example1:
+Example 1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regulator.
@@ -184,7 +191,7 @@ Example1:
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
----------------------------------------------------------
-Example2 :
+Example 2:
The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
is listed below:
@@ -419,3 +426,60 @@ Example2 :
devfreq = <&bus_leftbus>;
status = "okay";
};
+
+Example 3:
+ An interconnect path "bus_display -- bus_leftbus -- bus_dmc" on
+ Exynos4412 SoC with video mixer as an interconnect consumer device.
+
+ soc {
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ bus-width = <4>;
+ #interconnect-cells = <0>;
+ status = "disabled";
+ };
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ samsung,interconnect-parent = <&bus_dmc>;
+ #interconnect-cells = <0>;
+ status = "disabled";
+ };
+
+ bus_display: bus_display {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_display_opp_table>;
+ samsung,interconnect-parent = <&bus_leftbus>;
+ #interconnect-cells = <0>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ /* ... */
+ }
+
+ bus_leftbus_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ /* ... */
+ };
+
+ bus_display_opp_table: opp_table4 {
+ compatible = "operating-points-v2";
+ /* .. */
+ };
+
+ &mixer {
+ compatible = "samsung,exynos4212-mixer";
+ interconnects = <&bus_display &bus_dmc>;
+ /* ... */
+ };
+ };
--
2.7.4
This patch adds the following properties for Exynos4412 interconnect
bus nodes:
- samsung,interconnect-parent: to declare connections between
nodes in order to guarantee PM QoS requirements between nodes,
- #interconnect-cells: required by the interconnect framework,
- bus-width: the bus width in bits, required to properly derive
minimum bus clock frequency from requested bandwidth for each
bus.
Note that #interconnect-cells is always zero and node IDs are not
hardcoded anywhere.
Signed-off-by: Artur Świgoń <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
---
Changes for v6:
- added bus-width property in bus_dmc node.
Changes for v5:
- adjust to renamed exynos,interconnect-parent-node property,
- add properties in common exynos4412.dtsi file rather than
in Odroid specific odroid4412-odroid-common.dtsi.
---
arch/arm/boot/dts/exynos4412.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 4886894..24529d4 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -381,6 +381,8 @@
clocks = <&clock CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
+ bus-width = <4>;
+ #interconnect-cells = <0>;
status = "disabled";
};
@@ -450,6 +452,8 @@
clocks = <&clock CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
+ samsung,interconnect-parent = <&bus_dmc>;
+ #interconnect-cells = <0>;
status = "disabled";
};
@@ -466,6 +470,8 @@
clocks = <&clock CLK_ACLK160>;
clock-names = "bus";
operating-points-v2 = <&bus_display_opp_table>;
+ samsung,interconnect-parent = <&bus_leftbus>;
+ #interconnect-cells = <0>;
status = "disabled";
};
--
2.7.4
Hi Sylwester,
On 7/3/20 1:37 AM, 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ń <[email protected]>
> Signed-off-by: Sylwester Nawrocki <[email protected]>
> ---
> Changes for v6:
> - added dts example of bus hierarchy definition and the interconnect
> consumer,
> - added new bus-width property.
>
> Changes for v5:
> - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 68 +++++++++++++++++++++-
> 1 file changed, 66 insertions(+), 2 deletions(-)
Acked-by: Chanwoo Choi <[email protected]>
(snip)
--
Best Regards,
Chanwoo Choi
Samsung Electronics
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ń <[email protected]>
> Signed-off-by: Sylwester Nawrocki <[email protected]>
> ---
> Changes for v6:
> - added dts example of bus hierarchy definition and the interconnect
> consumer,
> - added new bus-width property.
>
> Changes for v5:
> - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 68 +++++++++++++++++++++-
> 1 file changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index e71f752..4035e3e 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -51,6 +51,13 @@ Optional properties only for parent bus device:
> - exynos,saturation-ratio: the percentage value which is used to calibrate
> the performance count against total cycle count.
>
> +Optional properties for interconnect functionality (QoS frequency constraints):
> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
> + passive devices should point to same node as the exynos,parent-bus property.
Adding vendor specific properties for a common binding defeats the
point.
> +- #interconnect-cells: should be 0.
> +- bus-width: the interconnect bus width in bits, default value is 8 when this
> + property is missing.
Your bus is 8-bits or 4-bits as the example?
> +
> Detailed correlation between sub-blocks and power line according to Exynos SoC:
> - In case of Exynos3250, there are two power line as following:
> VDD_MIF |--- DMC
> @@ -135,7 +142,7 @@ Detailed correlation between sub-blocks and power line according to Exynos SoC:
> |--- PERIC (Fixed clock rate)
> |--- FSYS (Fixed clock rate)
>
> -Example1:
> +Example 1:
> Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
> power line (regulator). The MIF (Memory Interface) AXI bus is used to
> transfer data between DRAM and CPU and uses the VDD_MIF regulator.
> @@ -184,7 +191,7 @@ Example1:
> |L5 |200000 |200000 |400000 |300000 | ||1000000 |
> ----------------------------------------------------------
>
> -Example2 :
> +Example 2:
> The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> is listed below:
>
> @@ -419,3 +426,60 @@ Example2 :
> devfreq = <&bus_leftbus>;
> status = "okay";
> };
> +
> +Example 3:
> + An interconnect path "bus_display -- bus_leftbus -- bus_dmc" on
> + Exynos4412 SoC with video mixer as an interconnect consumer device.
> +
> + soc {
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + bus-width = <4>;
> + #interconnect-cells = <0>;
> + status = "disabled";
> + };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + samsung,interconnect-parent = <&bus_dmc>;
> + #interconnect-cells = <0>;
> + status = "disabled";
> + };
> +
> + bus_display: bus_display {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_ACLK160>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_display_opp_table>;
> + samsung,interconnect-parent = <&bus_leftbus>;
> + #interconnect-cells = <0>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + /* ... */
> + }
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + /* ... */
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + /* .. */
> + };
> +
> + &mixer {
> + compatible = "samsung,exynos4212-mixer";
> + interconnects = <&bus_display &bus_dmc>;
> + /* ... */
> + };
> + };
> --
> 2.7.4
>
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ń <[email protected]>
>> Signed-off-by: Sylwester Nawrocki <[email protected]>
>> ---
>> .../devicetree/bindings/devfreq/exynos-bus.txt | 68 +++++++++++++++++++++-
>> 1 file changed, 66 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> index e71f752..4035e3e 100644
>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -51,6 +51,13 @@ Optional properties only for parent bus device:
>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>> the performance count against total cycle count.
>>
>> +Optional properties for interconnect functionality (QoS frequency constraints):
>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>> + passive devices should point to same node as the exynos,parent-bus property.
>
> Adding vendor specific properties for a common binding defeats the
> point.
Should we make it then a common interconnect-parent property? Perhaps allowing
also a second cell after the phandle to indicate the target interconnect id?
Currently the links are only being defined in drivers, I'm not sure if we want
to go that direction and extend the interconnect binding so it is possible
to define any link between the nodes.
With the samsung,interconnect-parent property there was an assumption that
each DT node ("samsung,exynos-bus" compatible) corresponds to an interconnect
provider with single interconnect node. The source and destination node id
for the link were unspecified and dynamically allocated by the driver.
I guess we don't want a property that would contain pairs of the interconnect
node specifiers (phandle + interconnect id) to define all links, since usually
additional data is required per each link.
Then perhaps we could make the new interconnect-parent property applicable
only to DT nodes with #interconnect-cells == 0, i.e. valid only in such DT
nodes?
>> +- #interconnect-cells: should be 0.
>> +- bus-width: the interconnect bus width in bits, default value is 8 when this
>> + property is missing.
>
> Your bus is 8-bits or 4-bits as the example?
Bus width might not be a good term for the intended purpose of that property.
It has been added to specify minimum bus clock rate required for given data
throughput. After checking the documentation again the AXI bus width is
actually 128 bits everywhere for instance. The example defines data path
leftbus <- dmc <- (memory) and for leftbus we have bus-width=<8> and for dmc
bus-width=<4>.
Perhaps it's better to use a vendor specific property instead, e.g.
samsung, data-clock-ratio?
--
Thanks,
Sylwester
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ń <[email protected]>
>>> Signed-off-by: Sylwester Nawrocki <[email protected]>
>>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>> @@ -51,6 +51,13 @@ Optional properties only for parent bus device:
>>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>>> the performance count against total cycle count.
>>>
>>> +Optional properties for interconnect functionality (QoS frequency constraints):
>>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>>> + passive devices should point to same node as the exynos,parent-bus property.
>> Adding vendor specific properties for a common binding defeats the
>> point.
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>;
#interconnect-cells = <0>;
};
&mixer {
compatible = "samsung,exynos4212-mixer";
interconnects = <&bus_display &bus_dmc>;
/* ... */
};
};
What do you think, Georgi, Rob?
--
Regards
Sylwester
Hi Sylwester,
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ń <[email protected]>
>>>> Signed-off-by: Sylwester Nawrocki <[email protected]>
>
>>>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>>> @@ -51,6 +51,13 @@ Optional properties only for parent bus device:
>>>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>>>> the performance count against total cycle count.
>>>>
>>>> +Optional properties for interconnect functionality (QoS frequency constraints):
>>>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>>>> + passive devices should point to same node as the exynos,parent-bus property.
>
>>> Adding vendor specific properties for a common binding defeats the
>>> point.
>
> 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>;
> #interconnect-cells = <0>;
> };
>
>
> &mixer {
> compatible = "samsung,exynos4212-mixer";
> interconnects = <&bus_display &bus_dmc>;
> /* ... */
> };
> };
>
> What do you think, Georgi, Rob?
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,
Georgi
Hi Georgi,
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ń <[email protected]>
>>>>> Signed-off-by: Sylwester Nawrocki <[email protected]>
>>
>>>>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>>>> +Optional properties for interconnect functionality (QoS frequency constraints):
>>>>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>>>>> + passive devices should point to same node as the exynos,parent-bus property.
>>
>>>> Adding vendor specific properties for a common binding defeats the
>>>> point.
>>
>> 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>;
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.
>> #interconnect-cells = <0>;
>> };
>>
>>
>> &mixer {
>> compatible = "samsung,exynos4212-mixer";
>> interconnects = <&bus_display &bus_dmc>;
>> /* ... */
>> };
>> };
>>
>> What do you think, Georgi, Rob?
>
> 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<------------------------------
--
Regards,
Sylwester
Hi Sylwester,
On 9/9/20 17:47, Sylwester Nawrocki wrote:
> Hi Georgi,
>
> 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ń <[email protected]>
>>>>>> Signed-off-by: Sylwester Nawrocki <[email protected]>
>>>
>>>>>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>>>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>
>>>>>> +Optional properties for interconnect functionality (QoS frequency constraints):
>>>>>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>>>>>> + passive devices should point to same node as the exynos,parent-bus property.
>>>
>>>>> Adding vendor specific properties for a common binding defeats the
>>>>> point.
>>>
>>> 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 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.
>>> #interconnect-cells = <0>;
>>> };
>>>
>>>
>>> &mixer {
>>> compatible = "samsung,exynos4212-mixer";
>>> interconnects = <&bus_display &bus_dmc>;
>>> /* ... */
>>> };
>>> };
>>>
>>> What do you think, Georgi, Rob?
>>
>> 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.
Thanks,
Georgi
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ń <[email protected]>
>>>>>>> Signed-off-by: Sylwester Nawrocki <[email protected]>
>>>>>>> +++ 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