Hi, >On Tue, Mar 7, 2017 at 12:48 PM, Robin Murphy <robin.murphy@xxxxxxx> >wrote: >> On 01/03/17 17:42, Rob Clark wrote: >>> An iommu driver for Qualcomm "B" family devices which do not >>> completely implement the ARM SMMU spec. >> >> Is that actually true, or is it just that it's a compliant SMMU on >> which firmware has set SCR1.GASRAE? (which makes the global address >> space secure-access-only). I don't know which Qualcomm SoCs are the >> ones apparently using a plain ARM MMU-500 IP, but if any of those are >> also running this particular firmware configuration that puts us in a >> somewhat weird situation with respect to drivers :/ >> > >I can't say for sure, I don't really know exactly what tz is doing. >Although the net effect from linux kernel perspective is that it isn't really >"compliant". And I think the SMMU_INTR_SEL_NS part (for controlling routing >of cb irqs) is non-standard. > >As far as I can tell, if there was firmware that allowed access to the global >address space, I don't think it ever escaped outside of qcom's labs (ie. might >have existed on early versions of chips for new SoC bring-up.. but I think from >upstream perspective we can ignore that). Right, I would think this is the only one which has the MMU-500 behind the *secure* access constraints to global registers. The next set of Socs which were integrating the MMU-500 had this addressed in different ways, means its going to work with the upstream arm-smmu driver itself. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
