Hi,

On Tue, Dec 15, 2020 at 01:09:29AM +0000, Krishna Reddy wrote:

Hi Jean,

quoted

+bool arm_smmu_master_sva_supported(struct arm_smmu_master *master) {
+       if (!(master->smmu->features & ARM_SMMU_FEAT_SVA))
+               return false;

+

quoted

+       /* SSID and IOPF support are mandatory for the moment */
+       return master->ssid_bits && arm_smmu_iopf_supported(master); }
+

Tegra Next Gen SOC has arm-smmu-v3 and It doesn't have support for PRI interface.
However, PCIe client device has capability to handle the page faults on its own when the ATS translation fails.
The PCIe device needs SVA feature enable without PRI interface supported at arm-smmu-v3.
At present, the SVA feature enable is allowed only if the smmu/client device has PRI support. 
There seem to be no functional reason to make pri_supported as a pre-requisite for SVA enable.

The pri_supported check allows drivers to query whether the SMMU is
compatible with their capability. It's pointless, for example, to enable
SVA for a PRI-capable device if the SMMU doesn't support PRI.

I agree that we should let a device driver enable SVA if it supports some
form of IOPF. Perhaps we could extract the IOPF capability from
IOMMU_DEV_FEAT_SVA, into a new IOMMU_DEV_FEAT_IOPF feature. Device drivers
that rely on PRI or stall can first check FEAT_IOPF, then FEAT_SVA, and
enable both separately. Enabling FEAT_SVA would require FEAT_IOPF enabled
if supported. Let me try to write this up.

Thanks,
Jean

Can SVA enable be supported for pri_supported not set case as well? 
Also, It is noticed that SVA  enable on Intel doesn't need pri_supported set. 

-KR