Re: [PATCH] ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Ohad,

On Monday 27 February 2012 09:00:51 Ohad Ben-Cohen wrote:
> On Mon, Feb 27, 2012 at 12:47 AM, Laurent Pinchart wrote:
> > I'm asking about the probe deferral mechanism. The omap3-isp driver will
> > still call iommu_attach_device() in its probe function. What will happen
> > then ? Will it return an error ? On what basis will it do so ?
> 
> Yes, iommu_attach_device() will fail, and omap3isp's probe function will
> then need to return -EAGAIN to request that its probe function will be
> invoked again later on.
> 
> > That's what the comment in the Makefile is for ;-) I don't think it's a
> > perfect solution either, but it avoids playing with the various initcalls.
> > The OMAP3 IOMMU isn't a subsystem, subsys_initcall() looks a bit like an
> > API abuse to me.
> 
> Yes, it's dirty.
> 
> But it's explicit and consistent across build system changes (without
> imposing anything on the build system). We do it all the time with other
> subsystems. We don't like it, but luckily Grant came up with the deferred
> probing mechanism, which will fix this all very nicely.
> 
> > Are drivers supposed to call iommu_attach_device() in their probe()
> > function or later on ?
> 
> If you can defer attaching to a later point, most commonly to a point
> where the device is opened by the user, it's better - less power will
> be consumed.

I'll try that then. How expensive is the iommu_attach_device() (and detach) 
operation in terms of CPU time ?

-- 
Regards,

Laurent Pinchart