linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thor Thayer <thor.thayer@linux.intel.com>
To: Robin Murphy <robin.murphy@arm.com>,
	joro@8bytes.org, robh+dt@kernel.org, mark.rutland@arm.com,
	dinguyen@kernel.org, will.deacon@arm.com,
	sricharan@codeaurora.org
Cc: iommu@lists.linux-foundation.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64: dts: stratix10: Add Stratix10 SMMU support
Date: Thu, 16 Aug 2018 22:33:31 -0500	[thread overview]
Message-ID: <cfe958b8-2711-4dbf-5f32-d777166c305a@linux.intel.com> (raw)
In-Reply-To: <db4d8290-c015-aa8b-6058-11fd3d25464b@arm.com>

Hi Robin,

On 08/08/2018 12:38 PM, Robin Murphy wrote:
> On 25/07/18 19:24, thor.thayer@linux.intel.com wrote:
>> From: Thor Thayer <thor.thayer@linux.intel.com>
>>
>> Add SMMU support to the Stratix10 Device Tree which
>> includes adding the SMMU node and adding IOMMU stream
>> ids to the SMMU peripherals. Update bindings.
>>
>> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
>> ---
>> This patch is dependent on the patch series
>> "iommu/arm-smmu: Add runtime pm/sleep support"
>> (https://patchwork.ozlabs.org/cover/946160/)
>> ---
>>   .../devicetree/bindings/iommu/arm,smmu.txt         | 25 
>> ++++++++++++++++++
>>   arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  | 30 
>> ++++++++++++++++++++++
>>   2 files changed, 55 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
>> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index 7c71a6ed465a..8e3fe0594e3e 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -18,6 +18,7 @@ conditions.
>>                           "arm,mmu-500"
>>                           "cavium,smmu-v2"
>>                           "qcom,<soc>-smmu-v2", "qcom,smmu-v2"
>> +                        "altr,smmu-v2"
> 
> Can we guarantee that no Altera SoC will ever exist with a different 
> SMMU implementation, configuration, or clock tree? If we must have 
> compatibles for SoC-specific integrations, I'd be a lot happier if they 
> were actually SoC-specific, i.e. at least "altr,stratix10-smmu", or even 
> something like "altr,gx5500-smmu" if there's a chance of new 
> incompatible designs being added to the Stratix 10 family in future.
> 

Good point. I'll get a better compatible string if I pursue this.

> I'm still dubious that we actually need this for MMU-500, though, since 
> we will always need the TCU clock enabled to do anything, and given the 
> difficulty in associating particular TBU clocks with whichever domains 
> might cause allocations into which TBU's TLBs, it seems highly unlikely 
> that it'll ever be feasible to work at a granularity finer than "all of 
> the clocks". And at that point the names don't really matter, and we 
> merely need something like the proposed of_clk_bulk_get()[1], which 
> works fine regardless of how many TBUs and distinct clocks exist for a 
> particular MMU-500 configuration and integration.
> 

Yes, I would prefer to use the standard arm,mmu-500 but with the changes 
proposed by [2] that this patch was dependent on, it seemed I would need 
to make a new structure and type.

I like the patch series for devm_clk_bulk_get_all() that includes 
of_clk_bulk_get(). That would enable my patch to work with minor changes 
to add bulk_clk to arm-smmu.c. However, the patchset doesn't seem to 
have been accepted yet.

>>                     depending on the particular implementation and/or the
>>                     version of the architecture implemented.
>> @@ -179,3 +180,27 @@ conditions.
>>                <&mmcc SMMU_MDP_AHB_CLK>;
>>           clock-names = "bus", "iface";
>>       };
>> +
>> +    /* Stratix10 arm,smmu-v2 implementation */
>> +    smmu5: iommu@fa000000 {
>> +        compatible = "altr,smmu-v2", "arm,mmu-500",
>> +                 "arm,smmu-v2";
>> +        reg = <0xfa000000 0x40000>;
>> +        #global-interrupts = <2>;
>> +        #iommu-cells = <1>;
>> +        clocks = <&clkmgr STRATIX10_L4_MAIN_CLK>;
>> +        clock-names = "masters";
> 
> This isn't documented as an actual property, and if it also clocks the 
> TCU then I'm not sure it's really the most accurate name.
> 
> Robin.
> 
> [1] https://patchwork.kernel.org/patch/10427095/

In the patch I'll remove the clock-names.

I'll keep track of the status of this patch (and [3] from the same 
patchset). I tested a simple patch that uses devm_clk_bulk_get_all() 
from these bulk_clk patches and it works well with the standard 
"arm,mmu-500" compatible.

