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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU <Hiroshi.DOYU@xxxxxxxxx> wrote:
> From: ext Felipe Contreras <felipe.contreras@xxxxxxxxx>
> 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
>> <linux@xxxxxxxxxxxxxxxx> 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.

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.

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?

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux