From: Krishna Reddy <vdumpa@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>,
Jonathan Hunter <jonathanh@nvidia.com>
Cc: Timo Alho <talho@nvidia.com>, Thierry Reding <treding@nvidia.com>,
Bryan Huntsman <bhuntsman@nvidia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Mikko Perttunen <mperttunen@nvidia.com>,
"nicoleotsuka@gmail.com" <nicoleotsuka@gmail.com>,
Sachin Nikam <Snikam@nvidia.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Yu-Huan Hsu <YHsu@nvidia.com>,
Pritesh Raithatha <praithatha@nvidia.com>,
"will@kernel.org" <will@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Bitan Biswas <bbiswas@nvidia.com>
Subject: RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
Date: Wed, 1 Jul 2020 18:18:22 +0000 [thread overview]
Message-ID: <BYAPR12MB2822FC263456303302EF30BEB36C0@BYAPR12MB2822.namprd12.prod.outlook.com> (raw)
In-Reply-To: <d59b7220-168c-419f-db16-194307e11065@arm.com>
>> + * When Linux kernel supports multiple SMMU devices, the SMMU device
>> +used for
>> + * isochornous HW devices should be added as a separate ARM MMU-500
>> +device
>> + * in DT and be programmed independently for efficient TLB invalidates.
>I don't understand the "When" there - the driver has always supported multiple independent SMMUs, and it's not something that could be configured out or otherwise disabled. Plus I really don't see why you would ever want to force unrelated SMMUs to be >programmed together - beyond the TLB thing mentioned it would also waste precious context bank resources and might lead to weird device grouping via false stream ID aliasing, with no obvious upside at all.
Sorry, I missed this comment.
During the initial patches, when the iommu_ops were different between, support multiple SMMU drivers at the same is not possible as one of them(that gets probed last) overwrites the platform bus ops.
On revisiting the original issue, This problem is no longer relevant. At this point, It makes more sense to just get rid of 3rd instance programming in arm-smmu-nvidia.c and just limit it to the SMMU instances that need identical programming.
-KR
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-07-01 18:18 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 0:10 [PATCH v8 0/3] Nvidia Arm SMMUv2 Implementation Krishna Reddy
2020-06-30 0:10 ` [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage Krishna Reddy
2020-06-30 0:16 ` Nicolin Chen
2020-06-30 5:54 ` Pritesh Raithatha
2020-06-30 8:19 ` Jon Hunter
2020-06-30 14:53 ` Robin Murphy
2020-06-30 15:17 ` Jon Hunter
2020-07-01 18:18 ` Krishna Reddy [this message]
2020-07-01 18:56 ` Robin Murphy
2020-07-01 19:12 ` Krishna Reddy
2020-06-30 17:04 ` Krishna Reddy
2020-06-30 10:17 ` Jon Hunter
2020-06-30 16:23 ` Krishna Reddy
2020-06-30 16:32 ` Jon Hunter
2020-06-30 16:44 ` Jon Hunter
2020-06-30 17:16 ` Krishna Reddy
2020-06-30 19:03 ` Jon Hunter
2020-06-30 20:21 ` Krishna Reddy
2020-06-30 0:10 ` [PATCH v8 2/3] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU Krishna Reddy
2020-06-30 6:01 ` Pritesh Raithatha
2020-06-30 8:21 ` Jon Hunter
2020-06-30 12:27 ` Robin Murphy
2020-07-01 18:28 ` Krishna Reddy
2020-07-01 18:47 ` Jon Hunter
2020-07-01 19:00 ` Krishna Reddy
2020-07-01 19:31 ` Jon Hunter
2020-07-01 19:39 ` Krishna Reddy
2020-07-02 16:05 ` Robin Murphy
2020-07-01 19:03 ` Robin Murphy
2020-06-30 0:10 ` [PATCH v8 3/3] iommu/arm-smmu: Add global/context fault implementation hooks Krishna Reddy
2020-06-30 0:19 ` Nicolin Chen
2020-06-30 5:58 ` Pritesh Raithatha
2020-06-30 8:37 ` Jon Hunter
2020-06-30 12:13 ` Robin Murphy
2020-06-30 12:42 ` Jon Hunter
2020-07-01 18:48 ` Krishna Reddy
2020-07-01 19:14 ` Robin Murphy
2020-07-01 19:22 ` Krishna Reddy
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=BYAPR12MB2822FC263456303302EF30BEB36C0@BYAPR12MB2822.namprd12.prod.outlook.com \
--to=vdumpa@nvidia.com \
--cc=Snikam@nvidia.com \
--cc=YHsu@nvidia.com \
--cc=bbiswas@nvidia.com \
--cc=bhuntsman@nvidia.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mperttunen@nvidia.com \
--cc=nicoleotsuka@gmail.com \
--cc=nicolinc@nvidia.com \
--cc=praithatha@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=talho@nvidia.com \
--cc=treding@nvidia.com \
--cc=will@kernel.org \
/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).