On 10/31/2013 10:46 AM, Hiroshi Doyu wrote:

Stephen Warren [off-list ref] wrote @ Thu, 31 Oct 2013 17:35:24 +0100:

...

quoted

quoted

quoted

... and for the driver to explicitly parse that property, and wait
until the driver for iommu_phandle is ready. Exactly the same as any
other resource/service dependency.

That will solve all the problems.

The only downside is that every driver needs to contain code to parse
that property. However, I think that's just one function call; the
actual implementation of that function can be unified somewhere inside
core code in drivers/iommu/.

Yes, but only missing part now is that, we could do this with
"bus_notifier", but the current bus_notifier doesn't have the feature
to return error(-EPROBE_DEFER). This could be modified so that
bus_notifier could return (-EPROBE_DEFER) to postpone
probing. Alternatively this could be done in some core probe code as
well as Thierry pointed out.

[1] In the reply of "[PATCHv3 14/19] iommu/tegra: smmu: Get "nvidia,memory-clients" from DT"

I think this should be done explicitly in drivers. It's much
simpler,

Yes, we need to insert some IOMMU specific code in driver?

quoted

and doesn't encode any knowledge of driver-specific bindings into some
common bus notifier code.

I think that we cannot do that in drivers. We want to use drivers as
they are without any modifications indicating its dependency on
IOMMU because most of drivers are existing ones which nvidia doesn't
implement. We want to set up any IOMMU related thingy implicitly,
hided from driver. That's why we need to do this in bus_notifier or
driver core code.

We're talking about memory-mapped on-SoC devices here, that generally
only exist inside Tegra SoCs.

Even ignoring that (i.e. expanding the argument to arbitrary modules),
having drivers that perform bus-master transactions call a function
of_iommu_attach() or similar, which does nothing if the device isn't
behind an IOMMU but otherwise does whatever is required, seems like it
isn't much of an imposition.

If this turns out to be something that lots of devices benefit from, we
could do the same thing that pinctrl does for "hogs", and make the
function call in the driver core. But note that's still part of the
probing flow (just implemented in the driver core) rather than bus
notifier based, hence keeps the same simplicity.