Hi Arnd, On Wednesday 17 December 2014 22:58:47 Arnd Bergmann wrote: > On Wednesday 17 December 2014 18:02:51 Laurent Pinchart wrote: > > On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote: > >> 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. > > > > I was thinking about setting status = "disabled" on the IOMMU nodes, not > > removing the IOMMU references in the bus master nodes. > > But that still requires a modification of the DT. The hardware is the > same, so I don't see why we should update the dtb based on kernel > configuration. It wouldn't be the first time we encode configuration information in DT, but I agree it's not an optimal solution. Setting iommu=off on the kernel command line is better, and should be easy to implement. -- Regards, Laurent Pinchart -- 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
 |