How to specify IOMMU'able devices in DT (was: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely)
On Fri, 21 Sep 2012 20:16:00 +0200
Krishna Reddy vdu...@nvidia.com wrote:
The device(H/W controller) need to access few special memory
blocks(IOVA==PA) and DRAM as well.
OK, so only /some/ of the VA space is VA==PA, and some is remapped; that's a
little different that what you originally implied above.
BTW, which HW module is this; AVP/COP or something else. This sounds like an
odd requirement.
This is not specific to ARM7. There are protected memory regions on Tegra that
can be accessed by some controllers like display, 2D, 3D, VDE, HDA. These are
DRAM regions configured as protected by BootRom. These memory regions
are not exposed to and not managed by OS page allocator. The H/W controller
accesses to these regions still to go through IOMMU.
The IOMMU view for all the H/W controllers is not uniform on Tegra.
Some Controllers see entire 4GB IOVA space. i.e all accesses go though IOMMU.
Some controllers see the IOVA Space that don't overlap with MMIO space. i.e
The MMIO address access bypass IOMMU and directly go to MMIO space.
Tegra IOMMU can support multiple address spaces as well. To hide controller
Specific behavior, the drivers should take care of one to one mapping and
remove inaccessible iova spaces in their address space's based platform
device info.
The above is also related to another issue,
how to specify IOMMU'able devices in DT.
As mentioned above, some IOVA mapping may be unique to some devices,
and the number of IOMMU'able device are quite many nowadays, a few
dozen in Tegra30 now. Basically they are seen as just normal platform
devices from CPU even if they belong to different busses in H/W. IOW, their
IOMMU'ability just depend on a platfrom bus from _S/W_ POV. Doing each
registration(create a map attach device) in board files isn't so
nice. Currently we register them at platform_device_add() at once
with just a HACK(*1), but this could/should be done based on the info
passed from DT. For tegra, those parameter could be, ASID and
address range(start, size, alignment). For example in DT:
deviceA {
start size align
iommu = 0x1234 0x0040 0x000; # exclusively specify
start or align
iommu = 0x 0x0040 0x001;
iommu = 0x1234 0x0004 0x1238 0x0004; # start,
size could be repeated...
asid = 3; # if needed
or
dma_range = 0x1234 0x0040 0x000; # if iommu is
considered as one implementation of dma.
};
Is there any way to specify each IOMMU'able _platform device_ and
specify its map in DT?
The above ASID may be specific to Tegra, though. If we can specify the
above info in DT and the info is passed to kernel, some platform
common code would register them as IOMMU'able device automatically. It
would be really covenient if this is done in platform_device/IOMMU
common code. If the above attribute is implemented specific to
Tegra/platform, we have to call attach_device quite many times
somewhere in device initializations.
Any comment would be really appreciated.
*1:
From dd4dd6532d705c7bba0914b54c819d8d735c2fad Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu hd...@nvidia.com
Date: Thu, 22 Mar 2012 16:06:27 +0200
Subject: [RFC 1/1] platform: IOMMU'able platform_device w/
PLATFORM_ENABLE_IOMMU
Introduced a new kernel config option, PLATFORM_ENABLE_IOMMU. With
this, all platform devices can be converted to be IOMMU'able if
platform_bus has non-null dma_iommu_map, where H/Ws always see its IO
virtual address and virt_to_phys() doesn't work from H/W POV.
Signed-off-by: Hiroshi Doyu hd...@nvidia.com
---
arch/arm/mm/dma-mapping.c |7 +++
drivers/base/Kconfig |4
drivers/base/platform.c | 17 +++--
drivers/iommu/Kconfig |2 +-
include/linux/device.h|5 -
5 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 242289f..28ca7c2 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1899,6 +1899,13 @@ arm_iommu_create_mapping(struct bus_type *bus,
dma_addr_t base, size_t size,
mapping-order = order;
spin_lock_init(mapping-lock);
+#ifdef CONFIG_PLATFORM_ENABLE_IOMMU
+ if (WARN_ON(bus-map))
+ goto err3;
+
+ bus-map = mapping;
+#endif
+
mapping-domain = iommu_domain_alloc(bus);
if (!mapping-domain)
goto err3;
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 3df339c..0f45311 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -308,4 +308,8 @@ config CMA_AREAS
endif
+config PLATFORM_ENABLE_IOMMU
+bool Make platform devices iommuable
+ depends on IOMMU_API
+
endmenu
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a1a7225..9eae3be 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -21,6 +21,8 @@
#include linux/slab.h
#include
Re: How to specify IOMMU'able devices in DT (was: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely)
Hi James,
On Mon, 24 Sep 2012 11:28:01 +0200
James Bottomley james.bottom...@hansenpartnership.com wrote:
On Mon, 2012-09-24 at 12:04 +0300, Hiroshi Doyu wrote:
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a1a7225..9eae3be 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -21,6 +21,8 @@
#include linux/slab.h
#include linux/pm_runtime.h
+#include asm/dma-iommu.h
+
#include base.h
#define to_platform_driver(drv)(container_of((drv), struct
platform_driver, \
@@ -305,8 +307,19 @@ int platform_device_add(struct platform_device
*pdev)
dev_name(pdev-dev), dev_name(pdev-dev.parent));
ret = device_add(pdev-dev);
- if (ret == 0)
- return ret;
+ if (ret)
+ goto failed;
+
+#ifdef CONFIG_PLATFORM_ENABLE_IOMMU
+ if (platform_bus_type.map !pdev-dev.archdata.mapping) {
+ ret = arm_iommu_attach_device(pdev-dev,
+ platform_bus_type.map);
+ if (ret)
+ goto failed;
This is horrible ... you're adding an architecture specific callback
into our generic code; that's really a no-no. If the concept of
CONFIG_PLATFORM_ENABE_IOMMU is useful to more than just arm, then this
could become a generic callback.
As mentioned in the original, this is a heck to explain what is
needed. I am looking for some generic solution for how to specify
IOMMU info for each platform devices. I'm guessing that some other SoC
may have the similar requirements on the above. As you mentioned, this
solution should be a generic, not arch specific.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: How to specify IOMMU'able devices in DT (was: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely)
Hello,
On Monday, September 24, 2012 11:45 AM Hiroshi Doyu wrote:
On Mon, 24 Sep 2012 11:28:01 +0200
James Bottomley james.bottom...@hansenpartnership.com wrote:
On Mon, 2012-09-24 at 12:04 +0300, Hiroshi Doyu wrote:
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a1a7225..9eae3be 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -21,6 +21,8 @@
#include linux/slab.h
#include linux/pm_runtime.h
+#include asm/dma-iommu.h
+
#include base.h
#define to_platform_driver(drv)(container_of((drv), struct
platform_driver, \
@@ -305,8 +307,19 @@ int platform_device_add(struct platform_device
*pdev)
dev_name(pdev-dev), dev_name(pdev-dev.parent));
ret = device_add(pdev-dev);
- if (ret == 0)
- return ret;
+ if (ret)
+ goto failed;
+
+#ifdef CONFIG_PLATFORM_ENABLE_IOMMU
+ if (platform_bus_type.map !pdev-dev.archdata.mapping) {
+ ret = arm_iommu_attach_device(pdev-dev,
+ platform_bus_type.map);
+ if (ret)
+ goto failed;
This is horrible ... you're adding an architecture specific callback
into our generic code; that's really a no-no. If the concept of
CONFIG_PLATFORM_ENABE_IOMMU is useful to more than just arm, then this
could become a generic callback.
As mentioned in the original, this is a heck to explain what is
needed. I am looking for some generic solution for how to specify
IOMMU info for each platform devices. I'm guessing that some other SoC
may have the similar requirements on the above. As you mentioned, this
solution should be a generic, not arch specific.
Please read more about bus notifiers. IMHO a good example is provided in
the following thread:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12238.html
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: How to specify IOMMU'able devices in DT (was: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely)
On Mon, 2012-09-24 at 12:04 +0300, Hiroshi Doyu wrote:
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a1a7225..9eae3be 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -21,6 +21,8 @@
#include linux/slab.h
#include linux/pm_runtime.h
+#include asm/dma-iommu.h
+
#include base.h
#define to_platform_driver(drv)(container_of((drv), struct
platform_driver, \
@@ -305,8 +307,19 @@ int platform_device_add(struct platform_device
*pdev)
dev_name(pdev-dev), dev_name(pdev-dev.parent));
ret = device_add(pdev-dev);
- if (ret == 0)
- return ret;
+ if (ret)
+ goto failed;
+
+#ifdef CONFIG_PLATFORM_ENABLE_IOMMU
+ if (platform_bus_type.map !pdev-dev.archdata.mapping) {
+ ret = arm_iommu_attach_device(pdev-dev,
+ platform_bus_type.map);
+ if (ret)
+ goto failed;
This is horrible ... you're adding an architecture specific callback
into our generic code; that's really a no-no. If the concept of
CONFIG_PLATFORM_ENABE_IOMMU is useful to more than just arm, then this
could become a generic callback.
James
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
The device(H/W controller) need to access few special memory blocks(IOVA==PA) and DRAM as well. OK, so only /some/ of the VA space is VA==PA, and some is remapped; that's a little different that what you originally implied above. BTW, which HW module is this; AVP/COP or something else. This sounds like an odd requirement. This is not specific to ARM7. There are protected memory regions on Tegra that can be accessed by some controllers like display, 2D, 3D, VDE, HDA. These are DRAM regions configured as protected by BootRom. These memory regions are not exposed to and not managed by OS page allocator. The H/W controller accesses to these regions still to go through IOMMU. The IOMMU view for all the H/W controllers is not uniform on Tegra. Some Controllers see entire 4GB IOVA space. i.e all accesses go though IOMMU. Some controllers see the IOVA Space that don't overlap with MMIO space. i.e The MMIO address access bypass IOMMU and directly go to MMIO space. Tegra IOMMU can support multiple address spaces as well. To hide controller Specific behavior, the drivers should take care of one to one mapping and remove inaccessible iova spaces in their address space's based platform device info. In my initial mail, I referred protected memory regions as MMIO blocks, which is incorrect. -KR ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On Tegra, the following use cases need specific IOVA mapping. 1. Few MMIO blocks need IOVA=PA mapping setup. In that case, why would we enable the IOMMU for that one device; IOMMU disabled means VA==PA, right? Perhaps isolation of the device so it can only access certain PA ranges for security? The device(H/W controller) need to access few special memory blocks(IOVA==PA) and DRAM as well. If IOMMU is disabled, then it has to handle memory fragmentation, which defeats the purpose of IOMMU support. There is also a case where frame buffer memory is passed from BootLoader to Kernel and display H/W continues to access it with IOMMU enabled. To support this, the one to one mapping has to be setup before enabling IOMMU. -KR ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On 09/20/2012 12:40 AM, Krishna Reddy wrote: On Tegra, the following use cases need specific IOVA mapping. 1. Few MMIO blocks need IOVA=PA mapping setup. In that case, why would we enable the IOMMU for that one device; IOMMU disabled means VA==PA, right? Perhaps isolation of the device so it can only access certain PA ranges for security? The device(H/W controller) need to access few special memory blocks(IOVA==PA) and DRAM as well. OK, so only /some/ of the VA space is VA==PA, and some is remapped; that's a little different that what you originally implied above. BTW, which HW module is this; AVP/COP or something else. This sounds like an odd requirement. There is also a case where frame buffer memory is passed from BootLoader to Kernel and display H/W continues to access it with IOMMU enabled. To support this, the one to one mapping has to be setup before enabling IOMMU. Yes, that makes sense. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
Hi Joerg,
On Tue, 18 Sep 2012 14:49:18 +0200
Joerg Roedel joerg.roe...@amd.com wrote:
On Wed, Aug 29, 2012 at 09:55:30AM +0300, Hiroshi Doyu wrote:
The following APIs are needed for us to support the legacy Tegra
memory manager for devices(NvMap) with *DMA mapping API*.
Maybe I am not understanding the need completly. Can you elaborate on
why this is needed for legacy Tegra?
Actually not for legacy but it's necessary to replace homebrewed
in-kernel API(not upstreamed) with the standard ones. The homebrewed
in-kernel API has been used for the abvoe nvmap as its backend. The
homebrewed ones are being replaced with the standard ones, IOMMU-API,
DMA-API and dma-buf, mainly for transition purpose. I found that some
missing features in DMA-API for that. I posted since other SoCs may
have the similiar requirements, (1) To specify IOVA address at
allocation, and (2) To have IOVA allocation and mapping separately.
New API:
-iova_alloc(): To allocate IOVA area.
-iova_alloc_at(): To allocate IOVA area at specific address.
-iova_free(): To free IOVA area.
-map_page_at(): To map page at specific IOVA.
This sounds like a layering violation. The situation today is as
follows:
DMA-API : Handle DMA-addresses including an address allocator
IOMMU-API : Full control over DMA address space, no address
allocator
So what you want to do add to the DMA-API is already part of the
IOMMU-API.
Here is my suggestion what you can do instead of extending the DMA-API.
You can use the IOMMU-API to initialize the device address space with
any mappings at the IOVAs you need the mappings. In the end you allocate
another free range in the device address space and use that to satisfy
DMA-API allocations. Any reason why that could not work?
I guess that it would work. Originally I thought that using DMA-API
and IOMMU-API together in driver might be kind of layering violation
since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
might be cleaner. Considering that DMA API traditionally handling
*anonymous* {bus,iova} address only, introducing the concept of
specific address in DMA API may not be so encouraged, though.
It would be nice to listen how other SoCs have solved similar needs.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On Wednesday 19 September 2012, Hiroshi Doyu wrote:
I guess that it would work. Originally I thought that using DMA-API
and IOMMU-API together in driver might be kind of layering violation
since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
might be cleaner. Considering that DMA API traditionally handling
anonymous {bus,iova} address only, introducing the concept of
specific address in DMA API may not be so encouraged, though.
It would be nice to listen how other SoCs have solved similar needs.
In general, I would recommend using only the IOMMU API when you have a device
driver that needs to control the bus virtual address space and that manages
a device that resides in its own IOMMU context. I would recommend using
only the dma-mapping API when you have a device that lives in a shared
bus virtual address space with other devices, and then never ask for
a specific bus virtual address.
Can you explain what devices you see that don't fit in one of those two
categories?
Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
Hi Arnd,
On Wed, 19 Sep 2012 09:59:45 +0200
Arnd Bergmann a...@arndb.de wrote:
On Wednesday 19 September 2012, Hiroshi Doyu wrote:
I guess that it would work. Originally I thought that using DMA-API
and IOMMU-API together in driver might be kind of layering violation
since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
might be cleaner. Considering that DMA API traditionally handling
anonymous {bus,iova} address only, introducing the concept of
specific address in DMA API may not be so encouraged, though.
It would be nice to listen how other SoCs have solved similar needs.
In general, I would recommend using only the IOMMU API when you have a device
driver that needs to control the bus virtual address space and that manages
a device that resides in its own IOMMU context. I would recommend using
only the dma-mapping API when you have a device that lives in a shared
bus virtual address space with other devices, and then never ask for
a specific bus virtual address.
Can you explain what devices you see that don't fit in one of those two
categories?
I think that the above fis, but I'll continue to explain our case a little
bit more below:
In Tegra, there's a few dozen of IOMMU'able devices. Each of them can
be configured to enable/disable IOMMU. Also some IOMMU Address Space
IDs(ASID) can be assigned to each device respectively. Some of devices
are just traditional ones to use traditional dma-mapping API only,
like normal SD/MMC. Some of devices require some specific IOVA address
for reset vector and MMIO. For example, Tegra has another ARM(ARM7) as
such. For traditional devices, dma mapping API is so nice that driver
doesn't have to be aware of IOMMU. The same dma mapping API works
with/without IOMMU.
If both devices are attached to the same mapping, IOMMU-API and
dma-mapping API would be used together from different
devices. Technically this can be avoided to assign different maps to
each device, though.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On Wed, Sep 19, 2012 at 07:59:45AM +, Arnd Bergmann wrote:
On Wednesday 19 September 2012, Hiroshi Doyu wrote:
I guess that it would work. Originally I thought that using DMA-API
and IOMMU-API together in driver might be kind of layering violation
since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
might be cleaner. Considering that DMA API traditionally handling
anonymous {bus,iova} address only, introducing the concept of
specific address in DMA API may not be so encouraged, though.
It would be nice to listen how other SoCs have solved similar needs.
In general, I would recommend using only the IOMMU API when you have a device
driver that needs to control the bus virtual address space and that manages
a device that resides in its own IOMMU context. I would recommend using
only the dma-mapping API when you have a device that lives in a shared
bus virtual address space with other devices, and then never ask for
a specific bus virtual address.
Can you explain what devices you see that don't fit in one of those two
categories?
Well, I don't think that a driver should limit to one of these 2 APIs. A
driver can very well use the IOMMU-API during initialization (for
example to map the firmware to an address the device expects it to be)
and use the DMA-API later during normal operation to exchange data with
the device.
When a device driver would only use the IOMMU-API and needs small
DMA-able areas it has to re-implement something like the DMA-API
(basically an address allocator) for that. So I don't see a reason why
both can't be used in a device driver.
Regards,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
When a device driver would only use the IOMMU-API and needs small DMA-
able areas it has to re-implement something like the DMA-API (basically an
address allocator) for that. So I don't see a reason why both can't be used
in a
device driver.
On Tegra, the following use cases need specific IOVA mapping.
1. Few MMIO blocks need IOVA=PA mapping setup.
2. CPU side loads the firmware into physical memory, which has to be
mapped to a specific IOVA address, as firmware is statically linked based
on specific IOVA address.
DMA api's allow specifying only one address space per platform device.
For #1, DMA API can't be used as it doesn't allow mapping specific IOVA to PA.
IOMMU API can be used for mapping specific IOVA to PA. But, in order to use
IOMMU API, the driver has to dereference the dev pointer, get domain ptr,
take lock, and allocate memory from dma_iommu_mapping. This breaks
the abstraction for struct device. Each device driver that need IOVA=PA has to
do this, which is redundant.
For #2, physical memory allocations alone can be done through DMA as it also
allocates IOVA space Implicitly. Even after allocating physical memory through
DMA API's, it would have same problem as #1 for IOVA to PA mapping.
If a fake device is expected to be created for specific IOVA allocation, then it
may lead to creating multiple fake devices per specific IOVA and per
ASID(unique IOVA address space). As domain init would be done based on
device name, the fake device should have the same name as of original platform
device.
If DMA API allows allocating specific IOVA address and mapping IOVA to specific
PA,
device driver don't need to know any details of struct device and specifying
one mapping per device is enough and no need for fake devices.
Comments are much appreciated.
-KR
-Original Message-
From: Joerg Roedel [mailto:joerg.roe...@amd.com]
Sent: Wednesday, September 19, 2012 5:50 AM
To: Arnd Bergmann
Cc: Hiroshi Doyu; m.szyprow...@samsung.com; li...@arm.linux.org.uk;
minc...@kernel.org; chunsang.je...@linaro.org; linux-
ker...@vger.kernel.org; subas...@gmail.com; linaro-mm-...@lists.linaro.org;
linux...@kvack.org; iommu@lists.linux-foundation.org; Krishna Reddy; linux-
te...@vger.kernel.org; kyungmin.p...@samsung.com;
pullip@samsung.com; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA
more precisely
On Wed, Sep 19, 2012 at 07:59:45AM +, Arnd Bergmann wrote:
On Wednesday 19 September 2012, Hiroshi Doyu wrote:
I guess that it would work. Originally I thought that using DMA-API
and IOMMU-API together in driver might be kind of layering violation
since IOMMU-API itself is used in DMA-API. Only DMA-API used in
driver might be cleaner. Considering that DMA API traditionally
handling anonymous {bus,iova} address only, introducing the concept
of specific address in DMA API may not be so encouraged, though.
It would be nice to listen how other SoCs have solved similar needs.
In general, I would recommend using only the IOMMU API when you have a
device driver that needs to control the bus virtual address space and
that manages a device that resides in its own IOMMU context. I would
recommend using only the dma-mapping API when you have a device that
lives in a shared bus virtual address space with other devices, and
then never ask for a specific bus virtual address.
Can you explain what devices you see that don't fit in one of those
two categories?
Well, I don't think that a driver should limit to one of these 2 APIs. A
driver can
very well use the IOMMU-API during initialization (for example to map the
firmware to an address the device expects it to be) and use the DMA-API later
during normal operation to exchange data with the device.
When a device driver would only use the IOMMU-API and needs small DMA-
able areas it has to re-implement something like the DMA-API (basically an
address allocator) for that. So I don't see a reason why both can't be used
in a
device driver.
Regards,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General
Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr.
43632
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On 09/19/2012 07:44 PM, Krishna Reddy wrote: When a device driver would only use the IOMMU-API and needs small DMA- able areas it has to re-implement something like the DMA-API (basically an address allocator) for that. So I don't see a reason why both can't be used in a device driver. On Tegra, the following use cases need specific IOVA mapping. 1. Few MMIO blocks need IOVA=PA mapping setup. In that case, why would we enable the IOMMU for that one device; IOMMU disabled means VA==PA, right? Perhaps isolation of the device so it can only access certain PA ranges for security? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
Hi,
The following APIs are needed for us to support the legacy Tegra
memory manager for devices(NvMap) with *DMA mapping API*.
New API:
-iova_alloc(): To allocate IOVA area.
-iova_alloc_at(): To allocate IOVA area at specific address.
-iova_free(): To free IOVA area.
-map_page_at(): To map page at specific IOVA.
misc:
-iova_get_free_total(): To return how much IOVA is available totally.
-iova_get_free_max(): To return the size of biggest IOVA area.
Although NvMap itself will be replaced soon, there are cases for the
above API where we need to specify IOVA explicitly.
(1) HWAs may require the address for special purpose, like reset vector.
(2) IOVA linear mapping: ex: [RFC 5/5] ARM: dma-mapping: Introduce
dma_map_linear_attrs() for IOVA linear map
(3) To support different heaps. To have allocation and mapping
independently.
Some of them could be supported with creating different mappings, but
currently a device can have a single contiguous mapping, and we cannot
specifiy any address inside of a map since all IOVA alloction is done
implicitly now.
This is the revised version of:
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001947.html
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001948.html
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001949.html
Any comment would be really appreciated.
Hiroshi Doyu (5):
ARM: dma-mapping: New dma_map_ops-iova_get_free_{total,max}
functions
ARM: dma-mapping: New dma_map_ops-iova_{alloc,free}() functions
ARM: dma-mapping: New dma_map_ops-iova_alloc*_at* function
ARM: dma-mapping: New dma_map_ops-map_page*_at* function
ARM: dma-mapping: Introduce dma_map_linear_attrs() for IOVA linear
map
arch/arm/include/asm/dma-mapping.h | 55 +
arch/arm/mm/dma-mapping.c| 124 ++
include/asm-generic/dma-mapping-common.h | 20 +
include/linux/dma-mapping.h | 14
4 files changed, 213 insertions(+), 0 deletions(-)
--
1.7.5.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
