Signed-off-by: Konrad Dybcio <[email protected]>
---
Changes in v2:
- Explicitly call the thing the PCIe SMMU, rewrite the commit msg
- Add 8280-specific bindings
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Konrad Dybcio (2):
dt-bindings: iommu: arm,smmu-v3: Add SC8280XP compatible
arm64: dts: qcom: sc8280xp: Describe the PCIe SMMUv3
Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 6 +++++-
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 16 ++++++++++++++++
2 files changed, 21 insertions(+), 1 deletion(-)
---
base-commit: 8ffc8b1bbd505e27e2c8439d326b6059c906c9dd
change-id: 20231219-topic-8280_smmuv3-51d8795af7ec
Best regards,
--
Konrad Dybcio <[email protected]>
The smmu-v3 binding currently doesn't differentiate the SoCs it's
implemented on. This is a poor design choice that may bite in the future,
should any quirks surface.
Add a compatible for the instance found on Qualcomm SC8280XP.
Signed-off-by: Konrad Dybcio <[email protected]>
---
Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
index 75fcf4cb52d9..f284f7b0c1d8 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
@@ -20,7 +20,11 @@ properties:
$nodename:
pattern: "^iommu@[0-9a-f]*"
compatible:
- const: arm,smmu-v3
+ oneOf:
+ - items:
+ - const: qcom,sc8280xp-smmu-v3
+ - const: arm,smmu-v3
+ - const: arm,smmu-v3
reg:
maxItems: 1
--
2.44.0
SC8280XP actually has a third SMMU, which can be seen in e.g. the IORT
ACPI table and is used for the PCIe hosts.
Unfortunately though, the secure firmware seems to be configured in a
way such that Linux can't touch it, not even read back the ID registers.
It also seems like the SMMU is configured to run in some sort of bypass
mode, completely opaque to the OS.
Describe it so that one can configure it when running Linux as a
hypervisor (e.g with [1]) and for hardware description completeness.
[1] https://github.com/TravMurav/slbounce
Signed-off-by: Konrad Dybcio <[email protected]>
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index a5b194813079..28edd30a9c04 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -4648,6 +4648,22 @@ cci3_i2c1_sleep: cci3-i2c1-sleep-pins {
};
};
+ pcie_smmu: iommu@14f80000 {
+ compatible = "qcom,sc8280xp-smmu-v3", "arm,smmu-v3";
+ reg = <0 0x14f80000 0 0x80000>;
+ interrupts = <GIC_SPI 951 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 955 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 953 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "eventq",
+ "gerror",
+ "cmdq-sync";
+ #iommu-cells = <1>;
+ dma-coherent;
+
+ /* The hypervisor prevents register access from Linux */
+ status = "reserved";
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,sc8280xp-smmu-500", "arm,mmu-500";
reg = <0 0x15000000 0 0x100000>;
--
2.44.0
On 09/03/2024 14:31, Konrad Dybcio wrote:
> The smmu-v3 binding currently doesn't differentiate the SoCs it's
> implemented on. This is a poor design choice that may bite in the future,
> should any quirks surface.
>
> Add a compatible for the instance found on Qualcomm SC8280XP.
>
> Signed-off-by: Konrad Dybcio <[email protected]>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index 75fcf4cb52d9..f284f7b0c1d8 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -20,7 +20,11 @@ properties:
> $nodename:
> pattern: "^iommu@[0-9a-f]*"
> compatible:
> - const: arm,smmu-v3
> + oneOf:
> + - items:
> + - const: qcom,sc8280xp-smmu-v3
This could be enum, because likely it will grow in the future, but there
is no need to resend for this alone.
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On Sat, Mar 09, 2024 at 02:31:10PM +0100, Konrad Dybcio wrote:
> SC8280XP actually has a third SMMU, which can be seen in e.g. the IORT
> ACPI table and is used for the PCIe hosts.
>
> Unfortunately though, the secure firmware seems to be configured in a
> way such that Linux can't touch it, not even read back the ID registers.
> It also seems like the SMMU is configured to run in some sort of bypass
> mode, completely opaque to the OS.
>
> Describe it so that one can configure it when running Linux as a
> hypervisor (e.g with [1]) and for hardware description completeness.
>
> [1] https://github.com/TravMurav/slbounce
> Signed-off-by: Konrad Dybcio <[email protected]>
Have this information been validated? Or are you suggesting we add it
for documentation purposes?
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index a5b194813079..28edd30a9c04 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -4648,6 +4648,22 @@ cci3_i2c1_sleep: cci3-i2c1-sleep-pins {
> };
> };
>
> + pcie_smmu: iommu@14f80000 {
> + compatible = "qcom,sc8280xp-smmu-v3", "arm,smmu-v3";
> + reg = <0 0x14f80000 0 0x80000>;
> + interrupts = <GIC_SPI 951 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 955 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 953 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "eventq",
> + "gerror",
> + "cmdq-sync";
> + #iommu-cells = <1>;
> + dma-coherent;
> +
> + /* The hypervisor prevents register access from Linux */
> + status = "reserved";
> + };
> +
> apps_smmu: iommu@15000000 {
> compatible = "qcom,sc8280xp-smmu-500", "arm,mmu-500";
> reg = <0 0x15000000 0 0x100000>;
>
> --
> 2.44.0
>
On 18.03.2024 02:31, Bjorn Andersson wrote:
> On Sat, Mar 09, 2024 at 02:31:10PM +0100, Konrad Dybcio wrote:
>> SC8280XP actually has a third SMMU, which can be seen in e.g. the IORT
>> ACPI table and is used for the PCIe hosts.
>>
>> Unfortunately though, the secure firmware seems to be configured in a
>> way such that Linux can't touch it, not even read back the ID registers.
>> It also seems like the SMMU is configured to run in some sort of bypass
>> mode, completely opaque to the OS.
>>
>> Describe it so that one can configure it when running Linux as a
>> hypervisor (e.g with [1]) and for hardware description completeness.
>>
>> [1] https://github.com/TravMurav/slbounce
>> Signed-off-by: Konrad Dybcio <[email protected]>
>
> Have this information been validated? Or are you suggesting we add it
> for documentation purposes?
I confirmed the platforms boots up with this if the hypervisor is gone.
Konrad
On 2024-03-09 1:31 pm, Konrad Dybcio wrote:
> The smmu-v3 binding currently doesn't differentiate the SoCs it's
> implemented on. This is a poor design choice that may bite in the future,
> should any quirks surface.
That doesn't seem entirely fair to say - the vast majority of bindings
don't have separate compatibles for every known integration of the same
implementation in different SoCs. And in this case we don't have
per-implementation compatibles for quirks and errata because the
implementation is architecturally discoverable from the SMMU_IIDR register.
We have the whole mess for QCom SMMUv2 because the effective
*implementation* is a mix of hardware and hypervisor, whose behaviour
does seem to vary on almost a per-SoC basis. I'm not at all keen to
start repeating that here without very good reason, and that of
"documenting" a device which we typically expect to not even be
accessible isn't really convincing me...
Thanks,
Robin.
>
> Add a compatible for the instance found on Qualcomm SC8280XP.
>
> Signed-off-by: Konrad Dybcio <[email protected]>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index 75fcf4cb52d9..f284f7b0c1d8 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -20,7 +20,11 @@ properties:
> $nodename:
> pattern: "^iommu@[0-9a-f]*"
> compatible:
> - const: arm,smmu-v3
> + oneOf:
> + - items:
> + - const: qcom,sc8280xp-smmu-v3
> + - const: arm,smmu-v3
> + - const: arm,smmu-v3
>
> reg:
> maxItems: 1
>
On 19.03.2024 2:53 PM, Robin Murphy wrote:
> On 2024-03-09 1:31 pm, Konrad Dybcio wrote:
>> The smmu-v3 binding currently doesn't differentiate the SoCs it's
>> implemented on. This is a poor design choice that may bite in the future,
>> should any quirks surface.
>
> That doesn't seem entirely fair to say - the vast majority of bindings don't have separate compatibles for every known integration of the same implementation in different SoCs. And in this case we don't have per-implementation compatibles for quirks and errata because the implementation is architecturally discoverable from the SMMU_IIDR register.
>
> We have the whole mess for QCom SMMUv2 because the effective *implementation* is a mix of hardware and hypervisor, whose behaviour does seem to vary on almost a per-SoC basis. I'm not at all keen to start repeating that here without very good reason, and that of "documenting" a device which we typically expect to not even be accessible isn't really convincing me...
From my POV as an arch dts maintainer, this often ends up being the only
way to retroactively add some conditional action into the code - the kernel
is supposed to be backwards compatible with older device trees.
And so far it's been almost by luck that all of the smmuv3 implementations
have been a straight copy-and-paste of the reference design (or close enough),
I don't believe this will be for much longer.
Konrad