Hi Sakari, On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote: > Laurent Pinchart wrote: > > On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote: > >> On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus wrote: > >>> Hi, > >>> > >>> This patchset is aimed to fix a problem in arch_iommu implementation > >>> references. When an actual arch_iommu implementation is not loaded > >>> while iommu_get() is being called results to a kernel oops, as well as > >>> removing an arch_iommu implementation which is in use. > >> > >> How about fixing the dependency instead? Right now iommu2 depends on > >> iommu because of the calls to > >> install_iommu_arch/uninstall_iommu_arch... we should change that > >> dependency to iommu depend on iommu2. Something like iommu (plat) > >> querying iommu2 (mach) for devices to install. > > > > The reason why iommu depends on iommu2 and not the other way around is > > because several mach-specific iommu implementations should be able to > > coexist in the same kernel. The right one should be loaded at runtime. > > > > I think that Sakari's patches correcty fix the problems he noticed. > > However, they won't fix one basic issue, which is that the iommu2 module > > won't be automatically pulled in when the omap3isp module is loaded. The > > omap3isp driver will then fail to probe the device. That's better than > > crashing though. > > One option would be to specify the name of the module in the platform > data and request_module() that in omap_iommu_probe(). This would solve > the issue, not sure how pretty is this though. Do we need that ? My understanding is that a machine will need a single mach- specific iommu implementation only. Drivers shouldn't need to care about that. The iommu implementation should be automatically selected based on the machine time. > In a generic case there would have to be a list of modules implementing > iommu in the platform data. > > > One possible solution for that is to turn the tristate option for iommu2 > > into a bool option. I've also read a couple of times that the kernel > > provides a standard iommu API. Maybe switching to it would help. > > That would solve it as well, but having it as a module would be nice, too. -- Regards, Laurent Pinchart -- 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
