avoid issues of two modules managing mmu data/irqs/resets;
this until tidspbridge can be safely migrated to iommu framework.
Omar Ramirez Luna (4):
OMAP3: hwmod data: add mmu data for iva and isp
OMAP4: hwmod data: add mmu hwmod for ipu and dsp
OMAP3/4: iommu: migrate to hwmod framework
Add mmu hwmod data for iva and isp.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 131
arch/arm/plat-omap/include/plat/iommu.h| 13 +++
2 files changed, 144 insertions(+), 0 deletions(-)
diff --git
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 154 +--
1 files changed, 142 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm
device and resource data, handling
of sysconfig register for softreset purposes; and add device
latency in preparation for runtime PM.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 163
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations, reset and sysconfig
handling.
Tidspbridge uses a macro removed with this patch, for now the value
is hardcoded to avoid breaking compilation.
Signed-off-by: Omar Ramirez Luna omar.rami
Hi,
On 26 October 2012 13:00, Tony Lindgren t...@atomide.com wrote:
...
I would also like to move the tidspbridge to the DMA API, but I think we'll
need to move step by step there, and using the OMAP IOMMU and IOVMM APIs
as an
intermediate step would allow splitting patches in reviewable
