Re: [PATCHv3 14/19] iommu/tegra: smmu: Get "nvidia,memory-clients" from DT

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 11/01/2013 10:34 AM, Will Deacon wrote:
> On Fri, Nov 01, 2013 at 04:08:52PM +0000, Stephen Warren wrote:
>> On 10/31/2013 01:39 PM, Will Deacon wrote:
>>> On Thu, Oct 31, 2013 at 07:25:25PM +0000, Stephen Warren wrote:
>>>> On 10/31/2013 01:16 PM, Stephen Warren wrote:
>>>>> Hmm. That's interesting. I see that the ARM SMMU has a list of the
>>>>> clients it affects, whereas this Tegra series puts information into each
>>>>> client device about the SMMU(s) that affect it. Is it better to flip the
>>>>> Tegra binding around to match the style of the ARM SMMU?
>>>>
>>>> One question here: How do you ensure that the SMMU driver probe()s
>>>> before probe() runs for devices affected by the SMMU?
>>>
>>> I think we get away with this by virtue of nobody actually creating IOMMU
>>> mappings from within drivers,
>>
>> Where are the mapping set up? What prevents that action from happening
>> before the IOMMU is set up and the various devices have their DMA ops
>> hooked through the IOMMU? It's fairly clear how deferred probe of client
>> devices could achieve that, but I'm quite unsure how some what other
>> mechanism would ensure that.
> 
> This is the part where I start to struggle. If you look at a mainline
> kernel, arm_iommu_create_mapping isn't really used, so it's difficult to
> know at which point the IOMMU needs to be initialised across different ARM
> SoCs.
> 
> For other architectures, it looks like the IOMMU initialisation hangs
> directly off arch code (which in turn are driven from initcalls), but that's
> generally possible because either the IOMMU is architected, or it's strongly
> tied to PCI initialisation.
> 
> What are the requirements for Tegra? If the IOMMU isn't initialised, does it
> act as a passthrough?

I believe so, yes. In particular we have the following register bits:

1) Register bit AHB_ARBITRATION_XBAR_CTRL_SMMU_INIT_DONE is an overall
SMMU enable flag. This sits outside the SMMU module itself, but the SMMU
probe function requests drivers/amba/tegra-ahb.c:tegra_ahb_enable_smmu()
to go enable it.

2) Each memory client ID has a bit in SMMU_TRANSLATION_ENABLE_* to
enable translation for the client. This is also enabled during the SMMU
probe function.

3) Each swgroup ID has a register indicating which ASID to use for
translation, and an associated enable bit. These are also set up during
SMMU probe at present.

I believe when any of those bits aren't enabled, the SMMU is a
pass-through, considering that I'm pretty sure if I disable the SMMU
driver in the kernel, everything will still work just fine.