RE: [PATCH 5/9] iommu: add qcom_iommu

["sricharan" <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]

Hi,

>On Tue, Mar 7, 2017 at 12:48 PM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>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