arm: msm: Add System MMU support.
in [Kernel]
|
Prev: [PATCH 3/4] Checkpatch: prefer usleep_range over usleep
Next: [PATCH 0/4 -tip] delay documentation and checkpatch additions
From: Roedel, Joerg on 2 Aug 2010 04:10 On Mon, Aug 02, 2010 at 04:03:02AM -0400, Benjamin Herrenschmidt wrote: > On Mon, 2010-08-02 at 09:48 +0200, Roedel, Joerg wrote: > > > Hrm, indeed I just noticed that. Pretty gross... it should definitly > > be > > > renamed, is will caused endless confusion with unrelated iommu.h and > > > iommu_* interfaces which represent something different. > > > > The first direction to go should be trying to unify all the different > > iommu* interfaces into the iommu-api. The generic api will definitly > > need to be extended for that, but since it is an in-kernel interface > > thats no problem. > > Well, I suppose I'm the de-facto candidate to take care of the powerpc > side then :-) > > I don't have the bandwidth right now, but I'll try to have a look when > time permits. Great :-) -- Joerg Roedel - AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roedel, Joerg on 2 Aug 2010 04:40 On Mon, Aug 02, 2010 at 04:03:02AM -0400, Benjamin Herrenschmidt wrote: > On Mon, 2010-08-02 at 09:48 +0200, Roedel, Joerg wrote: > > > Hrm, indeed I just noticed that. Pretty gross... it should definitly > > be > > > renamed, is will caused endless confusion with unrelated iommu.h and > > > iommu_* interfaces which represent something different. > > > > The first direction to go should be trying to unify all the different > > iommu* interfaces into the iommu-api. The generic api will definitly > > need to be extended for that, but since it is an in-kernel interface > > thats no problem. > > Well, I suppose I'm the de-facto candidate to take care of the powerpc > side then :-) > > I don't have the bandwidth right now, but I'll try to have a look when > time permits. Btw. I have some ideas to extend the IOMMU-API to also support GART-like IOMMUs. These pieces could also support (limited-size) domains (without isolation) using segmentation. Not sure if this makes sense for the use-cases in other architectures but we should not declare this impossible for now. -- Joerg Roedel - AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 2 Aug 2010 04:40 On Mon, 02 Aug 2010 18:03:02 +1000 Benjamin Herrenschmidt <benh(a)kernel.crashing.org> wrote: > On Mon, 2010-08-02 at 09:48 +0200, Roedel, Joerg wrote: > > > Hrm, indeed I just noticed that. Pretty gross... it should definitly > > be > > > renamed, is will caused endless confusion with unrelated iommu.h and > > > iommu_* interfaces which represent something different. > > > > The first direction to go should be trying to unify all the different > > iommu* interfaces into the iommu-api. The generic api will definitly > > need to be extended for that, but since it is an in-kernel interface > > thats no problem. > > Well, I suppose I'm the de-facto candidate to take care of the powerpc > side then :-) We already agreed that what the iommu-api looks like? ARM's iommu code (arch/plat-omap/include/plat/iommu.h) is a library to simplify the IOMMU implementations. It could be useful for all the iommu implementations. The current iommu-api (include/linux/iommu.h) provides the common interface for specific purposes (for KVM). I think that the current iommu-api can be a part of the former. I also think that the IOMMU part of this new msm should be integrated into the former. Another question is how the above can work with the DMA-API. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 2 Aug 2010 05:10 On Mon, Aug 02, 2010 at 05:30:26PM +0900, FUJITA Tomonori wrote: > ARM's iommu code (arch/plat-omap/include/plat/iommu.h) is a library to > simplify the IOMMU implementations. It could be useful for all the > iommu implementations. ITYM OMAP's iommu code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 2 Aug 2010 05:30
On Mon, 2 Aug 2010 10:03:26 +0100 Russell King - ARM Linux <linux(a)arm.linux.org.uk> wrote: > On Mon, Aug 02, 2010 at 05:30:26PM +0900, FUJITA Tomonori wrote: > > ARM's iommu code (arch/plat-omap/include/plat/iommu.h) is a library to > > simplify the IOMMU implementations. It could be useful for all the > > iommu implementations. > > ITYM OMAP's iommu code. Yeah, I meant that we could extend it to make it useful for other iommu implementations. At least, we could make something generic like struct iommu_functions, I think. Then we can embed a generic iommu structure into an iommu specific struct (like we do with inode). The current iommu-api (include/linux/iommu.h) is just about domain and mapping concept. We can implement it on the top of the above infrastructure. I'm still trying to figure out how the DMA-API can work well with them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |