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... Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |