Re: [RFC/PATCH 3/3] omap3-iommu: remote registration

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

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@arm.linux.org.uk> 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@arm.linux.org.uk> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html