On 2020-07-01 19:18, Krishna Reddy wrote:
+ * 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.

Yeah, I realised later last night that this probably originated from forking the whole driver downstream. But even then you could have treated the other one as a separate nsmmu with a single instance ;)

Since it does add a bit of confusion to the code and comments, let's just keep things simple. I do like Jon's suggestion of actually enforcing that the number of "reg" regions exactly matches the number expected for the given compatible - I guess for now that means just hard-coding 2 and hoping the hardware folks don't cook up any more of these...

iommu mailing list

Reply via email to