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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> so the ordering is already handled. However, I
> also have a patch queued to move the SMMU initialisation to a
> subsys_initcall. I'm not particularly fond of that, but it seems to be the
> done thing (even for other architectures).

We've been trying very hard not to rely on initcall ordering to solve
issues like this, simply it doesn't scale to complex use-cases, and
different HW/drivers/... might have conflicting requirements that aren't
possible to solve by tweaking initcall levels. It seems much more
preferable to use something that's guaranteed to work and adapt to any
situation, such as deferred probe.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux