Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Fri, Jul 02, 2010 at 12:09:02AM -0700, Zach Pfeffer wrote: Hari Kanigeri wrote: He demonstrated the usage of his code in one of the emails he sent out initially. Did you go over that, and what (or how many) step would you use with the current code to do the same thing? -- So is this patch set adding layers and abstractions to help the User ? If the idea is to share some memory across multiple devices, I guess you can achieve the same by calling the map function provided by iommu module and sharing the mapped address to the 10's or 100's of devices to access the buffers. You would only need a dedicated virtual pool per IOMMU device to manage its virtual memory allocations. Yeah, you can do that. My idea is to get away from explicit addressing and encapsulate the device address to physical address link into a mapping. The DMA-API already does this with the help of IOMMUs if they are present. What is the benefit of your approach over that? Joerg -- 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
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, Jul 01, 2010 at 03:00:17PM -0700, Zach Pfeffer wrote: Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs [...] Thats not true. Multiple IOMMUs are completly handled by the IOMMU drivers. In the case of the IOMMU-API backend drivers this also includes the ability to use page-tables on multiple IOMMUs. Since the particular topology is run-time configurable all of these use-cases and more can be expressed without pushing the topology into the low-level IOMMU driver. The IOMMU driver has to know about the topology anyway because it needs to know which IOMMU it needs to program for a particular device. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). I partially agree here. All the IOMMU implementations in the Linux kernel have a lot of functionality in common where code could be shared. Work to share code has been done in the past by Fujita Tomonori but there are more places to work on. I am just not sure if a new front-end API is the right way to do this. Joerg -- 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
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote: Daniel Walker wrote: So if we include this code which map implementations could you collapse into this implementations ? Generally , what currently existing code can VCMM help to eliminate? In theory, it can eliminate all code the interoperates between IOMMU, CPU and non-IOMMU based devices and all the mapping code, alignment, mapping attribute and special block size support that's been implemented. Thats a very abstract statement. Can you point to particular code files and give a rough sketch how it could be improved using VCMM? Joerg -- 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
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote: Andi Kleen wrote: Hmm? dma_map_* does not change any CPU mappings. It only sets up DMA mapping(s). Sure, but I was saying that iommu_map() doesn't just set up the IOMMU mappings, its sets up both the iommu and kernel buffer mappings. What do you mean by kernel buffer mappings? That assumes that all the IOMMUs on the system support the same page table format, right? Actually no. Since the VCMM abstracts a page-table as a Virtual Contiguous Region (VCM) a VCM can be associated with any device, regardless of their individual page table format. The IOMMU-API abstracts a page-table as a domain which can also be associated with any device (behind an iommu). Joerg -- 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
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote: Joerg Roedel wrote: The DMA-API already does this with the help of IOMMUs if they are present. What is the benefit of your approach over that? The grist to the DMA-API mill is the opaque scatterlist. Each scatterlist element brings together a physical address and a bus address that may be different. The set of scatterlist elements constitute both the set of physical buffers and the mappings to those buffers. My approach separates these two things into a struct physmem which contains the set of physical buffers and a struct reservation which contains the set of bus addresses (or device addresses). Each element in the struct physmem may be of various lengths (without resorting to chaining). A map call maps the one set to the other. Okay, thats a different concept, where is the benefit? Joerg -- 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
[PATCH] arm: omap: Fix build error in ispccdc.c
The following build error occurs with 3.1-rc5: CC drivers/media/video/omap3isp/ispccdc.o /home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c: In function 'ccdc_lsc_config': /home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c:427:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] /home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c:427:6: warning: assignment makes pointer from integer without a cast [enabled by default] This patch adds the missing 'linux/slab.h' include to fix the problem. Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: linux-me...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- drivers/media/video/omap3isp/ispccdc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c index 9d3459d..80796eb 100644 --- a/drivers/media/video/omap3isp/ispccdc.c +++ b/drivers/media/video/omap3isp/ispccdc.c @@ -31,6 +31,7 @@ #include linux/dma-mapping.h #include linux/mm.h #include linux/sched.h +#include linux/slab.h #include media/v4l2-event.h #include isp.h -- 1.7.4.1 -- 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
[PATCH] iommu/omap: Fix build error with !IOMMU_SUPPORT
Without this patch it is possible to select the VIDEO_OMAP3 driver which then selects OMAP_IOVMM. But the omap iommu driver is not compiled without IOMMU_SUPPORT enabled. Fix that by forcing OMAP_IOMMU and OMAP_IOVMM are enabled before VIDEO_OMAP3 can be selected. Cc: Ohad Ben-Cohen o...@wizery.com Cc: io...@lists.linux-foundation.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- drivers/iommu/Kconfig |4 ++-- drivers/media/video/Kconfig |3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index d901930..ae46776 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -114,8 +114,8 @@ config OMAP_IOMMU select IOMMU_API config OMAP_IOVMM - tristate - select OMAP_IOMMU + tristate OMAP IO Virtual Memory Manager Support + depends on OMAP_IOMMU config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU/IOVMM internals in DebugFS diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 6a25fad..6201069 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -763,8 +763,7 @@ source drivers/media/video/m5mols/Kconfig config VIDEO_OMAP3 tristate OMAP 3 Camera support (EXPERIMENTAL) - select OMAP_IOVMM - depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API ARCH_OMAP3 EXPERIMENTAL + depends on OMAP_IOVMM VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API ARCH_OMAP3 EXPERIMENTAL ---help--- Driver for an OMAP 3 camera controller. -- 1.7.4.1 -- 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
Re: [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware
On Tue, Nov 08, 2011 at 02:57:02PM +0200, Ohad Ben-Cohen wrote: Joerg, gentle reminder. thanks. Just wanted to wait until -rc1 is out and I can start merging new stuff :) 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: cpuidle34xx.c: Fix compile error
Add missing module.h include to provide THIS_MODULE. Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- arch/arm/mach-omap2/cpuidle34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 1fe35c2..158c17e 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -24,6 +24,7 @@ #include linux/sched.h #include linux/cpuidle.h +#include linux/module.h #include plat/prcm.h #include plat/irqs.h -- 1.7.5.4 -- 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
Re: [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware
On Tue, Nov 08, 2011 at 04:03:09PM +0200, Ohad Ben-Cohen wrote: On Tue, Nov 8, 2011 at 4:01 PM, Joerg Roedel joerg.roe...@amd.com wrote: On Tue, Nov 08, 2011 at 02:57:02PM +0200, Ohad Ben-Cohen wrote: Joerg, gentle reminder. thanks. Just wanted to wait until -rc1 is out and I can start merging new stuff :) np, thanks :) Does not apply cleanly. Can you please rebase against v3.2-rc1 and resend? 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iommu: omap: fix compile failure
On Tue, Nov 08, 2011 at 06:29:15PM +0800, tom.leim...@gmail.com wrote: From: Ming Lei tom.leim...@gmail.com Fix the failure below: Applied with a shorter commit-msg. Thanks. -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: cpuidle34xx.c: Fix compile error
On Tue, Nov 08, 2011 at 09:36:48AM -0800, Kevin Hilman wrote: Joerg Roedel joerg.roe...@amd.com writes: Add missing module.h include to provide THIS_MODULE. Signed-off-by: Joerg Roedel joerg.roe...@amd.com FYI... Tony has already queued fix for this in his fixes branch. http://marc.info/?l=linux-arm-kernelm=132071036621713w=2 Great. I stumbled over it while compile-testing the iommu-tree for omap. Thanks, 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 08:16:16PM +0800, cody wrote: On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote: On Thu, Nov 10, 2011 at 8:17 AM, Kai Huangmail.kai.hu...@gmail.com wrote: Seems the unmap function don't take phys as parameter, does this mean domain-ops-unmap will walk through the page table to find out the actual page size? The short answer is yes, and furthermore, we also consider to remove the size param from domain-ops-unmap entirely at some point. We had a long discussion about it, please see: https://lkml.org/lkml/2011/10/10/234 Yes I've seen your discussion, I followed this thread from beginning:) How about the IOTLB flush? As I said I think we need to consider that IOMMU (even does not exist now) may have some limitation on IOTLB flush, and hiding page size from IOTLB flush code may hurt performance, or even worse, trigger undefined behaviors. We can only care about IOMMUs that exist today or ones that will exist and we already know of. In general for the hardware I know of a page-size is not required for implementing unmap operations. Requiring this would imply that any user of the IOMMU-API needs to keeps track of the page-sizes used to map a given area. This would be a huge burden which is not really necessary because the IOMMU driver already has this information and can return it to the user. So if you want to change that you need a very good reason for it. 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 10:35:34PM +0800, cody wrote: Yes I totally agree page-size is not required for unmap operations and should not be added as parameter to map/unmap operations. I am not saying the unmap operation, but the IOTLB flush operation. My point is we also may also need to add similar logic in IOTLB flush code (such as in Intel IOMMU dirver) to grantee that when issuing IOTLB flush command for large page, we will still meet the hardware limitation of flushing large page. Seems for Intel IOMMU the only limitation is the mask value (indicating number of 4k-pages) cannot be smaller than the value to cover large page, and seems current Intel IOMMU driver code has covered this case well. I am not familiar with how AMD IOMMU issues IOTLB flush command, it should be able to handle this large page case too. So at this moment, this patch should not have any issues :) The map-operation actually takes a size, as it should. The idea is to change this function to a map_page interface which takes a page-size parameter, but thats another story. The IOTLB flushing is not exposed by the IOMMU-API anyway. To whatever is necessary to do that, it is the business of the IOMMU driver. So in the unmap-path the driver finds out the page-size to unmap and can immediatly flush the IOTLB for that page. 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 03:28:50PM +, David Woodhouse wrote: Which brings me to another question I have been pondering... do we even have a consensus on exactly *when* the IOTLB should be flushed? Well, sort of, there is still the outstanding idea of the iommu_commit() interface for the IOMMU-API. Even just for the Intel IOMMU, we have three different behaviours: - For DMA API users by default, we do 'batched unmap', so a mapping may be active for a period of time after the driver has requested that it be unmapped. The requirement for the DMA-API is, that the IOTLB must be consistent with existing mappings, and only with the parts that are really mapped. The unmapped parts are not important. This allows nice optimizations like your 'batched unmap' on the Intel IOMMU driver side. The AMD IOMMU driver uses a round-robin bitmap allocator for the IO addresses which makes it very easy to flush certain IOTLB ranges only before they are reused. - ... unless booted with 'intel_iommu=strict', in which case we do the unmap and IOTLB flush immediately before returning to the driver. There is something similar on the AMD IOMMU side. There it is called unmap_flush. - But the IOMMU API for virtualisation is different. In fact that doesn't seem to flush the IOTLB at all. Which is probably a bug. Well, *current* requirement is, that the IOTLB is in sync with the page-table at every time. This is true for the iommu_map and especially for the iommu_unmap function. It means basically that the unmapped area needs to be flushed out of the IOTLBs before iommu_unmap returns. Some time ago I proposed the iommu_commit() interface which changes these requirements. With this interface the requirement is that after a couple of map/unmap operations the IOMMU-API user has to call iommu_commit() to make these changes visible to the hardware (so mostly sync the IOTLBs). As discussed at that time this would make sense for the Intel and AMD IOMMU drivers. What is acceptable, though? That batched unmap is quite important for performance, because it means that we don't have to bash on the hardware and wait for a flush to complete in the fast path of network driver RX, for example. Have you considered a round-robin bitmap-allocator? It allows quite nice flushing behavior. If we move to a model where we have a separate -flush_iotlb() call, we need to be careful that we still allow necessary optimisations to happen. With iommu_commit() this should be possible, still. I'm looking at fixing performance issues in the Intel IOMMU code, with its virtual address space allocation (the rbtree-based one in iova.c that nobody else uses, which has a single spinlock that *all* CPUs bash on when they need to allocate). The plan is, vaguely, to allocate large chunks of space to each CPU, and then for each CPU to allocate from its own region first, thus ensuring that the common case doesn't bounce locks between CPUs. It'll be rare for one CPU to have to touch a subregion 'belonging' to another CPU, so lock contention should be drastically reduced. Thats an interesting issue. It exists on the AMD IOMMU side too, the bitmap-allocator runs in a per-domain spinlock which can get high contention. I am not sure how per-cpu chunks of the address space scale to large numbers of cpus, though, given that some devices only have a small address range that they can address. I have been thinking about some lockless algorithms for the bitmap-allocator. But the ideas are not finalized yet, so I still don't know if they will work out at all :) The basic idea builds around the fact, that most allocations using the DMA-API fit into one page. So probably we can split the address-space into a region for one-page allocations which can be accessed without locks and another region for larger allocations which still need locks. Should I be planning to drop the DMA API support from intel-iommu.c completely, and have the new allocator just call into the IOMMU API functions instead? Other people have been looking at that, haven't they? Yes, Marek Szyprowski from the ARM side is looking into this already, but his patches are very ARM specific and not suitable for x86 yet. Is there any code? Or special platform-specific requirements for such a generic wrapper that I might not have thought of? Details about when to flush the IOTLB are one such thing which might need special handling for certain hardware... The plan is to have a single DMA-API implementation for all IOMMU drivers (X86 and ARM) which just uses the IOMMU-API. But to make this performing reasonalbly well a few changes to the IOMMU-API are required. I already have some ideas which we can discuss if you want. 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
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 07:28:39PM +, David Woodhouse wrote: ... which implies that a mapping, once made, might *never* actually get torn down until we loop and start reusing address space? That has interesting security implications. Yes, it is a trade-off between security and performance. But if the user wants more security the unmap_flush parameter can be used. Is it true even for devices which have been assigned to a VM and then unassigned? No, this is only used in the DMA-API path. The device-assignment code uses the IOMMU-API directly. There the IOTLB is always flushed on unmap. There is something similar on the AMD IOMMU side. There it is called unmap_flush. OK, so that definitely wants consolidating into a generic option. Agreed. Some time ago I proposed the iommu_commit() interface which changes these requirements. With this interface the requirement is that after a couple of map/unmap operations the IOMMU-API user has to call iommu_commit() to make these changes visible to the hardware (so mostly sync the IOTLBs). As discussed at that time this would make sense for the Intel and AMD IOMMU drivers. I would *really* want to keep those off the fast path (thinking mostly about DMA API here, since that's the performance issue). But as long as we can achieve that, that's fine. For AMD IOMMU there is a feature called not-present cache. It says that the IOMMU caches non-present entries as well and needs an IOTLB flush when something is mapped (meant for software implementations of the IOMMU). So it can't be really taken out of the fast-path. But the IOMMU driver can optimize the function so that it only flushes the IOTLB when there was an unmap-call before. It is also an improvement over the current situation where every iommu_unmap call results in a flush implicitly. This pretty much a no-go for using IOMMU-API in DMA mapping at the moment. But also, it's not *so* much of an issue to divide the space up even when it's limited. The idea was not to have it *strictly* per-CPU, but just for a CPU to try allocating from its own subrange first, and then fall back to allocating a new subrange, and *then* fall back to allocating from subranges belonging to other CPUs. It's not that the allocation from a subrange would be lockless — it's that the lock would almost never leave the l1 cache of the CPU that *normally* uses that subrange. Yeah, I get the idea. I fear that the memory consumption will get pretty high with that approach. It basically means one round-robin allocator per cpu and device. What does that mean on a 4096 CPU machine :) How much lock contention will be lowered also depends on the work-load. If dma-handles are frequently freed from another cpu than they were allocated from the same problem re-appears. But in the end we have to try it out and see what works best :) 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Changing IOMMU-API for generic DMA-mapping supported by the hardware
Okay, seperate thread for this one. On Thu, Nov 10, 2011 at 07:28:39PM +, David Woodhouse wrote: The plan is to have a single DMA-API implementation for all IOMMU drivers (X86 and ARM) which just uses the IOMMU-API. But to make this performing reasonalbly well a few changes to the IOMMU-API are required. I already have some ideas which we can discuss if you want. Yeah, that sounds useful. As I said some changes to the IOMMU-API are required in my opinion. These changes should also allow it to move over old-style IOMMUs like Calgary or GART later. The basic idea is that IOMMU drivers should be required to put every device they are responsible for into a default domain. The DMA mapping code can query this default domain for each device. Also the default domain has capabilities that can be queried. Those capabilities include the size and offset of the address space they can re-map. For GART and Calgary this will be the aperture, for VT-d and AMD IOMMU the whole 64bit address space. Another capability is whether addresses outside of that area are 1-1 mapped or no accessible to the device. The generic DMA-mapping code will use that information to initialize its allocator and uses iommu_map/iommu_unmap to create and destroy mappings as requested by the DMA-API (but the DMA-mapping code does not need to create a domain of its own). The good thing about these default domains is that IOMMU drivers can implement their own optimizations on it. The AMD IOMMU driver for example already makes a distinction between dma-mapping domains and other protection-domains. The optimization for dma-mapping domains is that the leaf-pages of the page-table are keept in an array so that it is very easy to find the PTE for an address. Those optimizations are still possible with the default-domain concept. In short, the benefits of the default-domain concept are: 1) It allows existing optimizations for the DMA-mapping code paths to persist 2) It also fits old-style IOMMUs like GART, Calgary and others An open problem is how to report reserved ranges of an address-space. These ranges might exist from a BIOS requirement for 1-1 mapping of certain address ranges (in AMD jargon: Unity mapped ranges, something similar exists on VT-d afaik) or hardware requirements like the reserved address range used for MSI interrupts. 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 01:12:00PM -0800, Stepan Moskovchenko wrote: I have been experimenting with an iommu_map_range call, which maps a given scatterlist of discontiguous physical pages into a contiguous virtual region at a given IOVA. This has some performance advantages over just calling iommu_map iteratively. First, it reduces the amount of table walking / calculation needed for mapping each page, given how you know that all the pages will be mapped into a single virtually-contiguous region (so in most cases, the first-level table calculation can be reused). Second, it allows one to defer the TLB (and sometimes cache) maintenance operations until the entire scatterlist has been mapped, rather than doing a TLB invalidate after mapping each page, as would have been the case if iommu_map were just being called from within a loop. Granted, just using iommu_map many times may be acceptable on the slow path, but I have seen significant performance gains when using this approach on the fast path. Yes, from a performance point-of-view that makes sense, as an addition to the existing iommu_map interface. Are the pages in the list allowed to have different page-sizes? 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On Fri, Nov 11, 2011 at 01:27:28PM +, David Woodhouse wrote: On Fri, 2011-11-11 at 13:58 +0100, Joerg Roedel wrote: For AMD IOMMU there is a feature called not-present cache. It says that the IOMMU caches non-present entries as well and needs an IOTLB flush when something is mapped (meant for software implementations of the IOMMU). So it can't be really taken out of the fast-path. But the IOMMU driver can optimize the function so that it only flushes the IOTLB when there was an unmap-call before. We have exactly the same situation with the Intel IOMMU (we call it 'Caching Mode') for the same reasons. I'd be wary about making the IOMMU driver *track* whether there was an unmap call before — that seems like hard work and more cache contention, especially if the -commit() call happens on a CPU other than the one that just did the unmap. Well, the IOMMU driver does not need to track this globally or per-IOMMU. It basically tracks it per-domain. This lowers the cache-bouncing a bit. I'm also not sure exactly when you'd call the -commit() function when the DMA API is being used, and which 'side' of that API the deferred-flush optimisations would live. The commit function is called every time before one of the DMA-API functions return. Would the optimisation be done on the generic side, only calling -commit when it absolutely *has* to happen? (Or periodically after unmaps have happened to avoid entries hanging around for ever?) Or would the optimisation be done in the IOMMU driver, thus turning the -commit() function into more of a *hint*? You could add a 'simon_says' boolean argument to it, I suppose...? The IOMMU driver can't do that because special knowledge about the address allocator is needed. So it has to happen in the generic part. Okay, that optimization does not really work with the -commit() idea, as I think about it. With the requirement to call commit() on the map-side would result in too many flushes to happen. So it may be better to just call it iommu_flush_tlb(domain) or something. The user of the IOMMU-API can assume that the flush is only necessary on the unmap-path. Stricter flushing rules need to be handled in the IOMMU driver itself. It is also an improvement over the current situation where every iommu_unmap call results in a flush implicitly. This pretty much a no-go for using IOMMU-API in DMA mapping at the moment. Right. That definitely needs to be handled. We just need to work out the (above and other) details. Yes, I am convinced now that the commit() idea is not the right solution :) Some less generic semantics like a iommu_flush_tlb call-back would do better with such an optimization. Certainly your concerns are valid, but I think we can cope with them fairly reasonably. If we *do* have large number of CPUs allocating for a given domain, we can move to a per-node rather than per-CPU allocator. And we can have dynamically sized allocation regions, so we aren't wasting too much space on unused bitmaps if you map just *one* page from each of your 4096 CPUs. It also requires somewhat that the chunks are reasonably small. On a typical small system the amount of allocated DMA memory is rather small (GPUs are the exception, of course). Btw, do you have numbers how much time is spent in spinlocks for multi-node machines and the VT-d driver for some workloads? I remember that I did this measurement some time ago on a 24 core AMD machine with netperf on a 10GBit network card and the time spent spinning came out at ~5%. For 1Gbit network and disk-load it was around 0.5% on that machine. How much lock contention will be lowered also depends on the work-load. If dma-handles are frequently freed from another cpu than they were allocated from the same problem re-appears. The idea is that dma handles are *infrequently* freed, in batches. So we'll bounce the lock's cache line occasionally, but not all the time. Hmm, btw, how does this batch-freeing works? Is the freeing done when the address space is filled up or is another approach used? But in the end we have to try it out and see what works best :) Indeed. I'm just trying to work out if I should try to do the allocator thing purely inside the Intel code first, and then try to move it out and make it generic — or if I should start with making the DMA API work with a wrapper around the IOMMU API, with your -commit() and other necessary changes. I think I'd prefer the latter, if we can work out how it should look. I think it is the best to start with a generic DMA-mapping implementation, benchmark it and then find the bottlenecks and try out possible optimizations. In the beginning it is hard enough to come up with an implementation that fits X86 and ARM at the same time. When this is worked out we can continue to optimize :) Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers
Re: [PATCH v4-rebased 0/7] iommu: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 11:32:24AM +0200, Ohad Ben-Cohen wrote: Ohad Ben-Cohen (7): iommu/core: stop converting bytes to page order back and forth iommu/core: split mapping to page sizes as supported by the hardware iommu/omap: announce supported page sizes iommu/msm: announce supported page sizes iommu/amd: announce supported page sizes iommu/intel: announce supported page sizes iommu/core: remove the temporary pgsize settings drivers/iommu/amd_iommu.c | 32 +--- drivers/iommu/intel-iommu.c | 30 --- drivers/iommu/iommu.c | 119 ++ drivers/iommu/msm_iommu.c | 25 - drivers/iommu/omap-iommu.c | 18 +++--- drivers/iommu/omap-iovmm.c | 17 ++ include/linux/iommu.h | 26 +++-- virt/kvm/iommu.c|8 ++-- 8 files changed, 205 insertions(+), 70 deletions(-) Applied, thanks. -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Changing IOMMU-API for generic DMA-mapping supported by the hardware
On Thu, Nov 24, 2011 at 01:52:33PM +0100, Marek Szyprowski wrote: In my DMA-mapping IOMMU integration I've used a dma_iommu_mapping structure, which contains a pointer to iommu domain, a bitmap and a lock. Maybe we should consider extending iommu domain with allocation bitmap (or other structure that hold information about used/unused iova ranges)? From the DMA-mapping (as a IOMMU client) perspective we only need 2 more callbacks in IOMMU API: alloc_iova_range() and free_iova_range(). Each IOMMU implementation can provide these calls based on internal bitmap allocator which will also cover the issue with reserved ranges. What do you think about such solution? Hmm, the main point of a generic DMA-mapping implementation is that a common address-allocator will be used. Today every IOMMU driver that implements the DMA-API has its own allocator, this is something to unify between for all drivers. The allocator information can be stored in the default iommu_domain. We need a user-private pointer there, but that is easy to add. 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote: Omar Ramirez Luna (6): ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected ARM: OMAP3: hwmod data: add mmu data for iva and isp ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP2+: iommu: add reset handling ARM: OMAP3/4: iommu: adapt to runtime pm What happens with this patch-set. Comments anyone? Ohad? 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 -- 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
Re: [PATCH] iommu/core: pass a user-provided token to fault handlers
On Mon, May 21, 2012 at 08:20:05PM +0300, Ohad Ben-Cohen wrote: Sometimes a single IOMMU user may have to deal with several different IOMMU devices (e.g. remoteproc). When an IOMMU fault happens, such users have to regain their context in order to deal with the fault. Users can't use the private fields of neither the iommu_domain nor the IOMMU device, because those are already used by the IOMMU core and low level driver (respectively). This patch just simply allows users to pass a private token (most notably their own context pointer) to iommu_set_fault_handler(), and then makes sure it is provided back to the users whenever an IOMMU fault happens. The patch also adopts remoteproc to the new fault handling interface, but the real functionality using this (recovery of remote processors) will only be added later in a subsequent patch set. Cc: Fernando Guzman Lugo fernando.l...@ti.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com Applied, thanks. -- 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 -- 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
[PATCH 1/2] iommu: Move iommu Kconfig entries to submenu
For better navigation this patch moves the drivers/iommu drivers into its own submenu in Kconfig. Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- drivers/iommu/Kconfig | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index e2a5f14..b57b3fa 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -2,6 +2,17 @@ config IOMMU_API bool +menuconfig IOMMU_SUPPORT + bool IOMMU Hardware Support + default y + ---help--- + Say Y here if you want to compile device drivers for IO Memory + Management Units into the kernel. These devices usually allow to + remap DMA requests and/or remap interrupts from other devices on the + system. + +if IOMMU_SUPPORT + # MSM IOMMU support config MSM_IOMMU bool MSM IOMMU Support @@ -95,3 +106,5 @@ config INTR_REMAP Supports Interrupt remapping for IO-APIC and MSI devices. To use x2apic mode in the CPU's which support x2APIC enhancements or to support platforms with CPU's having 8 bit APIC ID, say Y. + +endif # IOMMU_SUPPORT -- 1.7.4.1 -- 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
[PATCH 2/2] iommu/amd: Move missing parts to drivers/iommu
A few parts of the driver were missing in drivers/iommu.
Move them there to have the complete driver in that
directory.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kernel/Makefile |1 -
drivers/iommu/Makefile |2 +-
drivers/iommu/amd_iommu.c |7 ---
.../x86/kernel = drivers/iommu}/amd_iommu_init.c |8 +---
.../asm = drivers/iommu}/amd_iommu_proto.h|2 +-
.../asm = drivers/iommu}/amd_iommu_types.h|0
.../asm/amd_iommu.h = include/linux/amd-iommu.h |0
7 files changed, 11 insertions(+), 9 deletions(-)
rename {arch/x86/kernel = drivers/iommu}/amd_iommu_init.c (99%)
rename {arch/x86/include/asm = drivers/iommu}/amd_iommu_proto.h (98%)
rename {arch/x86/include/asm = drivers/iommu}/amd_iommu_types.h (100%)
rename arch/x86/include/asm/amd_iommu.h = include/linux/amd-iommu.h (100%)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index aef0298..11817ff 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -123,7 +123,6 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU)+= amd_gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU) += pci-calgary_64.o tce_64.o
- obj-$(CONFIG_AMD_IOMMU) += amd_iommu_init.o
obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o
obj-y += vsmp_64.o
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 49e9c0f..4d4d77d 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_IOMMU_API) += iommu.o
obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o msm_iommu_dev.o
-obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o
+obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o
obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o
obj-$(CONFIG_INTR_REMAP) += dmar.o intr_remapping.o
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 7c3a95e..5aa12ea 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -27,13 +27,14 @@
#include linux/iommu-helper.h
#include linux/iommu.h
#include linux/delay.h
+#include linux/amd-iommu.h
#include asm/proto.h
#include asm/iommu.h
#include asm/gart.h
#include asm/dma.h
-#include asm/amd_iommu_proto.h
-#include asm/amd_iommu_types.h
-#include asm/amd_iommu.h
+
+#include amd_iommu_proto.h
+#include amd_iommu_types.h
#define CMD_SET_TYPE(cmd, t) ((cmd)-data[1] |= ((t) 28))
diff --git a/arch/x86/kernel/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
similarity index 99%
rename from arch/x86/kernel/amd_iommu_init.c
rename to drivers/iommu/amd_iommu_init.c
index bfc8453..82d2410 100644
--- a/arch/x86/kernel/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -24,14 +24,16 @@
#include linux/syscore_ops.h
#include linux/interrupt.h
#include linux/msi.h
+#include linux/amd-iommu.h
#include asm/pci-direct.h
-#include asm/amd_iommu_proto.h
-#include asm/amd_iommu_types.h
-#include asm/amd_iommu.h
#include asm/iommu.h
#include asm/gart.h
#include asm/x86_init.h
#include asm/iommu_table.h
+
+#include amd_iommu_proto.h
+#include amd_iommu_types.h
+
/*
* definitions for the ACPI scanning code
*/
diff --git a/arch/x86/include/asm/amd_iommu_proto.h
b/drivers/iommu/amd_iommu_proto.h
similarity index 98%
rename from arch/x86/include/asm/amd_iommu_proto.h
rename to drivers/iommu/amd_iommu_proto.h
index 55d95eb..7ffaa64 100644
--- a/arch/x86/include/asm/amd_iommu_proto.h
+++ b/drivers/iommu/amd_iommu_proto.h
@@ -19,7 +19,7 @@
#ifndef _ASM_X86_AMD_IOMMU_PROTO_H
#define _ASM_X86_AMD_IOMMU_PROTO_H
-#include asm/amd_iommu_types.h
+#include amd_iommu_types.h
extern int amd_iommu_init_dma_ops(void);
extern int amd_iommu_init_passthrough(void);
diff --git a/arch/x86/include/asm/amd_iommu_types.h
b/drivers/iommu/amd_iommu_types.h
similarity index 100%
rename from arch/x86/include/asm/amd_iommu_types.h
rename to drivers/iommu/amd_iommu_types.h
diff --git a/arch/x86/include/asm/amd_iommu.h b/include/linux/amd-iommu.h
similarity index 100%
rename from arch/x86/include/asm/amd_iommu.h
rename to include/linux/amd-iommu.h
--
1.7.4.1
--
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
Re: [PATCH v2 0/4] drivers/iommu/ relocations
Okay, I applied the patches to move forward with them. On-top I also put two additional patches which are sent as a follow-up to this mail. These changes are at git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git in the core branch. Thanks, Joerg -- 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
Re: [PATCH v2 2/2] iommu/omap: fix NULL pointer dereference
I guess these patches are 3.3 material? How about tagging them for
stable too?
On Wed, Feb 22, 2012 at 11:14:46AM +0200, Ohad Ben-Cohen wrote:
Fix this:
root@omap4430-panda:~# cat /debug/iommu/ducati/mem
[ 62.725708] Unable to handle kernel NULL pointer dereference at virtual
addre
ss 001c
[ 62.725708] pgd = e624
[ 62.737091] [001c] *pgd=a7168831, *pte=, *ppte=
[ 62.743682] Internal error: Oops: 17 [#1] SMP
[ 62.743682] Modules linked in: omap_iommu_debug omap_iovmm
virtio_rpmsg_bus o
map_remoteproc remoteproc virtio_ring virtio mailbox_mach mailbox
[ 62.743682] CPU: 0Not tainted (3.3.0-rc1-00265-g382f84e-dirty #682)
[ 62.743682] PC is at debug_read_mem+0x5c/0xac [omap_iommu_debug]
[ 62.743682] LR is at 0x1004
[ 62.777832] pc : [bf033178]lr : [1004]psr: 6013
[ 62.777832] sp : e72c7f40 ip : c0763c00 fp : 0001
[ 62.777832] r10: r9 : r8 : e72c7f80
[ 62.777832] r7 : e6ffdc08 r6 : bed1ac78 r5 : 1000 r4 : e7276000
[ 62.777832] r3 : e60f3460 r2 : r1 : e60f38c0 r0 :
[ 62.777832] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
user
[ 62.816375] Control: 10c53c7d Table: a624004a DAC: 0015
[ 62.816375] Process cat (pid: 1176, stack limit = 0xe72c62f8)
[ 62.828369] Stack: (0xe72c7f40 to 0xe72c8000)
...
[ 62.884185] [bf033178] (debug_read_mem+0x5c/0xac [omap_iommu_debug])
from [
c010e354] (vfs_read+0xac/0x130)
[ 62.884185] [c010e354] (vfs_read+0xac/0x130) from [c010e4a8]
(sys_read+0x
40/0x70)
[ 62.884185] [c010e4a8] (sys_read+0x40/0x70) from [c0014a00]
(ret_fast_sys
call+0x0/0x3c)
Fix also its 'echo bla /debug/iommu/ducati/mem' Oops sibling, too.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Tony Lindgren t...@atomide.com
Cc: Hiroshi Doyu hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Joerg Roedel joerg.roe...@amd.com
---
v2: omap_find_iovm_area only returns NULL for errors. thanks, rmk.
drivers/iommu/omap-iommu-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c
index bad9f9d..103dbd9 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -274,7 +274,7 @@ static ssize_t debug_read_mem(struct file *file, char
__user *userbuf,
mutex_lock(iommu_debug_lock);
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (!area) {
bytes = -EINVAL;
goto err_out;
}
@@ -311,7 +311,7 @@ static ssize_t debug_write_mem(struct file *file, const
char __user *userbuf,
}
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (!area) {
count = -EINVAL;
goto err_out;
}
--
1.7.5.4
--
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
--
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
Re: [PATCH v2 2/2] iommu/omap: fix NULL pointer dereference
On Thu, Feb 23, 2012 at 06:16:59PM +0200, Ohad Ben-Cohen wrote: On Thu, Feb 23, 2012 at 6:11 PM, Joerg Roedel joerg.roe...@amd.com wrote: I guess these patches are 3.3 material? Yes. How about tagging them for stable too? Good point. But it's only relevant for this 2nd patch (the NULL pointer dereference fix), as the first one is a 3.3 regression. Let me know if you want me to resend the 2nd one with the stable tag. Not necessary. I'll add it when I apply the patch. Thanks, 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 -- 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
Re: [PATCH v2 2/2] iommu/omap: fix NULL pointer dereference
On Thu, Feb 23, 2012 at 06:16:59PM +0200, Ohad Ben-Cohen wrote: On Thu, Feb 23, 2012 at 6:11 PM, Joerg Roedel joerg.roe...@amd.com wrote: I guess these patches are 3.3 material? Yes. How about tagging them for stable too? Good point. But it's only relevant for this 2nd patch (the NULL pointer dereference fix), as the first one is a 3.3 regression. Let me know if you want me to resend the 2nd one with the stable tag. Applied both and added stable-tag to the second patch. I'll send the pull-request when you guys also send me the correct fix for the outstanding initialization order issue on OMAP. 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 -- 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
Re: [PATCH] ARM: OMAP: fix iommu, not mailbox
On Sun, Mar 04, 2012 at 12:01:11PM +0200, Ohad Ben-Cohen wrote: For some weird (freudian?) reason, commit 435792d ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp unintentionally changed the mailbox's initcall instead of the iommu's. Fix that. Applied, thanks. -- 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 -- 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
Re: [PATCH] iommu: OMAP: device detach on domain destroy
On Fri, Mar 30, 2012 at 11:03:49AM -0500, Omar Ramirez Luna wrote: 'domain_destroy with devices attached' case isn't yet handled, instead code assumes that the device was already detached. If the domain is destroyed the hardware still has access to invalid pointers to its page table and internal iommu object. In order to detach the users we need to track devices using the iommu, current use cases only have one user of iommu per instance. When required this can evolve to a list with the devices using the iommu_dev. Reported-by: Joerg Roedel j...@8bytes.org Reviewed-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org Doesn't apply against 3.4-rc2. Please rebase and send a new version. 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 -- 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
Re: [PATCH v2] iommu: OMAP: device detach on domain destroy
On Wed, Apr 18, 2012 at 01:09:41PM -0500, Omar Ramirez Luna wrote: 'domain_destroy with devices attached' case isn't yet handled, instead code assumes that the device was already detached. If the domain is destroyed the hardware still has access to invalid pointers to its page table and internal iommu object. In order to detach the users we need to track devices using the iommu, current use cases only have one user of iommu per instance. When required this can evolve to a list with the devices using the iommu_dev. Reported-by: Joerg Roedel j...@8bytes.org Reviewed-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org --- v2: rebased onto v3.4-rc2 Applied, thanks. -- 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 -- 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
Re: [PATCH] ARM: OMAP3: fix build on !CONFIG_IOMMU_API
On Wed, Jan 11, 2012 at 03:28:11PM +0200, Ohad Ben-Cohen wrote: omap3isp depends on CONFIG_IOMMU_API, so avoid registering its device (and defining its configuration structs) on !CONFIG_IOMMU_API. This is generally nice to have, but more importantly, it fixes: arch/arm/plat-omap/include/plat/iommu.h: In function 'dev_to_omap_iommu': arch/arm/plat-omap/include/plat/iommu.h:135: error: 'struct dev_archdata' has no member named 'iommu' arch/arm/mach-omap2/devices.c: In function 'omap3_init_camera': arch/arm/mach-omap2/devices.c:222: error: 'struct dev_archdata' has no member named 'iommu' make[1]: *** [arch/arm/mach-omap2/devices.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Will apply it as soon as the merge window closes. 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 -- 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
Re: [PATCH] ARM: OMAP3: fix build on !CONFIG_IOMMU_API
On Fri, Jan 13, 2012 at 05:54:10PM +0200, Ohad Ben-Cohen wrote: On Fri, Jan 13, 2012 at 1:07 PM, Joerg Roedel joerg.roe...@amd.com wrote: Will apply it as soon as the merge window closes. Though we might want to consider sending this to Linus before rc1, to eliminate global developers' pain as much as possible :) Okay, so I will send out the fix early next week :) 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 -- 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
Re: [PATCH] ARM: OMAP3: fix build on !CONFIG_IOMMU_API
On Wed, Jan 11, 2012 at 03:28:11PM +0200, Ohad Ben-Cohen wrote: omap3isp depends on CONFIG_IOMMU_API, so avoid registering its device (and defining its configuration structs) on !CONFIG_IOMMU_API. This is generally nice to have, but more importantly, it fixes: arch/arm/plat-omap/include/plat/iommu.h: In function 'dev_to_omap_iommu': arch/arm/plat-omap/include/plat/iommu.h:135: error: 'struct dev_archdata' has no member named 'iommu' arch/arm/mach-omap2/devices.c: In function 'omap3_init_camera': arch/arm/mach-omap2/devices.c:222: error: 'struct dev_archdata' has no member named 'iommu' make[1]: *** [arch/arm/mach-omap2/devices.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Which happens because while setting up the omap3isp device we try to access the (now nonexistent) iommu member of dev_archdata. Compile tested with omap2plus_defconfig on today's: Applied. Will send pull-request soon. -- 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 -- 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
Re: [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
On Mon, Nov 12, 2012 at 02:00:34PM -0800, Tony Lindgren wrote: Assuming Joerg is OK with these changes, I can push them into an immutable branch that Joerg can merge in as needed. Further patches on top of this series can then be queued by Joerg as arch/arm/*omap* and me are then out of the way of iommu development. Okay, from my side: Acked-by: Joerg Roedel j...@8bytes.org Please let me know which branch I need to pull into my tree when you merged these patches. Joerg -- 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
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. These two levels exist in the form of the DMA-API and the IOMMU-API. In fact, the IOMMU-API was created to provide a way to drivers to specifiy the IOVA-PHYS mappings on its own. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed ? The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA-API anymore then). Joerg -- 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
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Laurent, On Tue, Apr 08, 2014 at 02:50:38PM +0200, Laurent Pinchart wrote: I agree with you, the two levels are already present, but there's still rough edges that we need to soften. The ARM DMA API implementation requires someone to create the VA space mapping by calling arm_iommu_create_mapping() and attach devices to mappings by calling arm_iommu_attach_device(). Who is someone in this case? This must only be performed for devices that use the DMA API, devices that manage their IOMMU directly will call to the IOMMU API directly. One obvious possibility is to call those functions in the IOMMU bus masters device drivers. This is pretty easy, but makes the drivers IOMMU-aware (which I'd like to avoid) and doesn't allow multiple bus masters to share a VA space mapping. Another possibility is to place the calls in the IOMMU drivers. This has the advantage of removing any IOMMU knowledge from bus masters device drivers and allowing multiple bus masters per IOMMU, but makes IOMMU management by the DMA API unconditional. Why does that make IOMMU management by the DMA API unconditional? On x86 it works this way: The IOMMU drivers create DMA-API mappings for the devices by default. So any driver can use the DMA-API just out-of-the-box without being aware of an IOMMU. If the driver wants to deal with the IOMMU directly, it creates its own iommu-domain and attaches the device to it. The device uses the drivers domain then and not the DMA-API domain setup by the IOMMU driver. On iommu-detach the device is assigned back to its DMA-API domain. The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA-API anymore then). Are drivers supposed to reimplement the DMA API internally in that case? Usually not, but possible. Device drivers use the IOMMU-API when they want to control the io-addresses themselves. This is the case for VFIO for example, where a given range from a process address space is mapped into a device address space. In those cases the device driver usally does not need to implement its own address allocator. Regards, Joerg -- 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
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
On Tue, Apr 08, 2014 at 05:02:37PM +0200, Laurent Pinchart wrote: On Tuesday 08 April 2014 15:43:22 Joerg Roedel wrote: Who is someone in this case? That's exactly the problem :-) The ARM DMA API implementation doesn't care who that someone is. Existing implementations call those functions either from the bus masters device drivers (in which case the drivers need to be IOMMU- aware, even if they use the DMA API and don't need to handle the IOMMU directly) or from the IOMMU drivers (in which case the bus masters device drivers don't have to care about the IOMMU, but without a way for drivers to handle the IOMMU directly when they need to). Possible other candidates are core IOMMU code or bus code. That doesn't sound very transparent for the device drivers. All what you describe above (attaching a device to its default domain for DMA-API) should happen in the IOMMU driver. For the device driver it should make no difference if there is an IOMMU or not. If we call arm_iommu_attach_device() from the IOMMU driver to get default transparent IOMMU handling, the function will then attach the device to the default domain with a call to iommu_attach_device(). If you have to call a function it is not transparent anymore. If a driver needs to handle the IOMMU directly, should it start by detaching the device from the ARM IOMMU domain ? We would need to be very careful with the assumptions made by the different layers, as they might not support a driver attaching a new domain to a device that already has a domain attached. I'd feel more comfortable with avoiding to attach the default domain to the device in the first place, but that might not be easily doable. The way this is solved by others is that iommu_attach_device() automatically detaches the device from its default (DMA-API) domain and attach it to the device drivers own domain. On iommu_detach_device() the device is attached back to the default domain. Joerg -- 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
Re: [GIT PULL FOR v3.16] OMAP IOMMU fixes
Hi Laurent, On Fri, Apr 04, 2014 at 12:11:52AM +0200, Laurent Pinchart wrote: Laurent Pinchart (3): iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() iommu/omap: Remove comment about supporting single page mappings only iommu/omap: Fix map protection value handling Suman Anna (3): iommu/omap: Correct init value of iotlb_entry valid field iommu/omap: Remove omap_iommu_domain_has_cap() function iommu/omap: Move to_iommu definition from omap-iopgtable.h drivers/iommu/omap-iommu.c | 31 --- drivers/iommu/omap-iopgtable.h | 3 --- 2 files changed, 12 insertions(+), 22 deletions(-) Can you please rebase this to v3.15-rc1 and send a new pull request? I get a lot of commits besides these when I pull into v3.15-rc1. Joerg -- 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
Re: [GIT PULL v2 FOR v3.16] OMAP IOMMU fixes
On Wed, Apr 16, 2014 at 04:51:56PM +0200, Laurent Pinchart wrote: The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://linuxtv.org/pinchartl/media.git iommu/omap for you to fetch changes up to 286f600bc890347f7ec7bd50d33210d53a9095a3: iommu/omap: Fix map protection value handling (2014-04-16 16:30:18 +0200) Compared to the v1 pull request, the patches have been rebased directly on top of v3.15-rc1. Laurent Pinchart (3): iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() iommu/omap: Remove comment about supporting single page mappings only iommu/omap: Fix map protection value handling Suman Anna (3): iommu/omap: Correct init value of iotlb_entry valid field iommu/omap: Remove omap_iommu_domain_has_cap() function iommu/omap: Move to_iommu definition from omap-iopgtable.h drivers/iommu/omap-iommu.c | 31 --- drivers/iommu/omap-iopgtable.h | 3 --- 2 files changed, 12 insertions(+), 22 deletions(-) Pulled, thanks Laurent. You can use the arm/omap branch to base your work on (when I pushed it, which will probably happen tomorrow). Joerg -- 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
Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
On Mon, Jul 21, 2014 at 11:19:29PM -0700, Tony Lindgren wrote: Tony, is there still time to get this (and especially patch 2/3, which touches arch/ code) in v3.17 ? Yes as long as Joerg is OK to merge that branch in :) Fine with me, I can take only patch 1 or all 3 into my arm/omap branch, given Tony's Acked-by. Then you guys can merge in this branch wherever you want :) Cheers, Joerg -- 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
Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
On Wed, Jul 23, 2014 at 04:00:47PM +0200, Laurent Pinchart wrote: Thank you. Assuming there's currently no conflict to be resolved, I believe the easiest would be for both you and Tony to merge my branch in your trees. Okay, I applied the patches to my arm/omap branch. I will push them out today. Joerg -- 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
Re: [PATCHv2 0/2] OMAP IOMMU Fixes for DT-clients
On Thu, Sep 04, 2014 at 05:27:28PM -0500, Suman Anna wrote: Suman Anna (2): iommu/omap: Check for valid archdata in attach_dev iommu/omap: Fix iommu archdata name for DT-based devices drivers/iommu/omap-iommu.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) Applied, thanks. -- 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
Re: [PATCH 2/2] iommu/omap: Remove omap_iommu unused owner field
On Tue, Sep 09, 2014 at 06:45:45PM +0300, Laurent Pinchart wrote: The owner field is never set. Remove it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/iommu/omap-iommu.c | 11 --- drivers/iommu/omap-iommu.h | 1 - 2 files changed, 12 deletions(-) Applied this one to arm/omap, thanks. -- 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
Re: [PATCH 12/17] iommu/omap: Integrate omap-iommu-debug into omap-iommu
On Tue, Oct 21, 2014 at 04:28:27PM -0500, Suman Anna wrote: I am looking to refresh this series for 3.19, and this is the only patch that may need some changes. Please let me know what your preference is, and I can rework this patch if needed. Either way, the plan is to not have an OMAP IOMMU debugfs module, but only to have an option not to build the debugfs portions. Can I apply this series without this patch and you send me an updated version of only this patch? If yes, please let me know, otherwise please rebase the series on v3.18-rc1 and resend. Thanks, Joerg -- 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
Re: [PATCH v2 00/17] OMAP IOMMU Cleanup Consolidation
On Wed, Oct 22, 2014 at 05:22:18PM -0500, Suman Anna wrote: Suman Anna (17): iommu/omap: Remove refcount field from omap_iommu object iommu/omap: Remove unused isr_priv field from omap_iommu iommu/omap: Remove duplicate declarations iommu/omap: Remove conditional definition of dev_to_omap_iommu() iommu/omap: Remove ver debugfs entry iommu/omap: Remove omap_iommu_arch_version() and version field iommu/omap: Remove bogus version check in context save/restore iommu/omap: Simplify omap2_iommu_fault_isr() iommu/omap: Consolidate OMAP IOMMU modules iommu/omap: Fix the permissions on nr_tlb_entries iommu/omap: Make pagetable debugfs entry read-only iommu/omap: Integrate omap-iommu-debug into omap-iommu iommu/omap: Remove couple of unused exported functions iommu/omap: Do not export unneeded functions iommu/omap: Reset the domain field upon detaching iommu/omap: Fix bus error on debugfs access of unattached IOMMU iommu/omap: Switch pagetable debugfs entry to use seq_file drivers/iommu/Kconfig| 12 +- drivers/iommu/Makefile | 1 - drivers/iommu/omap-iommu-debug.c | 242 drivers/iommu/omap-iommu.c | 306 ++- drivers/iommu/omap-iommu.h | 98 ++-- drivers/iommu/omap-iommu2.c | 337 --- 6 files changed, 312 insertions(+), 684 deletions(-) delete mode 100644 drivers/iommu/omap-iommu2.c Applied to arm/omap, thanks Suman. -- 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
Re: [PATCH 0/2] DRA7 DSP MMU config support
On Tue, Jul 21, 2015 at 06:55:34PM -0500, Suman Anna wrote: The patches are baselined on 4.2-rc3 + the recent OMAP IOMMU cleanup series [1]. I will post the DTS patches separately to allow Tony to pick them up independently. From the discussion it looks like some more work is necessary here. Before you repost, please also test on older omap hardware to make sure nothing breaks there. Please also describe the testing you did in the repost. Joerg -- 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
Re: [PATCH 00/11] Some OMAP IOMMU cleanup patches
On Mon, Jul 20, 2015 at 05:33:22PM -0500, Suman Anna wrote: Suman Anna (11): Documentation: dt: Add #iommu-cells info to OMAP iommu bindings iommu/omap: Remove all module references iommu/omap: Move debugfs functions to omap-iommu-debug.c iommu/omap: Protect omap-iopgtable.h against double inclusion iommu/omap: Remove unused union fields iommu/omap: Remove trailing semi-colon from a macro iommu/omap: Remove unnecessary error traces on alloc failures iommu/omap: Use BIT(x) macros in omap-iopgtable.h iommu/omap: Use BIT(x) macros in omap-iommu.h iommu/omap: Align code with open parenthesis Applied these patches to arm/omap. iommu/omap: Split multiple assignments into separate lines Did not apply this one, there is nothing wrong with multiple assignments. Joerg -- 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
Re: next-20150806 build: 2 failures 52 warnings (next-20150806)
On Thu, Aug 06, 2015 at 07:01:56PM +0100, Mark Brown wrote: On Thu, Aug 06, 2015 at 12:00:47PM +0100, Build bot for Mark Brown wrote: Today's linux-next fails to build an ARM allmodconfig with: ../drivers/iommu/omap-iommu-debug.c:138:2: error: void value not ignored as it ought to be caused by a combination of 1ba2f20ac (fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void) which made seq_printf() return void and e203db293863fa15 (iommu/omap: Fix debug_read_tlb() to use seq_printf()) which has been in -next for a little while now. Whoops. Thanks for the report, I'll fix it tomorrow. Joerg -- 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
Re: [REPOST PATCH 0/2] DRA7 DSP MMU config support
On Fri, Oct 02, 2015 at 06:02:42PM -0500, Suman Anna wrote: > Suman Anna (2): > Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs > iommu/omap: Add support for configuring dsp iommus on DRA7xx > > .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++ > drivers/iommu/omap-iommu.c | 58 > ++ > drivers/iommu/omap-iommu.h | 9 > 3 files changed, 94 insertions(+) Applied, thanks. -- 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
