Re: [PATCH v8 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
From: Tomasz Figa <tfiga@chromium.org>
Date: 2018-02-13 08:57:39
Also in:
dri-devel, linux-arm-msm, linux-iommu, linux-pm, lkml
Hi Vivek, Thanks for the patch. Please see my comments inline. On Fri, Feb 9, 2018 at 7:57 PM, Vivek Gautam [off-list ref] wrote:
quoted hunk ↗ jump to hunk
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. This smmu core is used with multiple masters on msm8996, viz. mdss, video, etc. Add bindings for the same. Signed-off-by: Vivek Gautam <redacted> Reviewed-by: Rob Herring <robh@kernel.org> --- Changes in v8: - Added the missing IOMMU_OF_DECLARE declaration for "qcom,smmu-v2" .../devicetree/bindings/iommu/arm,smmu.txt | 43 ++++++++++++++++++++++ drivers/iommu/arm-smmu.c | 14 +++++++ 2 files changed, 57 insertions(+)diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt index 8a6ffce12af5..169222ae2706 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt@@ -17,10 +17,19 @@ conditions. "arm,mmu-401" "arm,mmu-500" "cavium,smmu-v2" + "qcom,<soc>-smmu-v2", "qcom,smmu-v2" depending on the particular implementation and/or the version of the architecture implemented. + A number of Qcom SoCs use qcom,smmu-v2 version of the IP. + "qcom,<soc>-smmu-v2" represents a soc specific compatible + string that should be present along with the "qcom,smmu-v2" + to facilitate SoC specific clocks/power connections and to + address specific bug fixes. + An example string would be - + "qcom,msm8996-smmu-v2", "qcom,smmu-v2".
Hmm, I remember that for <soc> and similar wildcards we required explicitly listing allowed values. Rob, has it changed since I stumbled upon such thing last time (or I just got it wrong before)?
quoted hunk ↗ jump to hunk
+ - reg : Base address and size of the SMMU. - #global-interrupts : The number of global interrupts exposed by the@@ -71,6 +80,23 @@ conditions. or using stream matching with #iommu-cells = <2>, and may be ignored if present in such cases. +- clock-names: Should be "bus", and "iface" for "qcom,smmu-v2" + implementation. + + "bus" clock for "qcom,smmu-v2" is required for downstream + bus access and for the smmu ptw. + + "iface" clock is required to access smmu's registers through + the TCU's programming interface.
nit: Could we have it in a bit more structured way? E.g. - clock-names: List of names of clocks input to the device. The required list depends on particular implementation and is as follows: - for "qcom,smmu-v2": - "bus": clock required for downstream bus access and for the smmu ptw, - "iface": clock required to access smmu's registers through the TCU's programming interface. - unspecified for other implementations. (+/- wrapping)
+ +- clocks: Phandles for respective clocks described by clock-names.
Phandle is just a pointer to another node. Clocks are however specified using a phandle and a number of arguments, depending on the clock controller. I'd change it to: - clocks: Specifiers for all clocks listed in the clock-names property, as per generic clock bindings.
+ +- power-domains: Phandles to SMMU's power domain specifier. This is + required even if SMMU belongs to the master's power + domain, as the SMMU will have to be enabled and + accessed before master gets enabled and linked to its + SMMU.
From DT point of view, the relationship of SMMU belonging to a master
device doesn't exist. The power-domains property needs to be properly specified for all devices within power domains represented in DT, with an exception of the case when the parent-child relationship is explicitly stated in DT by child devices being represented by child nodes of the parent device node. - power-domains: Specifiers for power domains required to be powered on for the SMMU to operate, as per generic power domain bindings. Best regards, Tomasz