On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote: > > On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote: > > 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. > > Should that really be controlled by compiling the IOMMU driver out, wouldn't > it be better to disable the IOMMU devices in DT in that case ? It's a policy decision that should only depend on the user. Modifying the DT is wrong here IMHO because the device is still connected to the IOMMU in hardware and we should correctly represent that. You can normally set 'iommu=off' or 'iommu=force' on the command line to force it on or off rather than letting the IOMMU driver decide whether the device turns it on. Not enabling the IOMMU at all should really just behave the same way as 'iommu=off', anything else would be very confusing. Arnd -- 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
 |