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

Ohad Ben-Cohen ohad at wizery.com
Mon Feb 27 02:00:51 EST 2012


Hi Laurent,

On Mon, Feb 27, 2012 at 12:47 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> 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.

Thanks,
Ohad.



More information about the linux-arm-kernel mailing list