From mboxrd@z Thu Jan 1 00:00:00 1970 From: laurent.pinchart@ideasonboard.com (Laurent Pinchart) Date: Thu, 01 Mar 2012 17:37:40 +0100 Subject: [PATCH] ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp In-Reply-To: References: <1330251254-14693-1-git-send-email-ohad@wizery.com> <35010303.ArkW8BdIu6@avalon> Message-ID: <6354375.6C9sXAHKbF@avalon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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