login
Search
Now these functions only map user space addresses to dsp virtual addresses, so now the functions have a more meaningful name Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com> --- arch/arm/plat-omap/include/dspbridge/dspdefs.h | 44 -------------------- drivers/dsp/bridge/core/_tiomap.h | 25 +++++++++++ drivers/dsp/bridge/core/tiomap3430.c | 52 ++++++++++-------------- drivers/dsp/bridge/pmgr/dev.c | 2 - drivers/dsp/bridge/rmgr/proc.c | 12 +++-- 5 files changed, 53 insertions(+), 82 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/dspdefs.h b/arch/arm/plat-omap/include/dspbridge/dspdefs.h index 493f62e..4f56ae6 100644 --- a/arch/arm/plat-omap/include/dspbridge/dspdefs.h +++ b/arch/arm/plat-omap/include/dspbridge/dspdefs.h @@ -162,48 +162,6 @@ typedef int(*fxn_brd_memwrite) (struct bridge_dev_context u32 ulMemType); /* - * ======== bridge_brd_mem_map ======== - * Purpose: - * Map a MPU memory region to a DSP/IVA memory space - * Parameters: - * hDevContext: Handle to Bridge driver defined device info. - * ul_mpu_addr: MPU memory region start address. - * ulVirtAddr: DSP/IVA memory region u8 address. - * ul_num_bytes: Number of bytes to map. - * map_attrs: Mapping attributes (e.g. endianness). - * Returns: - * 0: Success. - * -EPERM: Other, unspecified error. - * Requires: - * hDevContext != NULL; - * Ensures: - */ -typedef int(*fxn_brd_memmap) (struct bridge_dev_context - * hDevContext, u32 ul_mpu_addr, - u32 ulVirtAddr, u32 ul_num_bytes, - u32 ulMapAttrs, - struct page **mapped_pages); - -/* - * ======== bridge_brd_mem_un_map ======== - * Purpose: - * UnMap an MPU memory region from DSP/IVA memory space - * Parameters: - * hDevContext: Handle to Bridge driver defined device info. - * ulVirtAddr: DSP/IVA memory region ...
this patch cleans up cfg_hostres and bridge_dev_context
structures of custom mmu code not needed anymore.
Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
---
arch/arm/plat-omap/include/dspbridge/cfgdefs.h | 1 -
drivers/dsp/bridge/core/_tiomap.h | 5 -----
drivers/dsp/bridge/core/tiomap3430.c | 8 --------
drivers/dsp/bridge/core/tiomap_io.c | 2 +-
drivers/dsp/bridge/rmgr/drv.c | 4 ----
5 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
index 38122db..dfb55cc 100644
--- a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
@@ -68,7 +68,6 @@ struct cfg_hostres {
void __iomem *dw_per_base;
u32 dw_per_pm_base;
u32 dw_core_pm_base;
- void __iomem *dw_dmmu_base;
void __iomem *dw_sys_ctrl_base;
};
diff --git a/drivers/dsp/bridge/core/_tiomap.h b/drivers/dsp/bridge/core/_tiomap.h
index 8a9a822..82bce7d 100644
--- a/drivers/dsp/bridge/core/_tiomap.h
+++ b/drivers/dsp/bridge/core/_tiomap.h
@@ -323,7 +323,6 @@ struct bridge_dev_context {
*/
u32 dw_dsp_ext_base_addr; /* See the comment above */
u32 dw_api_reg_base; /* API mem map'd registers */
- void __iomem *dw_dsp_mmu_base; /* DSP MMU Mapped registers */
u32 dw_api_clk_base; /* CLK Registers */
u32 dw_dsp_clk_m2_base; /* DSP Clock Module m2 */
u32 dw_public_rhea; /* Pub Rhea */
@@ -347,10 +346,6 @@ struct bridge_dev_context {
/* DMMU TLB entries */
struct bridge_ioctl_extproc atlb_entry[BRDIOCTL_NUMOFMMUTLB];
u32 dw_brd_state; /* Last known board state. */
- u32 ul_int_mask; /* int mask */
- u16 io_base; /* Board I/O base */
- u32 num_tlb_entries; /* DSP MMU TLB entry counter */
- u32 fixed_tlb_entries; /* Fixed DSPMMU TLB entry count */
/* TC Settings */
bool tc_word_swap_on; /* Traffic Controller Word Swap */
diff --git ...This patch moves all the code related to iommu in the dsp-mmu.c file Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com> --- arch/arm/plat-omap/include/dspbridge/dsp-mmu.h | 90 ++++++++++ arch/arm/plat-omap/include/dspbridge/dspdeh.h | 1 - drivers/dsp/bridge/Makefile | 2 +- drivers/dsp/bridge/core/_deh.h | 3 - drivers/dsp/bridge/core/_tiomap.h | 41 +----- drivers/dsp/bridge/core/dsp-mmu.c | 218 ++++++++++++++++++++++++ drivers/dsp/bridge/core/mmu_fault.c | 76 -------- drivers/dsp/bridge/core/mmu_fault.h | 35 ---- drivers/dsp/bridge/core/tiomap3430.c | 111 +------------ drivers/dsp/bridge/core/ue_deh.c | 68 +------- drivers/dsp/bridge/rmgr/proc.c | 6 +- 11 files changed, 318 insertions(+), 333 deletions(-) create mode 100644 arch/arm/plat-omap/include/dspbridge/dsp-mmu.h create mode 100644 drivers/dsp/bridge/core/dsp-mmu.c delete mode 100644 drivers/dsp/bridge/core/mmu_fault.c delete mode 100644 drivers/dsp/bridge/core/mmu_fault.h diff --git a/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h b/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h new file mode 100644 index 0000000..266f38b --- /dev/null +++ b/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h @@ -0,0 +1,90 @@ +/* + * dsp-mmu.h + * + * DSP-BIOS Bridge driver support functions for TI OMAP processors. + * + * DSP iommu. + * + * Copyright (C) 2005-2010 Texas Instruments, Inc. + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +#ifndef _DSP_MMU_ +#define _DSP_MMU_ + +#include ...
due to a restriction in scatter gather lists, it can
not be created a list for a buffer bigger than 1MB.
This patch is spliting big mappings into 1MB mappings.
Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
---
arch/arm/plat-omap/include/dspbridge/dsp-mmu.h | 2 +-
drivers/dsp/bridge/core/dsp-mmu.c | 55 ++++++++++++++---------
drivers/dsp/bridge/rmgr/proc.c | 3 +-
3 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h b/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h
index 266f38b..2e4bf6a 100644
--- a/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h
+++ b/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h
@@ -85,6 +85,6 @@ int user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32 size,
* This function unmaps a user space buffer into DSP virtual address.
*
*/
-int user_to_dsp_unmap(struct iommu *mmu, u32 da);
+int user_to_dsp_unmap(struct iommu *mmu, u32 da, unsigned size);
#endif
diff --git a/drivers/dsp/bridge/core/dsp-mmu.c b/drivers/dsp/bridge/core/dsp-mmu.c
index e8da327..9a46206 100644
--- a/drivers/dsp/bridge/core/dsp-mmu.c
+++ b/drivers/dsp/bridge/core/dsp-mmu.c
@@ -133,7 +133,7 @@ int user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32 size,
struct page **usr_pgs)
{
int res, w;
- unsigned pages, i;
+ unsigned pages, i, j = 0;
struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
struct sg_table *sgt;
@@ -162,24 +162,31 @@ int user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32 size,
if (res < 0)
return res;
- sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ while (pages) {
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
- if (!sgt)
- return -ENOMEM;
+ if (!sgt)
+ return -ENOMEM;
- res = sg_alloc_table(sgt, pages, GFP_KERNEL);
+ res = sg_alloc_table(sgt,
+ min((unsigned)SG_MAX_SINGLE_ALLOC, pages), GFP_KERNEL);
+ pages -= min((unsigned)SG_MAX_SINGLE_ALLOC, pages);
- if (res < 0)
- goto ...-- iommu_vmap does the Kernel mapping to the buffers you are mapping to DSP MMU. Why do you need Kernel mappings ? If there is no benefit in maintaining Kernel mapping I would rather call iopgtable_store_entry directly to map the entries. Thank you, Best regards, Hari --
Where inside iommu_vmap is the mapping done? I thought the kernel can access to that buffer after get_user_pages() where the user pages are pin and we can get a kernel address. The intention using iommu_vmap was to use api's proved by the iovmmu module. iommu_vmap() it is also tracking the mapped areas, so maybe the next step could be: remove dmm.c/h files and also proc_reserve/unreserved functions. If you think the function is unneeded steps and could affect the performance I can do the change to use only iopgtable_store_entry(). I think a kernel mapping is needed for flush/invalidate api's, please correct me if I am wrong. Regards, --
-- The mapping is done to track down the Device mappings. But since you already have it in dmm.c this is kind of redundant right now, and we might see performance impact due to this. I think it might be good to transition to iovmm when we phase out dmm.c. Few things to take into account transitioning to iovmm approach: - DSPBridge used to have linked list approach to track down the mapped entries and profiling showed it took considerable amount of traversing through the list. Jeff Taylor's algorithm in dmm.c helped to reduce this impact. - How would you manage the Device virtual pool moving to iovmm ? And how about the reservation ? Thank you, Best regards, Hari --
I think, it would be good if we get rid of DMMPOOL size, if the liked list grow up as it is needed, there is no memory penalty of have all the possible iommu addresses valid (11000000 - FFFFFFFF). The reservation will only fail when there is no memory. If a software restriction is needed we could define a start and end addresses for iommu module (maybe as a parameter when the iommu handle for iva2 is got) and that boundaries can be taking in account at the moment of reserve the memory. I think the reserve/unreserved dspbridge api can disappear and just return the da address in the map function. Please let me know what you think. Thanks for the comments, --
On Fri, Jul 2, 2010 at 9:39 PM, Guzman Lugo, Fernando What happened to this? IIUC what you are proposing is to remove the DMM pool completely, that makes sense to me. However, is it really needed to finish the iommu This is something I've proposed before, so I agree :) -- Felipe Contreras --
Yeah, that is how it will be. I have been busy with other stuffs, but now I have finish a version with all dmm module removed and reserve/unreserve Api removed as well. But because a the big # of patches merge in dspbrdge I have to rebase them to the latest, I hope finish this week and send Them again next week. Regards,
On Tue, Aug 24, 2010 at 7:31 PM, Guzman Lugo, Fernando Awesome :) However, I still have the question about the dependency on iommu; AFAICS the DMM removal doesn't depend on the migration to iommu, which AFAIK has been stalled for some time. -- Felipe Contreras --
Yeah, DMM removal does not depend on iommu migration. However, After the changes for iommu migration the DMM module is not Needed anymore, so it is better to remove it too. Regards,
On Tue, Aug 24, 2010 at 9:44 PM, Guzman Lugo, Fernando Yes, but there are two options: a) 1. Migrate to iommu, 2. Remove DMM or: b) 1. Remove DMM, 2. Migrate to iommu I've heard there are some problems regarding DMM, and since you say you have already done the changes, and since iommu migration is not yet ready AFAIK, it might make sense to go for option b). Anyway, thanks for the clarification :) -- Felipe Contreras --
But DMM is used in this momment, it is after the IOMMU migration When DMM is not needed anymore. So we need to go for option a). Regards,
On Tue, Aug 24, 2010 at 10:05 PM, Guzman Lugo, Fernando Oh, I actually meant the DMM pool. a) 1. Migrate to iommu, 2. Remove DMM completely b) 1. Remove DMM pool, 2. Migrate to iommu 3. Remove DMM completely -- Felipe Contreras --
Ok, what is the issue with DMM pool? The issue I see removing DMM pool in this moment and making all the DMM Available (from 0x11000000 to 0xFFFFFFFF omap3 case) that is: The DMM module allocates a list of "struct map_page" elements base on DMM_POOL_SIZE to keep track of memory reserved and mapped. Memory allocated = DMM_POOL_SIZE / PAGE_SIZE * sizeof(struct map_page); So making all memory avalible it will increase the memory used for DMM Module and it could be quite significant. Iovmm.c module, the list is increased dynamically when it is needed so It does no have that problem. Then when the migration is done and Iovmm.c module is used the DMM_POOL_SIZE can be removed without issues. Regards,
On Tue, Aug 24, 2010 at 10:30 PM, Guzman Lugo, Fernando It seems that this "memory allocated" you are taking about is an array, but what we would like is a list, like apparently iovmm is using. I think I can give that a try if needed. However, from what I can see iovmm can be used instead of dmm even if the switch to iommu is not yet there. -- Felipe Contreras --
Iovmm have a list of memory used (reserved, that is what dmm module does) and also maps the buffer, So we can not use iovmm without removing The mapping which is done inside dspbridge because it will conflic with The mapping doing inside iovmm module. So that means for using iovmm, the Mapping in dspbridge had to be removed in order to work properly. Regards,
On Wed, Aug 25, 2010 at 12:55 AM, Guzman Lugo, Fernando Or the whole iovmm.c can be copied and just remove the mapping. -- Felipe Contreras --
That is the migration patches do, remove custom bridge mapping and use iovmm module instead. Regards,
On Wed, Aug 25, 2010 at 7:00 PM, Guzman Lugo, Fernando You didn't get me; copy the iovmm.c code into dmm.c, and remove the mapping. -- Felipe Contreras --
It sounds like double work, changing the dmm.c which will disappear. Also I think what you want is only the change from array to Linked list. Otherwise copying iovmm.c into dmm.c and adapting To how dspbridge is at this momment it will need too much changes, It is better to think like: take memory reservation (linked list) Implementation from iovmm and map it to dmm.c. But I don't see the point of doing that, if dmm.c is about to Dissapear. Regards,
On Wed, Aug 25, 2010 at 10:42 PM, Guzman Lugo, Fernando But in the meantime the bug is still there, and there's no timeline When exactly? -- Felipe Contreras --
I think you are talking about the issue when there are a lot of reservations and unreservations of big buffer and the memory is getting fragmented and it is not possible to allocate more big buffers. if so, I don't think it is a bug. The thing is because of the algorithm used for reserve memory is optimized to satisfy the memory requested as soon as possible, so this algorithm is good where there are too much reservation of memory and for small buffers, because the algorithm get rid of big free chucks of memory soon. so that issue, can be fixed just chaning the algorithm without changing the array implementation with iommu migration patches, hopefully next week. Regards, --
On Wed, 30 Jun 2010 19:20:59 -0500 I don't read the whole thread but the above description is incorrect. Why can't you use scatter gather chaining? You can create a scatter list for a buffer larger than 1MB. --
Hi Fujita, The thing is that ARM architecture does not support SG chaining. This patch should be seen like a workaround until it is fixed in iovmm module. Thanks and regards, Fernando. --
On Thu, 26 Aug 2010 07:38:26 -0500 Fix iovmm module is easier than the workaround? From a quick look, arch/arm/plat-omap/iovmm.c does nothing wrong about scatter gather chaining. arm/arm/mm/dma-mapping.c looks fine too about it. Maybe just defining ARCH_HAS_SG_CHAIN works? --
I have not thought about possible fixes inside iovmm, but now I am reviewing the patches I will figure out how to fix this inside iovmm. Since he workaround still I can try, but it looks tricky for me. Maybe someone else can tell us why SG chain is not supported for ARM or if there is a problem just defining ARCH_HAS_SG_CHAIN. Regards, Fernando. --
On Thu, 26 Aug 2010 08:16:24 -0500 I suppose that nobody in ARM has been interested in the feature. It was invented to improve I/O performance with large I/O requests. No wonder embeded people aren't interested in it. fujita@rose:~/git/linux-2.6$ find arch -name 'scatterlist.h'|xargs grep HAS_SG arch/x86/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN arch/ia64/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN arch/sparc/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN arch/powerpc/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN --
Ok, so let me try SG chain, that should be the correct fix. Thanks a lot, Fernando. --
This patch removes all the custom mmu code remaining in
tiomap3430.c which is not needed anymore.
Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
---
drivers/dsp/bridge/core/_tiomap.h | 1 -
drivers/dsp/bridge/core/tiomap3430.c | 470 ----------------------------------
2 files changed, 0 insertions(+), 471 deletions(-)
diff --git a/drivers/dsp/bridge/core/_tiomap.h b/drivers/dsp/bridge/core/_tiomap.h
index 4aa2358..c41fd8e 100644
--- a/drivers/dsp/bridge/core/_tiomap.h
+++ b/drivers/dsp/bridge/core/_tiomap.h
@@ -356,7 +356,6 @@ struct bridge_dev_context {
/* TC Settings */
bool tc_word_swap_on; /* Traffic Controller Word Swap */
- struct pg_table_attrs *pt_attrs;
u32 dsp_per_clks;
};
diff --git a/drivers/dsp/bridge/core/tiomap3430.c b/drivers/dsp/bridge/core/tiomap3430.c
index 88f5167..96cceea 100644
--- a/drivers/dsp/bridge/core/tiomap3430.c
+++ b/drivers/dsp/bridge/core/tiomap3430.c
@@ -105,56 +105,9 @@ static int bridge_dev_create(OUT struct bridge_dev_context
static int bridge_dev_ctrl(struct bridge_dev_context *dev_context,
u32 dw_cmd, IN OUT void *pargs);
static int bridge_dev_destroy(struct bridge_dev_context *dev_context);
-static u32 user_va2_pa(struct mm_struct *mm, u32 address);
-static int pte_update(struct bridge_dev_context *hDevContext, u32 pa,
- u32 va, u32 size,
- struct hw_mmu_map_attrs_t *map_attrs);
-static int pte_set(struct pg_table_attrs *pt, u32 pa, u32 va,
- u32 size, struct hw_mmu_map_attrs_t *attrs);
-static int mem_map_vmalloc(struct bridge_dev_context *hDevContext,
- u32 ul_mpu_addr, u32 ulVirtAddr,
- u32 ul_num_bytes,
- struct hw_mmu_map_attrs_t *hw_attrs);
bool wait_for_start(struct bridge_dev_context *dev_context, u32 dw_sync_addr);
-/* ----------------------------------- Globals */
-
-/* Attributes of L2 page tables for DSP MMU */
-struct page_info {
- u32 num_entries; /* Number of valid PTEs in the L2 PT */
-};
-
-/* Attributes used to manage the DSP MMU ...hw directory only was being used for custom iommu implementation api's, so after the iommu module migration this directory is not needed anymore. Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com> --- arch/arm/plat-omap/include/dspbridge/dspioctl.h | 7 - drivers/dsp/bridge/Makefile | 3 +- drivers/dsp/bridge/core/_tiomap.h | 1 - drivers/dsp/bridge/core/io_sm.c | 4 - drivers/dsp/bridge/core/mmu_fault.c | 4 - drivers/dsp/bridge/core/tiomap3430.c | 22 +- drivers/dsp/bridge/core/tiomap3430_pwr.c | 183 +------ drivers/dsp/bridge/core/tiomap_io.c | 5 +- drivers/dsp/bridge/core/ue_deh.c | 4 - drivers/dsp/bridge/hw/EasiGlobal.h | 41 -- drivers/dsp/bridge/hw/GlobalTypes.h | 308 ------------ drivers/dsp/bridge/hw/MMUAccInt.h | 76 --- drivers/dsp/bridge/hw/MMURegAcM.h | 226 --------- drivers/dsp/bridge/hw/hw_defs.h | 60 --- drivers/dsp/bridge/hw/hw_mmu.c | 587 ----------------------- drivers/dsp/bridge/hw/hw_mmu.h | 161 ------- drivers/dsp/bridge/rmgr/node.c | 4 +- 17 files changed, 35 insertions(+), 1661 deletions(-) delete mode 100644 drivers/dsp/bridge/hw/EasiGlobal.h delete mode 100644 drivers/dsp/bridge/hw/GlobalTypes.h delete mode 100644 drivers/dsp/bridge/hw/MMUAccInt.h delete mode 100644 drivers/dsp/bridge/hw/MMURegAcM.h delete mode 100644 drivers/dsp/bridge/hw/hw_defs.h delete mode 100644 drivers/dsp/bridge/hw/hw_mmu.c delete mode 100644 drivers/dsp/bridge/hw/hw_mmu.h diff --git a/arch/arm/plat-omap/include/dspbridge/dspioctl.h b/arch/arm/plat-omap/include/dspbridge/dspioctl.h index 41e0594..bad1801 100644 --- a/arch/arm/plat-omap/include/dspbridge/dspioctl.h +++ b/arch/arm/plat-omap/include/dspbridge/dspioctl.h @@ -19,10 +19,6 @@ #ifndef DSPIOCTL_ #define DSPIOCTL_ -/* ...
With changes for iommu migration mmu fault report and dsp track
dump is broken, this patch fixes that.
Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
---
drivers/dsp/bridge/core/mmu_fault.c | 93 ++++++---------------------------
drivers/dsp/bridge/core/mmu_fault.h | 5 +-
drivers/dsp/bridge/core/tiomap3430.c | 2 +
drivers/dsp/bridge/core/ue_deh.c | 31 +++++-------
4 files changed, 34 insertions(+), 97 deletions(-)
diff --git a/drivers/dsp/bridge/core/mmu_fault.c b/drivers/dsp/bridge/core/mmu_fault.c
index 5c0124f..d991c6a 100644
--- a/drivers/dsp/bridge/core/mmu_fault.c
+++ b/drivers/dsp/bridge/core/mmu_fault.c
@@ -23,9 +23,12 @@
/* ----------------------------------- Trace & Debug */
#include <dspbridge/host_os.h>
#include <dspbridge/dbc.h>
+#include <plat/iommu.h>
/* ----------------------------------- OS Adaptation Layer */
#include <dspbridge/drv.h>
+#include <dspbridge/dev.h>
+
/* ----------------------------------- Link Driver */
#include <dspbridge/dspdeh.h>
@@ -40,11 +43,6 @@
#include "_tiomap.h"
#include "mmu_fault.h"
-static u32 dmmu_event_mask;
-u32 fault_addr;
-
-static bool mmu_check_if_fault(struct bridge_dev_context *dev_context);
-
/*
* ======== mmu_fault_dpc ========
* Deferred procedure call to handle DSP MMU fault.
@@ -62,78 +60,21 @@ void mmu_fault_dpc(IN unsigned long pRefData)
* ======== mmu_fault_isr ========
* ISR to be triggered by a DSP MMU fault interrupt.
*/
-irqreturn_t mmu_fault_isr(int irq, IN void *pRefData)
-{
- struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)pRefData;
- struct bridge_dev_context *dev_context;
- struct cfg_hostres *resources;
-
- DBC_REQUIRE(irq == INT_DSP_MMU_IRQ);
- DBC_REQUIRE(deh_mgr_obj);
-
- if (deh_mgr_obj) {
-
- dev_context =
- (struct bridge_dev_context *)deh_mgr_obj->hbridge_context;
-
- resources = dev_context->resources;
-
- if (!resources) {
- dev_dbg(bridge, "%s: Failed to get Host ...Hi Fernando, From: ext Fernando Guzman Lugo <x0095840@ti.com> Subject: [PATCH 5/9] dspbridge: add mmufault support I think that the following "iommu_disable()" does disabling MMU. Modified arch/arm/plat-omap/iommu.c diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index a202a2c..17407f1 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -800,7 +800,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!stat) return IRQ_HANDLED; - iommu_disable(obj); + iommu_disable(obj); <- HERE! iopgd = iopgd_offset(obj, da); You can find the latest omap iommu code from: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-iommu-for-next Also I just thought that, passing 'da' to user callback might be cleaner as below. Then you can avoid the direct access to IOMMU registers. Basically we should avoid the direct access to IOMMU registers from client. If you have to, then it would be better to modify omap iommu code itself. Modified arch/arm/plat-omap/iommu.c diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index a202a2c..64d918e 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -787,13 +787,6 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!obj->refcount) return IRQ_NONE; - /* Dynamic loading TLB or PTE */ - if (obj->isr) - err = obj->isr(obj); - - if (!err) - return IRQ_HANDLED; - clk_enable(obj->clk); stat = iommu_report_fault(obj, &da); clk_disable(obj->clk); @@ -802,6 +795,13 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) iommu_disable(obj); + /* user registered callback */ + if (obj->isr) + err = obj->isr(obj, da); + + if (!err) + return IRQ_HANDLED; + --
What you mean? a) The replacement of the function? All custom mmu api's are removed, so the hw_mmu_event_ack is not a valid function any more. b) acking mmu fault interrupt? After the mmu fault the iva2 iommu prevent DSP to continue executing until the ack is done. And in this point we need let DSP continue in order to dsp its stack in share memory. Thanks for the comments, Regards, --
