Hi Laurent, On Sun, Feb 26, 2012 at 7:34 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Sunday 26 February 2012 12:14:14 Ohad Ben-Cohen wrote: >> omap3isp depends on omap's iommu and will fail to probe if >> initialized before it (which always happen if they are builtin). >> >> Make omap's iommu subsys_initcall as an interim solution until >> the probe deferral mechanism is merged. > > How will that fix the problem ? Sorry, I'm not entirely sure I understand the question: are you asking about this patch or about the probe deferral thingy ? > I'm fine with this patch, as it fixes the problem as well, although I still > believe modifying the link order would be a better fix in this case. I'm personally not a huge fan of implicit link order dependencies, as someone may change the order in the future (for whatever benign reason) without even realizing he's breaking drivers. >> +/* must be ready before omap3isp is probed */ > > The problem is not limited to the omap3isp driver, the DSP driver could be > affected as well. If you refer to tidspbridge, then I'm not sure it has the same issue: IIUC it doesn't enable the iommu hw on probe; only in response to an ioctl command (btw, tidspbridge doesn't even use this omap iommu driver - it manipulates the iommu registers directly. iicks.) The omap4 solutions (remoteproc et al.) will only enable the iommu after userspace is alive, so no risk there as well. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
