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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
