On Mon, May 18, 2009 at 4:40 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Mon, May 18, 2009 at 04:21:19PM +0300, Felipe Contreras wrote: >> On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux >> <linux@xxxxxxxxxxxxxxxx> wrote: >> > 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. >> >> Yeap, that needs to be done too. >> >> > As for the run-time size, that's truely minimal. >> >> I thought creating iommu devices involved some kind of overhead, >> allocating some resources probably. That's why the iva2 iommu device >> conflicts with tidspbridge custom mmu. > > I believe I've already said how to handle that - in fact it's in the > quoted messages at the top of this mail. > >> >> 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. >> >> Ok, yes, for iommu, but not for omap3-iommu which is a separate module. > > That is a point, but I think it's a relatively minor one. We could > get around that by ensuring that omap3-iommu is always built-in if > we have the possibility of iommu support, and leave iommu as a module. You mean omap3-iommu will be built-in in the iommu module? That looks ok to me, *if* it's true that iommu devices don't waste any significant resources if nobody is using them. -- Felipe Contreras -- 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
