On Thu, May 13, 2010 at 12:09 AM, Guzman Lugo, Fernando
<fernando.l...@ti.com> wrote:
>> If you are referring to this patch:
>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
>> 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22
>
> Yes, that's the patch. Could you make sure that the GPT8 interrupt is
> generated before acking MMU fault interrupt?
I'll try tomorrow when I have access to the hw.
>> I tried to backport it to minimize the changes to a reproducible
>> test-case. I guess in the l-o branch the commit would be dd1fd0b.
>> Unfortunately that didn't fix the corruption. So I don't by that GPT8
>> theory.
>>
>> > - we don't need allocate memory for dummy_va_addr, if some patch should
>> be created should be the patch to remove dummy_va_addr allocation and
>> deletion.
>>
>> I tried that, and that actually fixes the corruption for me (passing 0
>> to hw_mmu_tlb_add).
>
> I think first page DSP side memory is never mapped to MPU side, so even if
> the DSP corrupts that page it does not affect MPU side. However the right
> solution is the one explained before: avoid DSP continues executing after
> MMUfault.
First of all, what is the DSP supposed to do with that memory? Do we
really need to call hw_mmu_tlb_add at all?
We really, absolutely want the DSP to don't corrupt memory on ARM
side, so if we pass something, it should be full pages.
Sure, it would be nice to wait for the DSP to stop, but if for some
reason it doesn't, we need to know that the DSP doesn't have the power
to corrupt memory.
Now, I went back to commit 72110f1 and tried the patch you mentioned.
There's no GPT8 involved, and I cannot reproduce any corruption on a
beagleboard.
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -193,6 +193,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
&resources);
if (MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) {
+ void *temp1, *temp2;
printk(KERN_INFO
"bridge_deh_notify: ********** DEVICE EXCEPTION "
"**********\n");
@@ -227,8 +228,11 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
printk(KERN_INFO
"bridge_deh_notify: DSP_MMUFAULT, fault "
"address = 0x%x\n", (unsigned int)fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
+ temp1 = kmalloc(0x100000, GFP_ATOMIC);
+ temp2 = kmalloc(0x1000, GFP_ATOMIC);
+ kfree(temp1);
+ kfree(temp2);
+ dummy_va_addr = (u32) kmalloc(0x1000, GFP_ATOMIC);
mem_physical =
VIRT_TO_PHYS(PG_ALIGN_LOW
((u32) dummy_va_addr, PG_SIZE4K));
Is there anything special I should do?
Also, wouldn't it be easier to trigger this by doing:
printk(KERN_INFO
"bridge_deh_notify: DSP_MMUFAULT, fault "
"address = 0x%x\n", (unsigned int)fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
+ temp1 = kmalloc(0x100000, GFP_ATOMIC);
+ temp2 = kmalloc(0x1000, GFP_ATOMIC);
+ kfree(temp1);
mem_physical =
VIRT_TO_PHYS(PG_ALIGN_LOW
- ((u32) dummy_va_addr, PG_SIZE4K));
+ ((u32) temp2, PG_SIZE4K));
+ kfree(temp2);
dev_context = (struct wmd_dev_context *)
deh_mgr_obj->hwmd_context;
/* Reset the dynamic mmu index to fixed count if it
Cheers.
--
Felipe Contreras
--
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
