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

Laurent Pinchart
2014-12-17T22:38:48Z

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