> -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] > Sent: Monday, October 11, 2010 8:00 AM > To: Hiroshi DOYU > Cc: linux-omap@xxxxxxxxxxxxxxx; greg@xxxxxxxxx; > felipe.contreras@xxxxxxxxx; Guzman Lugo, Fernando; Marathe, > Yogesh; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] omap: iommu: make iva2 iommu selectable > > On Mon, Oct 11, 2010 at 3:28 PM, Hiroshi DOYU > <Hiroshi.DOYU@xxxxxxxxx> wrote: > > From: ext Felipe Contreras <felipe.contreras@xxxxxxxxx> > > Subject: [PATCH 1/2] omap: iommu: make iva2 iommu selectable > > Date: Mon, 11 Oct 2010 11:53:49 +0200 > > > >> From: Felipe Contreras <felipe.contreras@xxxxxxxxx> > >> > >> It seems dsp-link will do this, and tidspbridge too at some point, > >> but right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU. > > > > Why does it have to be selectable? > > You mean why is it desirable to turn it off? Right now > there's a mess of tidspbridge branches, some work, some > don't, some have migrated to iommu, some don't. In mainline > all this, plus the status on dsp-link, should be irrelevant, > a configuration solves all the issues. > > Once the iommu migration works (haven't managed to get it > working myself), and it has been merged into mainline, then > we can think about enabling it unconditionally. In the > meantime, enabling unconditionally would break the > tidspbridge that is in staging (mainline). What is the problem enabling unconditionally? The iva2 iommu does not start working until you call iommu_get. So if for some reason you are using the dspbridge with custom Iommu implementation it should not cause any collision with Iommu module. Regards, Fernando. > > > Please Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx too. > > Will do, after you reply the above. > > -- > 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