This patch has dependencies on [2]. It seems like [2] could use the 
bulk_clk patches in [1] above (in particular [2]'s patch 1/4).  The 
function arm_smmu_fill_clk_data() wouldn't be needed because everything 
happens in devm_clk_bulk_get_all(). However, those bulk_clk patches have 
been hanging out there since May.

I'm unclear on how to proceed. Do I continue with dependency on [2] or 
create a new patch adding the bulk clocks changes in [1] (and [3])?

Thanks for reviewing!

Thor

[2] https://patchwork.kernel.org/patch/10546677/
[3] https://patchwork.kernel.org/patch/10427079/
> 
>> +        interrupt-parent = <&intc>;
>> +        interrupts = <0 128 4>,    /* Global Secure Fault */
>> +            <0 129 4>, /* Global Non-secure Fault */
>> +            /* Non-secure Context Interrupts (32) */
>> +            <0 138 4>, <0 139 4>, <0 140 4>, <0 141 4>,
>> +            <0 142 4>, <0 143 4>, <0 144 4>, <0 145 4>,
>> +            <0 146 4>, <0 147 4>, <0 148 4>, <0 149 4>,
>> +            <0 150 4>, <0 151 4>, <0 152 4>, <0 153 4>,
>> +            <0 154 4>, <0 155 4>, <0 156 4>, <0 157 4>,
>> +            <0 158 4>, <0 159 4>, <0 160 4>, <0 161 4>,
>> +            <0 162 4>, <0 163 4>, <0 164 4>, <0 165 4>,
>> +            <0 166 4>, <0 167 4>, <0 168 4>, <0 169 4>;
>> +        stream-match-mask = <0x7ff0>;
>> +    };
>> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
>> b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>> index d033da401c26..e38ca86d48f6 100644
>> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>> @@ -137,6 +137,7 @@
>>               reset-names = "stmmaceth", "stmmaceth-ocp";
>>               clocks = <&clkmgr STRATIX10_EMAC0_CLK>;
>>               clock-names = "stmmaceth";
>> +            iommus = <&smmu 1>;
>>               status = "disabled";
>>           };
>> @@ -150,6 +151,7 @@
>>               reset-names = "stmmaceth", "stmmaceth-ocp";
>>               clocks = <&clkmgr STRATIX10_EMAC1_CLK>;
>>               clock-names = "stmmaceth";
>> +            iommus = <&smmu 2>;
>>               status = "disabled";
>>           };
>> @@ -163,6 +165,7 @@
>>               reset-names = "stmmaceth", "stmmaceth-ocp";
>>               clocks = <&clkmgr STRATIX10_EMAC2_CLK>;
>>               clock-names = "stmmaceth";
>> +            iommus = <&smmu 3>;
>>               status = "disabled";
>>           };
>> @@ -273,6 +276,7 @@
>>               clocks = <&clkmgr STRATIX10_L4_MP_CLK>,
>>                    <&clkmgr STRATIX10_SDMMC_CLK>;
>>               clock-names = "biu", "ciu";
>> +            iommus = <&smmu 5>;
>>               status = "disabled";
>>           };
>> @@ -307,6 +311,30 @@
>>               altr,modrst-offset = <0x20>;
>>           };
>> +        smmu: iommu@fa000000 {
>> +            compatible = "altr,smmu-v2", "arm,mmu-500",
>> +                     "arm,smmu-v2";
>> +            reg = <0xfa000000 0x40000>;
>> +            #global-interrupts = <2>;
>> +            #iommu-cells = <1>;
>> +            clocks = <&clkmgr STRATIX10_L4_MAIN_CLK>;
>> +            clock-names = "masters";
>> +            interrupt-parent = <&intc>;
>> +            interrupts = <0 128 4>,    /* Global Secure Fault */
>> +                <0 129 4>, /* Global Non-secure Fault */
>> +                /* Non-secure Context Interrupts (32) */
>> +                <0 138 4>, <0 139 4>, <0 140 4>, <0 141 4>,
>> +                <0 142 4>, <0 143 4>, <0 144 4>, <0 145 4>,
>> +                <0 146 4>, <0 147 4>, <0 148 4>, <0 149 4>,
>> +                <0 150 4>, <0 151 4>, <0 152 4>, <0 153 4>,
>> +                <0 154 4>, <0 155 4>, <0 156 4>, <0 157 4>,
>> +                <0 158 4>, <0 159 4>, <0 160 4>, <0 161 4>,
>> +                <0 162 4>, <0 163 4>, <0 164 4>, <0 165 4>,
>> +                <0 166 4>, <0 167 4>, <0 168 4>, <0 169 4>;
>> +            stream-match-mask = <0x7ff0>;
>> +            status = "disabled";
>> +        };
>> +
>>           spi0: spi@ffda4000 {
>>               compatible = "snps,dw-apb-ssi";
>>               #address-cells = <1>;
>> @@ -416,6 +444,7 @@
>>               resets = <&rst USB0_RESET>, <&rst USB0_OCP_RESET>;
>>               reset-names = "dwc2", "dwc2-ecc";
>>               clocks = <&clkmgr STRATIX10_USB_CLK>;
>> +            iommus = <&smmu 6>;
>>               status = "disabled";
>>           };
>> @@ -428,6 +457,7 @@
>>               resets = <&rst USB1_RESET>, <&rst USB1_OCP_RESET>;
>>               reset-names = "dwc2", "dwc2-ecc";
>>               clocks = <&clkmgr STRATIX10_USB_CLK>;
>> +            iommus = <&smmu 7>;
>>               status = "disabled";
>>           };
>>
> 


  reply	other threads:[~2018-08-17  3:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25 18:24 [PATCH 0/2] iommu/arm-smmu: Add Stratix10 SMMU Support thor.thayer
2018-07-25 18:24 ` [PATCH 1/2] arm64: dts: stratix10: Add Stratix10 SMMU support thor.thayer
2018-08-07 18:00   ` Rob Herring
2018-08-08 17:38   ` Robin Murphy
2018-08-17  3:33     ` Thor Thayer [this message]
2018-07-25 18:24 ` [PATCH 2/2] iommu/arm-smmu: Add support for Stratix10 smmu-v2 variant thor.thayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cfe958b8-2711-4dbf-5f32-d777166c305a@linux.intel.com \
    --to=thor.thayer@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dinguyen@kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sricharan@codeaurora.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).