[Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Arnd Bergmann]

On Wednesday 17 December 2014 15:53:25 Lucas Stach wrote:
> Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann:
> > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> > > 
> > > If we forbid the IOMMU driver from being compiled as a module can't we just 
> > > rely on deferred probing ? The bus master driver will just be reprobed after 
> > > the IOMMU gets probed, like for other devices.
> > > 
> > > This could fail in case the IOMMU device permanently fails to probe. There 
> > > would be something very wrong in the system in that case, Enabling the bus 
> > > masters totally transparently without IOMMU support could not be such a good 
> > > idea.
> > 
> > I believe in the majority of cases today, the IOMMU is entirely optional.
> > There are valid reasons for not including the IOMMU driver in the kernel,
> > e.g. when you know that all the machines with that driver can DMA to
> > all of their RAM and you want to avoid the overhead of IOTLB misses.
> > 
> This is similar to the problems we discussed with the componentized
> device framework and in the end everybody agreed on a simple rule:
> if the device node is enabled in the DT there must be a driver bound to
> it before other devices depending on this node can be probed.
> 
> If we apply the same logic to the IOMMU situation we get two
> possibilities to allow bypassing the IOMMU:
> 1. completely disable the IOMMU node in the DT
> 2. leave node enabled in DT, but add a bypass property
> 
> Obviously the second option still requires to have the IOMMU driver
> available, but is more flexible. Right now everything depends on the
> IOMMU being in passthrough mode at reset with no driver bound. If a
> device comes around where this isn't the case thing will break with the
> current assumptions or the first option.
> 
> Having the IOMMU node enabled in DT with no driver available to the
> kernel seems like an invalid configuration which should be expected to
> break. Exactly the same thing as with componentized devices...

One differences here is that for the IOMMU, we should generally be able
to fall back to swiotlb (currently only on ARM64, not ARM32, until
someone adds support). I can see your point regarding machines that
have a mandatory IOMMU with no fallback when there is no driver, but
we can support them by making the iommu driver selected through Kconfig
for that platform, while still allowing other platforms to work with
drivers left out of the kernel.

	Arnd