From: ext Felipe Contreras <felipe.contre...@gmail.com> Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration Date: Mon, 18 May 2009 13:48:09 +0200
> On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU <hiroshi.d...@nokia.com> wrote: > > From: ext Felipe Contreras <felipe.contre...@gmail.com> > > Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration > > Date: Sat, 16 May 2009 20:32:10 +0200 > > > >> On Sat, May 16, 2009 at 7:36 PM, Russell King - ARM Linux > >> <li...@arm.linux.org.uk> wrote: > >> > On Sat, May 16, 2009 at 01:05:47PM +0300, Felipe Contreras wrote: > >> >> This patch series cleanups up a bit the opap3-iommu device registration > >> >> and > >> >> then allows registration from other parts of the code. > >> >> > >> >> Currently the iva2 code (tidspbridge) is not using iommu, therefore it > >> >> can't be > >> >> used as-is with the current omap iommu. By allowing devies to be > >> >> registered > >> >> externaly (either isp, or iva2) this problem goes away. > >> > > >> > Hmm, so does this mean that the iommu patchset is going to grow by three > >> > patches? Hope not. > > > > This series has been posted for a long time and I want to get this in > > this time with minor fixes. > > > >> I hope Hiroshi integrates my patches. > > > > I think that the problem of yours is that it's not necesary to allow > > device registration around kernel anywhere by "omap_iommu_add()" at > > all, but enough only in "omap3-iommu.c". Since eventually > > "tidspbridge" will use this iommu framework, no need for this > > flexibility. Keeping same kind of device registration in one place is > > good thing from SoC perspective. So I want to avoid adding unnecessary > > flexibility to the code. I'll follow Russell's call, anyway. > > The first patch has nothing to do with omap_iommu_add, it's just > cleanups, and you haven't provided any valid reason to reject them. Your code doesn't work since the other members of "struct resource" haven't been initilialized like: + memset(res, 0, sizeof(res)); Please refer to: http://marc.info/?l=linux-omap&m=124263966231599&w=2 > The rest of the patches are *necessary* as of right now. IMHO iommu > should not be merged in it's current state because it will break > tidspbridge. Maybe after tidspbridge has been fully converted to use > iommu. > > I think there will probably be a conversion period where the > tidspbridge will use iommu optionally, in that period iommu would need > to be patched and add a #ifdef MPU_BRIDGE_IOMMU, that would be ugly. How about: http://lists.arm.linux.org.uk/lurker/attach/3...@20090518.133533.487a3dd4.attach > > Also you haven't answered my questions: what happens if you disable > MPU_BRIDGE? What's the point of iommu to register the iva2 iommu > device? enough small to ignore. > > My patches solves all of those issues. > > -- > Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
