Add APPS SMMU to SM6125 dtsi and use it in SDHCI/USB nodes.
Changes since v3:
- Drop driver patch in favour of using generic qcom,smmu-500 compatible;
- Add patches that use apps_smmu in USB and SDHCI nodes, reconfiguring
their streamID which otherwise gets lost (from the bootloader) as soon
as SMMU probes, breaking their functionality;
- Rebased on next-20221216 to solve dt-bindings conflict.
v3: https://lore.kernel.org/linux-iommu/[email protected]/T/#u
AngeloGioacchino Del Regno (1):
arm64: dts: qcom: sm6125: Add IOMMU context to DWC3
Marijn Suijten (1):
arm64: dts: qcom: sm6125: Add apps_smmu with streamID to SDHCI 1/2
nodes
Martin Botka (2):
dt-bindings: arm-smmu: Document smmu-500 binding for SM6125
arm64: dts: qcom: sm6125: Configure APPS SMMU
.../devicetree/bindings/iommu/arm,smmu.yaml | 1 +
arch/arm64/boot/dts/qcom/sm6125.dtsi | 76 +++++++++++++++++++
2 files changed, 77 insertions(+)
--
2.39.0
When enabling the APPS SMMU the mainline driver reconfigures the SMMU
from its bootloader configuration, loosing the stream mapping for (among
which) the SDHCI hardware and breaking its ADMA feature. This feature
can be disabled with:
sdhci.debug_quirks=0x40
But it is of course desired to have this feature enabled and working
through the SMMU.
Signed-off-by: Marijn Suijten <[email protected]>
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index 347665c2067c..f560499cc0ca 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -468,6 +468,7 @@ sdhc_1: mmc@4744000 {
<&gcc GCC_SDCC1_APPS_CLK>,
<&xo_board>;
clock-names = "iface", "core", "xo";
+ iommus = <&apps_smmu 0x160 0>;
power-domains = <&rpmpd SM6125_VDDCX>;
@@ -494,6 +495,7 @@ sdhc_2: mmc@4784000 {
<&gcc GCC_SDCC2_APPS_CLK>,
<&xo_board>;
clock-names = "iface", "core", "xo";
+ iommus = <&apps_smmu 0x180 0>;
pinctrl-0 = <&sdc2_on_state>;
pinctrl-1 = <&sdc2_off_state>;
--
2.39.0
From: Martin Botka <[email protected]>
Add a node for the APPS SMMU, to which various devices such as USB and
storage nodes are connected.
Signed-off-by: Martin Botka <[email protected]>
[Marijn: add the new, generic, "qcom,smmu-500" compatible, add patch
description, reorder # properties]
Signed-off-by: Marijn Suijten <[email protected]>
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 73 ++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index bf9e8d45ee44..347665c2067c 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -573,6 +573,79 @@ spmi_bus: spmi@1c40000 {
cell-index = <0>;
};
+ apps_smmu: iommu@c600000 {
+ compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", "arm,mmu-500";
+ reg = <0xc600000 0x80000>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+
+ #global-interrupts = <1>;
+ #iommu-cells = <2>;
+ };
+
apcs_glb: mailbox@f111000 {
compatible = "qcom,sm6125-apcs-hmss-global";
reg = <0x0f111000 0x1000>;
--
2.39.0
From: Martin Botka <[email protected]>
Document smmu-500 compatibility with the SM6125 SoC.
Signed-off-by: Martin Botka <[email protected]>
[Marijn: Move compatible to the new, generic, qcom,smmu-500 list]
Signed-off-by: Marijn Suijten <[email protected]>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index b28c5c2b0ff2..95b03fd86e18 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -43,6 +43,7 @@ properties:
- qcom,sdm670-smmu-500
- qcom,sdm845-smmu-500
- qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
- qcom,sm6350-smmu-500
- qcom,sm6375-smmu-500
- qcom,sm8150-smmu-500
--
2.39.0
On 16.12.2022 22:58, Marijn Suijten wrote:
> When enabling the APPS SMMU the mainline driver reconfigures the SMMU
> from its bootloader configuration, loosing the stream mapping for (among
> which) the SDHCI hardware and breaking its ADMA feature. This feature
> can be disabled with:
>
> sdhci.debug_quirks=0x40
>
> But it is of course desired to have this feature enabled and working
> through the SMMU.
>
> Signed-off-by: Marijn Suijten <[email protected]>
> ---
Reviewed-by: Konrad Dybcio <[email protected]>
Konrad
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> index 347665c2067c..f560499cc0ca 100644
> --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> @@ -468,6 +468,7 @@ sdhc_1: mmc@4744000 {
> <&gcc GCC_SDCC1_APPS_CLK>,
> <&xo_board>;
> clock-names = "iface", "core", "xo";
> + iommus = <&apps_smmu 0x160 0>;
>
> power-domains = <&rpmpd SM6125_VDDCX>;
>
> @@ -494,6 +495,7 @@ sdhc_2: mmc@4784000 {
> <&gcc GCC_SDCC2_APPS_CLK>,
> <&xo_board>;
> clock-names = "iface", "core", "xo";
> + iommus = <&apps_smmu 0x180 0>;
>
> pinctrl-0 = <&sdc2_on_state>;
> pinctrl-1 = <&sdc2_off_state>;
On 16.12.2022 22:58, Marijn Suijten wrote:
> From: Martin Botka <[email protected]>
>
> Add a node for the APPS SMMU, to which various devices such as USB and
> storage nodes are connected.
>
> Signed-off-by: Martin Botka <[email protected]>
> [Marijn: add the new, generic, "qcom,smmu-500" compatible, add patch
> description, reorder # properties]
> Signed-off-by: Marijn Suijten <[email protected]>
> ---
Reviewed-by: Konrad Dybcio <[email protected]>
Konrad
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 73 ++++++++++++++++++++++++++++
> 1 file changed, 73 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> index bf9e8d45ee44..347665c2067c 100644
> --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> @@ -573,6 +573,79 @@ spmi_bus: spmi@1c40000 {
> cell-index = <0>;
> };
>
> + apps_smmu: iommu@c600000 {
> + compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", "arm,mmu-500";
> + reg = <0xc600000 0x80000>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
> +
> + #global-interrupts = <1>;
> + #iommu-cells = <2>;
> + };
> +
> apcs_glb: mailbox@f111000 {
> compatible = "qcom,sm6125-apcs-hmss-global";
> reg = <0x0f111000 0x1000>;
On 2022-12-16 22:58:18, Marijn Suijten wrote:
> When enabling the APPS SMMU the mainline driver reconfigures the SMMU
> from its bootloader configuration, loosing the stream mapping for (among
> which) the SDHCI hardware and breaking its ADMA feature. This feature
> can be disabled with:
>
> sdhci.debug_quirks=0x40
>
> But it is of course desired to have this feature enabled and working
> through the SMMU.
>
> Signed-off-by: Marijn Suijten <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> index 347665c2067c..f560499cc0ca 100644
> --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> @@ -468,6 +468,7 @@ sdhc_1: mmc@4744000 {
> <&gcc GCC_SDCC1_APPS_CLK>,
> <&xo_board>;
> clock-names = "iface", "core", "xo";
> + iommus = <&apps_smmu 0x160 0>;
I'll make the mask 0x0 (same below) in the next revision, please do not
apply this patch.
- Marijn
> power-domains = <&rpmpd SM6125_VDDCX>;
>
> @@ -494,6 +495,7 @@ sdhc_2: mmc@4784000 {
> <&gcc GCC_SDCC2_APPS_CLK>,
> <&xo_board>;
> clock-names = "iface", "core", "xo";
> + iommus = <&apps_smmu 0x180 0>;
>
> pinctrl-0 = <&sdc2_on_state>;
> pinctrl-1 = <&sdc2_off_state>;
> --
> 2.39.0
>
On Fri, Dec 16 2022 at 10:58:18 PM +01:00:00, Marijn Suijten
<[email protected]> wrote:
> When enabling the APPS SMMU the mainline driver reconfigures the SMMU
> from its bootloader configuration, loosing the stream mapping for
> (among
> which) the SDHCI hardware and breaking its ADMA feature. This feature
> can be disabled with:
>
> sdhci.debug_quirks=0x40
>
> But it is of course desired to have this feature enabled and working
> through the SMMU.
>
> Signed-off-by: Marijn Suijten <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/sm6125.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> index 347665c2067c..f560499cc0ca 100644
> --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> @@ -468,6 +468,7 @@ sdhc_1: mmc@4744000 {
> <&gcc GCC_SDCC1_APPS_CLK>,
> <&xo_board>;
> clock-names = "iface", "core", "xo";
> + iommus = <&apps_smmu 0x160 0>;
>
> power-domains = <&rpmpd SM6125_VDDCX>;
>
> @@ -494,6 +495,7 @@ sdhc_2: mmc@4784000 {
> <&gcc GCC_SDCC2_APPS_CLK>,
> <&xo_board>;
> clock-names = "iface", "core", "xo";
> + iommus = <&apps_smmu 0x180 0>;
>
> pinctrl-0 = <&sdc2_on_state>;
> pinctrl-1 = <&sdc2_off_state>;
> --
> 2.39.0
>
With 0x0 as mask
Reviewed-by: Martin Botka <[email protected]>
-Martin
On 16/12/2022 22:58, Marijn Suijten wrote:
> From: Martin Botka <[email protected]>
>
> Document smmu-500 compatibility with the SM6125 SoC.
>
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On 19/12/2022 10:07, Krzysztof Kozlowski wrote:
> On 16/12/2022 22:58, Marijn Suijten wrote:
>> From: Martin Botka <[email protected]>
>>
>> Document smmu-500 compatibility with the SM6125 SoC.
>>
>
> Acked-by: Krzysztof Kozlowski <[email protected]>
Wait, not entirely... no constraints for clocks and regs?
Best regards,
Krzysztof
On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote:
> On 19/12/2022 10:07, Krzysztof Kozlowski wrote:
> > On 16/12/2022 22:58, Marijn Suijten wrote:
> >> From: Martin Botka <[email protected]>
> >>
> >> Document smmu-500 compatibility with the SM6125 SoC.
> >>
> >
> > Acked-by: Krzysztof Kozlowski <[email protected]>
>
> Wait, not entirely... no constraints for clocks and regs?
Quite odd that there is no warning for my DT patch as it clearly
requires at least one clock...
Irrespective of that downstream doesn't define any (nor power domains).
How should we proceed?
- Marijn
On 19/12/2022 20:28, Marijn Suijten wrote:
> On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote:
>> On 19/12/2022 10:07, Krzysztof Kozlowski wrote:
>>> On 16/12/2022 22:58, Marijn Suijten wrote:
>>>> From: Martin Botka <[email protected]>
>>>>
>>>> Document smmu-500 compatibility with the SM6125 SoC.
>>>>
>>>
>>> Acked-by: Krzysztof Kozlowski <[email protected]>
>>
>> Wait, not entirely... no constraints for clocks and regs?
>
> Quite odd that there is no warning for my DT patch as it clearly
> requires at least one clock...
>
> Irrespective of that downstream doesn't define any (nor power domains).
> How should we proceed?
Binding now has constraints for clocks so at least that should be added
to your variant.
Best regards,
Krzysztof
On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote:
> On 19/12/2022 20:28, Marijn Suijten wrote:
> > On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote:
> >> On 19/12/2022 10:07, Krzysztof Kozlowski wrote:
> >>> On 16/12/2022 22:58, Marijn Suijten wrote:
> >>>> From: Martin Botka <[email protected]>
> >>>>
> >>>> Document smmu-500 compatibility with the SM6125 SoC.
> >>>>
> >>>
> >>> Acked-by: Krzysztof Kozlowski <[email protected]>
> >>
> >> Wait, not entirely... no constraints for clocks and regs?
> >
> > Quite odd that there is no warning for my DT patch as it clearly
> > requires at least one clock...
Again, any idea why there's no warning for this DT mismatching minItems:
1 for clocks, clock-names and power-domains?
> > Irrespective of that downstream doesn't define any (nor power domains).
> > How should we proceed?
>
> Binding now has constraints for clocks so at least that should be added
> to your variant.
And that should be:
clock-names: false
clocks: false
power-domains: false
Because this board does declare have any, at least not when going off of
downstream DT?
- Marijn
On 22/12/2022 09:23, Marijn Suijten wrote:
> On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote:
>> On 19/12/2022 20:28, Marijn Suijten wrote:
>>> On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote:
>>>> On 19/12/2022 10:07, Krzysztof Kozlowski wrote:
>>>>> On 16/12/2022 22:58, Marijn Suijten wrote:
>>>>>> From: Martin Botka <[email protected]>
>>>>>>
>>>>>> Document smmu-500 compatibility with the SM6125 SoC.
>>>>>>
>>>>>
>>>>> Acked-by: Krzysztof Kozlowski <[email protected]>
>>>>
>>>> Wait, not entirely... no constraints for clocks and regs?
>>>
>>> Quite odd that there is no warning for my DT patch as it clearly
>>> requires at least one clock...
>
> Again, any idea why there's no warning for this DT mismatching minItems:
> 1 for clocks, clock-names and power-domains?
I don't know what do you have in DT and what is mismatched. Why there
should be a warning?
>
>>> Irrespective of that downstream doesn't define any (nor power domains).
>>> How should we proceed?
>>
>> Binding now has constraints for clocks so at least that should be added
>> to your variant.
>
> And that should be:
>
> clock-names: false
> clocks: false
> power-domains: false
>
> Because this board does declare have any, at least not when going off of
> downstream DT?
I'll add it for existing platforms, so you can rebase on top.
Best regards,
Krzysztof
On 2022-12-22 10:29:40, Krzysztof Kozlowski wrote:
> On 22/12/2022 09:23, Marijn Suijten wrote:
> > On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote:
> >> On 19/12/2022 20:28, Marijn Suijten wrote:
> >>> On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote:
> >>>> On 19/12/2022 10:07, Krzysztof Kozlowski wrote:
> >>>>> On 16/12/2022 22:58, Marijn Suijten wrote:
> >>>>>> From: Martin Botka <[email protected]>
> >>>>>>
> >>>>>> Document smmu-500 compatibility with the SM6125 SoC.
> >>>>>>
> >>>>>
> >>>>> Acked-by: Krzysztof Kozlowski <[email protected]>
> >>>>
> >>>> Wait, not entirely... no constraints for clocks and regs?
> >>>
> >>> Quite odd that there is no warning for my DT patch as it clearly
> >>> requires at least one clock...
> >
> > Again, any idea why there's no warning for this DT mismatching minItems:
> > 1 for clocks, clock-names and power-domains?
>
> I don't know what do you have in DT and what is mismatched. Why there
> should be a warning?
There is:
clock-names:
minItems: 1
maxItems: 7
clocks:
minItems: 1
maxItems: 7
But I did not provide _any_ (see patch 2 of this series). Shouldn't
that trigger a warning?
> >>> Irrespective of that downstream doesn't define any (nor power domains).
> >>> How should we proceed?
> >>
> >> Binding now has constraints for clocks so at least that should be added
> >> to your variant.
> >
> > And that should be:
> >
> > clock-names: false
> > clocks: false
> > power-domains: false
> >
> > Because this board does declare have any, at least not when going off of
> > downstream DT?
>
> I'll add it for existing platforms, so you can rebase on top.
Thanks, will do!
- Marijn
On 22/12/2022 11:10, Marijn Suijten wrote:
> On 2022-12-22 10:29:40, Krzysztof Kozlowski wrote:
>> On 22/12/2022 09:23, Marijn Suijten wrote:
>>> On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote:
>>>> On 19/12/2022 20:28, Marijn Suijten wrote:
>>>>> On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote:
>>>>>> On 19/12/2022 10:07, Krzysztof Kozlowski wrote:
>>>>>>> On 16/12/2022 22:58, Marijn Suijten wrote:
>>>>>>>> From: Martin Botka <[email protected]>
>>>>>>>>
>>>>>>>> Document smmu-500 compatibility with the SM6125 SoC.
>>>>>>>>
>>>>>>>
>>>>>>> Acked-by: Krzysztof Kozlowski <[email protected]>
>>>>>>
>>>>>> Wait, not entirely... no constraints for clocks and regs?
>>>>>
>>>>> Quite odd that there is no warning for my DT patch as it clearly
>>>>> requires at least one clock...
>>>
>>> Again, any idea why there's no warning for this DT mismatching minItems:
>>> 1 for clocks, clock-names and power-domains?
>>
>> I don't know what do you have in DT and what is mismatched. Why there
>> should be a warning?
>
> There is:
>
> clock-names:
> minItems: 1
> maxItems: 7
>
> clocks:
> minItems: 1
> maxItems: 7
>
> But I did not provide _any_ (see patch 2 of this series). Shouldn't
> that trigger a warning?
No. Are these required properties?
Best regards,
Krzysztof
On 2022-12-22 11:36:49, Krzysztof Kozlowski wrote:
> [..]
> > There is:
> >
> > clock-names:
> > minItems: 1
> > maxItems: 7
> >
> > clocks:
> > minItems: 1
> > maxItems: 7
> >
> > But I did not provide _any_ (see patch 2 of this series). Shouldn't
> > that trigger a warning?
>
> No. Are these required properties?
Ah right, this has no effect if the property is not required. Only if
the property is set should it adhere to minItems; that is, `clocks;` or
`clock-names;` as boolean property isn't allowed, it has to have `clocks
= <between 1 and 7 items>`.
- Marijn