On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: > On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > The real problem here seems to be the TI DSP bridge code, and if that's > > the case why can't we just avoid registering IVA2 if the TI DSP bridge > > code is enabled. That solves your stated problem without creating > > additional management issues. > > The bridgedriver is expected to move and use iommu eventually, but not > right now, so I guess the iva2 device should be registered only if > MPU_BRIDGE_IOMMU is defined. > > But then what's the point of having the isp iommu device if the camera > driver is disabled? Wouldn't that be wasting resources? Then if CAMERA > is not defined the isp device should not be registered either. So have something like: config OMAP_IOMMU tristate and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever else) select it. That way, you only end up with the IOMMU support code built into the kernel if you have users of it. These low-level internal services drivers really don't need to be publically visible in the configuration system. As for the run-time size, that's truely minimal. > And finally if none of the two are enabled then you don't really > iommu. By having omap_iommu_add all the dependencies would be handled > automatically, right? 'modprobe bridgedriver' would load iommu. Think about it - the dependencies _already_ have to be there to use the iommu services. -- 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
