Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 06, 2011 at 04:09:33PM -0400, Ohad Ben-Cohen wrote: On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg joerg.roe...@amd.com wrote: Well, it certainly makes sense to have a single implementation for this. But I want to hide this complexity to the user of the IOMMU-API. The best choice is to put this into the layer between the IOMMU-API and the backend implementation. I agree. The IOMMU API should take physically contiguous regions from the user, split them up according to page-sizes (/alignment requirements) supported by the hardware, and then tell the underlying implementation what to map where. Yup. Btw, is there any IOMMU hardware which supports non-natural alignment? In this case we need to expose these requirements somehow. Regards, Joerg -- 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg joerg.roe...@amd.com wrote: Yup. Btw, is there any IOMMU hardware which supports non-natural alignment? In this case we need to expose these requirements somehow. Not sure there are. Let's start with natural alignment, and extend it only if someone with additional requirements shows up. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Tue, Jun 07, 2011 at 05:22:11AM -0400, Ohad Ben-Cohen wrote: On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg joerg.roe...@amd.com wrote: Yup. Btw, is there any IOMMU hardware which supports non-natural alignment? In this case we need to expose these requirements somehow. Not sure there are. Let's start with natural alignment, and extend it only if someone with additional requirements shows up. Btw, mind to split out your changes which move the iommu-api into drivers/iommu? I can merge them meanwhile into my iommu tree and start working on a proposal for the generic large page-size support. Joerg -- 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg joerg.roe...@amd.com wrote: Btw, mind to split out your changes which move the iommu-api into drivers/iommu? I can merge them meanwhile into my iommu tree and start working on a proposal for the generic large page-size support. Sure, that will be great. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Sunday 05 June 2011, Ohad Ben-Cohen wrote: As far as I can tell, once we have that in place, we you can migrate omap3isp from iovmm to dma-mapping and remove iovmm. Sounds like a plan. I'd still prefer us to take small steps here, and not gate the omap iommu cleanups with Marek's generic dma_map_ops work though. Let's go forward and migrate omap's iommu to the generic iommu API, so new code will be able to use it (e.g. the long coming virtio-based IPC/AMP framework). Yes, of course. That's what I meant. Moving over omap to the IOMMU API is required anyway, so there is no point delaying that. We'll migrate iovmm/omap3isp just enough so they don't break, but once the generic dma_map_ops work materializes, we'd be able to complete the migration, remove iovmm, and decouple omap3isp from omap-specific iommu APIs for good. Ok, great! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi, On Thu, Jun 02, 2011 at 06:27:37PM -0400, Ohad Ben-Cohen wrote: First stab at iommu consolidation: - Migrate OMAP's iommu driver to the generic iommu API. With this in hand, users can now start using the generic iommu layer instead of calling omap-specific iommu API. New code that requires functionality missing from the generic iommu api, will add that functionality in the generic framework (e.g. adding framework awareness to multi page sizes, supported by the underlying hardware, will avoid the otherwise-inevitable code duplication when mapping a memory region). The IOMMU-API already supports multiple page-sizes. See the 'order'-parameter of the map/unmap functions. Further generalizing of iovmm strongly depends on our broader plans for providing a generic virtual memory manager and allocation framework (which, as discussed, should be separated from a specific mapper). The generic vmm for DMA is called DMA-API :) Any reason for not using that (those reasons should be fixed)? iovmm has a mainline user: omap3isp, and therefore must be maintained, but new potential users will either have to generalize it, or come up with a different generic framework that will replace it. Moving to the DMA-API should be considered here. If it is too much work iovmm can stay for a while, but the goal should be to get rid of it and only use the DMA-API. - Create a dedicated iommu drivers folder (and put the base iommu code there) Very good idea. Joerg P.S.: Please also Cc the iommu-list (io...@lists.linux-foundation.org) in the future for IOMMU related patches. -- 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi Joerg, On Mon, Jun 6, 2011 at 1:09 PM, Roedel, Joerg joerg.roe...@amd.com wrote: The IOMMU-API already supports multiple page-sizes. See the 'order'-parameter of the map/unmap functions. This is insufficient; users need somehow to tell what page sizes are supported by the underlying hardware (we can't assume host page-sizes, and we want to use bigger pages whenever possible, to relax the TLB pressure). Further generalizing of iovmm strongly depends on our broader plans for providing a generic virtual memory manager and allocation framework (which, as discussed, should be separated from a specific mapper). The generic vmm for DMA is called DMA-API :) Any reason for not using that (those reasons should be fixed)? This is definitely something we will look into (dspbridge will need it too, not only omap3isp). Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 6, 2011 at 12:10 PM, Arnd Bergmann a...@arndb.de wrote: I'd still prefer us to take small steps here, and not gate the omap iommu cleanups with Marek's generic dma_map_ops work though. Let's go forward and migrate omap's iommu to the generic iommu API, so new code will be able to use it (e.g. the long coming virtio-based IPC/AMP framework). Yes, of course. That's what I meant. Moving over omap to the IOMMU API is required anyway, so there is no point delaying that. Ok, great ! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote: This is insufficient; users need somehow to tell what page sizes are supported by the underlying hardware (we can't assume host page-sizes, and we want to use bigger pages whenever possible, to relax the TLB pressure). / What does the IOMMU-API user need this info for? On the x86 IOMMUs these details are handled transparently by the IOMMU driver. Joerg -- 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg joerg.roe...@amd.com wrote: Well, it certainly makes sense to have a single implementation for this. But I want to hide this complexity to the user of the IOMMU-API. The best choice is to put this into the layer between the IOMMU-API and the backend implementation. I agree. The IOMMU API should take physically contiguous regions from the user, split them up according to page-sizes (/alignment requirements) supported by the hardware, and then tell the underlying implementation what to map where. That interface is not put into stone. There were other complains about the -unmap part recently, so there is certainly room for improvement there. Once the supported page sizes are exposed to the framework, the current -unmap API should probably be enough. 'va' + 'order' sounds like all the information an implementation needs to unmap a page. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi Arnd, On Fri, Jun 3, 2011 at 6:53 PM, Arnd Bergmann a...@arndb.de wrote: I think the future of iovmm is looking not so good. Marek Szyprowski is working on a generic version of the dma-mapping API (dma_map_ops) based on the iommu API. Nice! I missed Marek's work somehow. As far as I can tell, once we have that in place, we you can migrate omap3isp from iovmm to dma-mapping and remove iovmm. Sounds like a plan. I'd still prefer us to take small steps here, and not gate the omap iommu cleanups with Marek's generic dma_map_ops work though. Let's go forward and migrate omap's iommu to the generic iommu API, so new code will be able to use it (e.g. the long coming virtio-based IPC/AMP framework). We'll migrate iovmm/omap3isp just enough so they don't break, but once the generic dma_map_ops work materializes, we'd be able to complete the migration, remove iovmm, and decouple omap3isp from omap-specific iommu APIs for good. I've only moved the omap and msm implementations for now, to demonstrate the idea (and support the ARM diet :), but if this is found desirable, we can bring in intel-iommu.c and amd_iommu.c as well. Yes, very good idea. Great! (to move intel-iommu.c, we'll have to move the declaration of pci_find_upstream_pcie_bridge() from drivers/pci/pci.h to include/linux/pci.h, but that's probably not too bad). Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi Kyungmin, On Fri, Jun 3, 2011 at 2:57 AM, Kyungmin Park kmp...@infradead.org wrote: Please see the RFC patch, ARM: DMA-mapping IOMMU integration http://www.spinics.net/lists/linux-mm/msg19856.html Marek's work somehow escaped me, thanks for the pointers ! Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] iommu: generic api migration and grouping
On Friday 03 June 2011, Ohad Ben-Cohen wrote: First stab at iommu consolidation: Hi Ohad, Great to see your progress here! - Migrate OMAP's iommu driver to the generic iommu API. With this in hand, users can now start using the generic iommu layer instead of calling omap-specific iommu API. New code that requires functionality missing from the generic iommu api, will add that functionality in the generic framework (e.g. adding framework awareness to multi page sizes, supported by the underlying hardware, will avoid the otherwise-inevitable code duplication when mapping a memory region). OMAP-specific api that is still exposed in the omap iommu driver can now be either moved to the generic iommu framework, or just removed (if not used). This api (and other omap-specific primitives like struct iommu) needs to be omapified (i.e. renamed to include an 'omap_' prefix). At this early point of this patch set this is too much churn though, so I'll do that in the following iteration, after (and if), the general direction is accepted. Sounds all good. - Migrate OMAP's iovmm (virtual memory manager) driver to the generic iommu API. With this in hand, iovmm no longer uses omap-specific api for mapping/unmapping operations. Nevertheless, iovmm is still coupled with omap's iommu even with this change: it assumes omap page sizes, and it uses omap's iommu objects to maintain its internal state. Further generalizing of iovmm strongly depends on our broader plans for providing a generic virtual memory manager and allocation framework (which, as discussed, should be separated from a specific mapper). iovmm has a mainline user: omap3isp, and therefore must be maintained, but new potential users will either have to generalize it, or come up with a different generic framework that will replace it. I think the future of iovmm is looking not so good. Marek Szyprowski is working on a generic version of the dma-mapping API (dma_map_ops) based on the iommu API. As far as I can tell, once we have that in place, we you can migrate omap3isp from iovmm to dma-mapping and remove iovmm. Of course if there are things missing from the dma-mapping API that are present in iovmm, we should know about them so that we can extend the dma-mapping API accordingly. - Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well (so it doesn't break). As with iovmm, omap3isp still depends on omap's iommu, mainly because iovmm depends on it, but also for iommu context saving and restoring. It is definitely desirable to completely remove omap3isp's dependency on the omap-specific iommu layer, and that will be possible as the required functionality will be added to generic framework. ok. - Create a dedicated iommu drivers folder (and put the base iommu code there) - Move OMAP's and MSM's iommu drivers to that drivers iommu folder Putting all iommu drivers together will ease finding similarities between different platforms, with the intention of solving problems once, in a generic framework which everyone can use. I've only moved the omap and msm implementations for now, to demonstrate the idea (and support the ARM diet :), but if this is found desirable, we can bring in intel-iommu.c and amd_iommu.c as well. Yes, very good idea. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/6] iommu: generic api migration and grouping
First stab at iommu consolidation:
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu API.
New code that requires functionality missing from the generic iommu api,
will add that functionality in the generic framework (e.g. adding framework
awareness to multi page sizes, supported by the underlying hardware, will
avoid the otherwise-inevitable code duplication when mapping a memory
region).
OMAP-specific api that is still exposed in the omap iommu driver can
now be either moved to the generic iommu framework, or just removed (if not
used).
This api (and other omap-specific primitives like struct iommu) needs to
be omapified (i.e. renamed to include an 'omap_' prefix). At this early
point of this patch set this is too much churn though, so I'll do that
in the following iteration, after (and if), the general direction is
accepted.
- Migrate OMAP's iovmm (virtual memory manager) driver to the generic
iommu API. With this in hand, iovmm no longer uses omap-specific api
for mapping/unmapping operations. Nevertheless, iovmm is still coupled
with omap's iommu even with this change: it assumes omap page sizes,
and it uses omap's iommu objects to maintain its internal state.
Further generalizing of iovmm strongly depends on our broader plans for
providing a generic virtual memory manager and allocation framework
(which, as discussed, should be separated from a specific mapper).
iovmm has a mainline user: omap3isp, and therefore must be maintained,
but new potential users will either have to generalize it, or come up
with a different generic framework that will replace it.
- Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well
(so it doesn't break). As with iovmm, omap3isp still depends on
omap's iommu, mainly because iovmm depends on it, but also for
iommu context saving and restoring.
It is definitely desirable to completely remove omap3isp's dependency
on the omap-specific iommu layer, and that will be possible as the
required functionality will be added to generic framework.
- Create a dedicated iommu drivers folder (and put the base iommu code there)
- Move OMAP's and MSM's iommu drivers to that drivers iommu folder
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
in a generic framework which everyone can use.
I've only moved the omap and msm implementations for now, to demonstrate
the idea (and support the ARM diet :), but if this is found desirable,
we can bring in intel-iommu.c and amd_iommu.c as well.
Meta:
- This patch set is not bisectable; it was splitted (and ordered) this way
to ease its review. Later iterations of this patch set will fix that
(most likely by squashing the first three patches)
- Based on and tested with 3.0-rc1
- OMAP's iommu code was tested on both OMAP3 and OMAP4
- omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only)
(thanks Laurent Pinchart for showing me the magic needed to test omap3isp :)
- MSM code was only compile tested
Ohad Ben-Cohen (6):
omap: iommu: generic iommu api migration
omap: iovmm: generic iommu api migration
media: omap3isp: generic iommu api migration
drivers: iommu: move to a dedicated folder
omap: iommu/iovmm: move to dedicated iommu folder
msm: iommu: move to dedicated iommu drivers folder
arch/arm/mach-msm/Kconfig | 15 -
arch/arm/mach-msm/Makefile |2 +-
arch/arm/plat-omap/Kconfig | 12 -
arch/arm/plat-omap/Makefile|2 -
arch/arm/plat-omap/include/plat/iommu.h|3 +-
arch/arm/plat-omap/{ = include/plat}/iopgtable.h | 18 ++
arch/arm/plat-omap/include/plat/iovmm.h| 27 +-
arch/x86/Kconfig |5 +-
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/base/Makefile |1 -
drivers/iommu/Kconfig | 32 +++
drivers/iommu/Makefile |5 +
drivers/{base = iommu}/iommu.c|0
.../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0
.../iommu/omap-iommu-debug.c |2 +-
.../iommu.c = drivers/iommu/omap-iommu.c | 290 +---
.../iovmm.c = drivers/iommu/omap-iovmm.c | 113 +---
drivers/media/video/Kconfig|2 +-
drivers/media/video/omap3isp/isp.c | 41 +++-
drivers/media/video/omap3isp/isp.h |3 +
drivers/media/video/omap3isp/ispccdc.c | 16 +-
drivers/media/video/omap3isp/ispstat.c |6 +-
Re: [RFC 0/6] iommu: generic api migration and grouping
Hi,
Good approach.
CC'ed the Samsung IOMMU developer. Marek.
BTW, Russell wants to use the DMA based IOMMU?
Please see the RFC patch, ARM: DMA-mapping IOMMU integration
http://www.spinics.net/lists/linux-mm/msg19856.html
Thank you,
Kyungmin Park
On Fri, Jun 3, 2011 at 7:27 AM, Ohad Ben-Cohen o...@wizery.com wrote:
First stab at iommu consolidation:
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu API.
New code that requires functionality missing from the generic iommu api,
will add that functionality in the generic framework (e.g. adding framework
awareness to multi page sizes, supported by the underlying hardware, will
avoid the otherwise-inevitable code duplication when mapping a memory
region).
OMAP-specific api that is still exposed in the omap iommu driver can
now be either moved to the generic iommu framework, or just removed (if not
used).
This api (and other omap-specific primitives like struct iommu) needs to
be omapified (i.e. renamed to include an 'omap_' prefix). At this early
point of this patch set this is too much churn though, so I'll do that
in the following iteration, after (and if), the general direction is
accepted.
- Migrate OMAP's iovmm (virtual memory manager) driver to the generic
iommu API. With this in hand, iovmm no longer uses omap-specific api
for mapping/unmapping operations. Nevertheless, iovmm is still coupled
with omap's iommu even with this change: it assumes omap page sizes,
and it uses omap's iommu objects to maintain its internal state.
Further generalizing of iovmm strongly depends on our broader plans for
providing a generic virtual memory manager and allocation framework
(which, as discussed, should be separated from a specific mapper).
iovmm has a mainline user: omap3isp, and therefore must be maintained,
but new potential users will either have to generalize it, or come up
with a different generic framework that will replace it.
- Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well
(so it doesn't break). As with iovmm, omap3isp still depends on
omap's iommu, mainly because iovmm depends on it, but also for
iommu context saving and restoring.
It is definitely desirable to completely remove omap3isp's dependency
on the omap-specific iommu layer, and that will be possible as the
required functionality will be added to generic framework.
- Create a dedicated iommu drivers folder (and put the base iommu code there)
- Move OMAP's and MSM's iommu drivers to that drivers iommu folder
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
in a generic framework which everyone can use.
I've only moved the omap and msm implementations for now, to demonstrate
the idea (and support the ARM diet :), but if this is found desirable,
we can bring in intel-iommu.c and amd_iommu.c as well.
Meta:
- This patch set is not bisectable; it was splitted (and ordered) this way
to ease its review. Later iterations of this patch set will fix that
(most likely by squashing the first three patches)
- Based on and tested with 3.0-rc1
- OMAP's iommu code was tested on both OMAP3 and OMAP4
- omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only)
(thanks Laurent Pinchart for showing me the magic needed to test omap3isp :)
- MSM code was only compile tested
Ohad Ben-Cohen (6):
omap: iommu: generic iommu api migration
omap: iovmm: generic iommu api migration
media: omap3isp: generic iommu api migration
drivers: iommu: move to a dedicated folder
omap: iommu/iovmm: move to dedicated iommu folder
msm: iommu: move to dedicated iommu drivers folder
arch/arm/mach-msm/Kconfig | 15 -
arch/arm/mach-msm/Makefile | 2 +-
arch/arm/plat-omap/Kconfig | 12 -
arch/arm/plat-omap/Makefile | 2 -
arch/arm/plat-omap/include/plat/iommu.h | 3 +-
arch/arm/plat-omap/{ = include/plat}/iopgtable.h | 18 ++
arch/arm/plat-omap/include/plat/iovmm.h | 27 +-
arch/x86/Kconfig | 5 +-
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/base/Makefile | 1 -
drivers/iommu/Kconfig | 32 +++
drivers/iommu/Makefile | 5 +
drivers/{base = iommu}/iommu.c | 0
.../mach-msm/iommu.c = drivers/iommu/msm-iommu.c | 0
.../iommu/omap-iommu-debug.c | 2 +-
.../iommu.c = drivers/iommu/omap-iommu.c | 290
+---
.../iovmm.c = drivers/iommu/omap-iovmm.c
