OMAP3 DSP MMU fault + off mode issue

OMAP3 DSP MMU fault + off mode issue

[venki kaps]

Dear all,

I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).

The issue is describing as below mentioned way,
        1). The Device is getting DSP MMU Fault when playing MP4 video clip.

The system is not hitting off mode in the below scenario,
        2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
mode -----------> Never hits off mode

But surprisingly the system is hitting off mode in the below scenario,
       3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
Fault -> allow off mode -----------> perfectly works


 - Could you please describe the root cause about the above issues 1 & 2?
 - How could solve the above issues?

Best Regards,
Venkii

Re: OMAP3 DSP MMU fault + off mode issue

[venki kaps]

On Tue, Sep 14, 2010 at 1:28 AM, venki kaps <venkiece2005@gmail.com> wrote:
> Dear all,
>
> I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).
>
> The issue is describing as below mentioned way,
>        1). The Device is getting DSP MMU Fault when playing MP4 video clip.
>
> The system is not hitting off mode in the below scenario,
>        2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
> mode -----------> Never hits off mode
>
> But surprisingly the system is hitting off mode in the below scenario,
>       3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
> Fault -> allow off mode -----------> perfectly works
>
>
>  - Could you please describe the root cause about the above issues 1 & 2?
>  - How could solve the above issues?

I have found the issue with UART3.
In System configuration register (SYSC),-
             IDLEMODE  - Smart idle -------> working scenario  ------>
system hits off mode.
             IDLEMODE  - No idle -------> Non working scenario
------> system never hits off mode.

Could you please explain why UART3 is not able to hit smart idle after
DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow
off -----------> Never hits off mode).,

Thanks in advance.

> Best Regards,
> Venkii
>

Re: OMAP3 DSP MMU fault + off mode issue

[venki kaps]

On Tue, Sep 14, 2010 at 8:54 PM, venki kaps <venkiece2005@gmail.com> wrote:
> On Tue, Sep 14, 2010 at 1:28 AM, venki kaps <venkiece2005@gmail.com> wrote:
>> Dear all,
>>
>> I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).
>>
>> The issue is describing as below mentioned way,
>>        1). The Device is getting DSP MMU Fault when playing MP4 video clip.
>>
>> The system is not hitting off mode in the below scenario,
>>        2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
>> mode -----------> Never hits off mode
>>
>> But surprisingly the system is hitting off mode in the below scenario,
>>       3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
>> Fault -> allow off mode -----------> perfectly works
>>
>>
>>  - Could you please describe the root cause about the above issues 1 & 2?
>>  - How could solve the above issues?
>
> I have found the issue with UART3.
> In System configuration register (SYSC),-
>             IDLEMODE  - Smart idle -------> working scenario  ------>
> system hits off mode.
>             IDLEMODE  - No idle -------> Non working scenario
> ------> system never hits off mode.
>
> Could you please explain why UART3 is not able to hit smart idle after
> DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow
> off -----------> Never hits off mode).,

My problem is resolved.GPtimer7 was not reset during the MMU FAULT
occurrence before the first power cycle.
So this pending interrupt is preventing the system sleep entry.
Now it works fine after resetting Gptimer7 in pm suspend path.

> Thanks in advance.
>
>> Best Regards,
>> Venkii
>>
>

Re: OMAP3 DSP MMU fault + off mode issue

[Kevin Hilman]

venki kaps <venkiece2005@gmail.com> writes:

> On Tue, Sep 14, 2010 at 8:54 PM, venki kaps <venkiece2005@gmail.com> wrote:
>> On Tue, Sep 14, 2010 at 1:28 AM, venki kaps <venkiece2005@gmail.com> wrote:
>>> Dear all,
>>>
>>> I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).
>>>
>>> The issue is describing as below mentioned way,
>>>        1). The Device is getting DSP MMU Fault when playing MP4 video clip.
>>>
>>> The system is not hitting off mode in the below scenario,
>>>        2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
>>> mode -----------> Never hits off mode
>>>
>>> But surprisingly the system is hitting off mode in the below scenario,
>>>       3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
>>> Fault -> allow off mode -----------> perfectly works
>>>
>>>
>>>  - Could you please describe the root cause about the above issues 1 & 2?
>>>  - How could solve the above issues?
>>
>> I have found the issue with UART3.
>> In System configuration register (SYSC),-
>>             IDLEMODE  - Smart idle -------> working scenario  ------>
>> system hits off mode.
>>             IDLEMODE  - No idle -------> Non working scenario
>> ------> system never hits off mode.
>>
>> Could you please explain why UART3 is not able to hit smart idle after
>> DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow
>> off -----------> Never hits off mode).,
>
> My problem is resolved.GPtimer7 was not reset during the MMU FAULT
> occurrence before the first power cycle.
> So this pending interrupt is preventing the system sleep entry.
> Now it works fine after resetting Gptimer7 in pm suspend path.

Sounds like a patch is needed for DSPBridge who manages that timer.

Kevin

Re: OMAP3 DSP MMU fault + off mode issue

[venki kaps]

Venkii,
On Wed, Sep 15, 2010 at 8:02 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> venki kaps <venkiece2005@gmail.com> writes:
>
>> On Tue, Sep 14, 2010 at 8:54 PM, venki kaps <venkiece2005@gmail.com> wrote:
>>> On Tue, Sep 14, 2010 at 1:28 AM, venki kaps <venkiece2005@gmail.com> wrote:
>>>> Dear all,
>>>>
>>>> I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).
>>>>
>>>> The issue is describing as below mentioned way,
>>>>        1). The Device is getting DSP MMU Fault when playing MP4 video clip.
>>>>
>>>> The system is not hitting off mode in the below scenario,
>>>>        2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
>>>> mode -----------> Never hits off mode
>>>>
>>>> But surprisingly the system is hitting off mode in the below scenario,
>>>>       3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
>>>> Fault -> allow off mode -----------> perfectly works
>>>>
>>>>
>>>>  - Could you please describe the root cause about the above issues 1 & 2?
>>>>  - How could solve the above issues?
>>>
>>> I have found the issue with UART3.
>>> In System configuration register (SYSC),-
>>>             IDLEMODE  - Smart idle -------> working scenario  ------>
>>> system hits off mode.
>>>             IDLEMODE  - No idle -------> Non working scenario
>>> ------> system never hits off mode.
>>>
>>> Could you please explain why UART3 is not able to hit smart idle after
>>> DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow
>>> off -----------> Never hits off mode).,
>>
>> My problem is resolved.GPtimer7 was not reset during the MMU FAULT
>> occurrence before the first power cycle.
>> So this pending interrupt is preventing the system sleep entry.
>> Now it works fine after resetting Gptimer7 in pm suspend path.
>
> Sounds like a patch is needed for DSPBridge who manages that timer.

Patchwork DSPBRIDGE: MMU-Fault debugging enhancements,
https://patchwork.kernel.org/patch/91577/
>From the above patch, please see the below comment
/*
 * Send a GP Timer interrupt to DSP
 * The DSP expects a GP timer interrupt after an
 * MMU-Fault Request GPTimer
 */

The above changes allow for DSP task information to be printed
by the MPU dspbridge when DSP MMU fault ocurrs.

This above changes will be required during development.
In my scenario, it is not required so i have just commented.

Index: android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c
===================================================================
--- android-2.6.32.9.orig/drivers/dsp/bridge/wmd/ue_deh.c
2010-08-24 18:19:19.000000000 +0900
+++ android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c    2010-09-16
00:28:52.000000000 +0900
@@ -285,7 +285,8 @@
                         * The DSP expects a GP timer interrupt after an
                         * MMU-Fault Request GPTimer
                         */
-                       if (timer) {
+                       if (0) {
                                omap_dm_timer_enable(timer);
                                /* Enable overflow interrupt */
                                omap_dm_timer_set_int_enable(timer,


> Kevin
>

Re: OMAP3 DSP MMU fault + off mode issue

[venki kaps]

Venkii,
On Wed, Sep 15, 2010 at 9:12 PM, venki kaps <venkiece2005@gmail.com> wrote:
> Venkii,
> On Wed, Sep 15, 2010 at 8:02 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> venki kaps <venkiece2005@gmail.com> writes:
>>
>>> On Tue, Sep 14, 2010 at 8:54 PM, venki kaps <venkiece2005@gmail.com> wrote:
>>>> On Tue, Sep 14, 2010 at 1:28 AM, venki kaps <venkiece2005@gmail.com> wrote:
>>>>> Dear all,
>>>>>
>>>>> I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).
>>>>>
>>>>> The issue is describing as below mentioned way,
>>>>>        1). The Device is getting DSP MMU Fault when playing MP4 video clip.
>>>>>
>>>>> The system is not hitting off mode in the below scenario,
>>>>>        2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
>>>>> mode -----------> Never hits off mode
>>>>>
>>>>> But surprisingly the system is hitting off mode in the below scenario,
>>>>>       3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
>>>>> Fault -> allow off mode -----------> perfectly works
>>>>>
>>>>>
>>>>>  - Could you please describe the root cause about the above issues 1 & 2?
>>>>>  - How could solve the above issues?
>>>>
>>>> I have found the issue with UART3.
>>>> In System configuration register (SYSC),-
>>>>             IDLEMODE  - Smart idle -------> working scenario  ------>
>>>> system hits off mode.
>>>>             IDLEMODE  - No idle -------> Non working scenario
>>>> ------> system never hits off mode.
>>>>
>>>> Could you please explain why UART3 is not able to hit smart idle after
>>>> DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow
>>>> off -----------> Never hits off mode).,
>>>
>>> My problem is resolved.GPtimer7 was not reset during the MMU FAULT
>>> occurrence before the first power cycle.
>>> So this pending interrupt is preventing the system sleep entry.
>>> Now it works fine after resetting Gptimer7 in pm suspend path.
>>
>> Sounds like a patch is needed for DSPBridge who manages that timer.
>
> Patchwork DSPBRIDGE: MMU-Fault debugging enhancements,
> https://patchwork.kernel.org/patch/91577/
> From the above patch, please see the below comment
> /*
>  * Send a GP Timer interrupt to DSP
>  * The DSP expects a GP timer interrupt after an
>  * MMU-Fault Request GPTimer
>  */
>
> The above changes allow for DSP task information to be printed
> by the MPU dspbridge when DSP MMU fault ocurrs.
>
> This above changes will be required during development.
> In my scenario, it is not required so i have just commented.
>
> Index: android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c
> ===================================================================
> --- android-2.6.32.9.orig/drivers/dsp/bridge/wmd/ue_deh.c
> 2010-08-24 18:19:19.000000000 +0900
> +++ android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c    2010-09-16
> 00:28:52.000000000 +0900
> @@ -285,7 +285,8 @@
>                         * The DSP expects a GP timer interrupt after an
>                         * MMU-Fault Request GPTimer
>                         */
> -                       if (timer) {
> +                       if (0) {
>                                omap_dm_timer_enable(timer);
>                                /* Enable overflow interrupt */
>                                omap_dm_timer_set_int_enable(timer,
>

In latest kernels (Eg, linux-2.6.36-rc3),The MMU-Fault debugging
enhancements code is moved under CONFIG_TIDSPBRIDGE_BACKTRACE.

>> Kevin
>>
>

Re: OMAP3 DSP MMU fault + off mode issue

[Felipe Contreras]

On Wed, Sep 15, 2010 at 7:03 PM, venki kaps <venkiece2005@gmail.com> wrote:
> In latest kernels (Eg, linux-2.6.36-rc3),The MMU-Fault debugging
> enhancements code is moved under CONFIG_TIDSPBRIDGE_BACKTRACE.

Indeed, I added that configuration in order to avoid that possibly
troublesome code in a production system. I haven't seen it working
properly yet.

-- 
Felipe Contreras

Re: OMAP3 DSP MMU fault + off mode issue

[venki kaps]

On Thu, Sep 16, 2010 at 7:34 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 7:03 PM, venki kaps <venkiece2005@gmail.com> wrote:
>> In latest kernels (Eg, linux-2.6.36-rc3),The MMU-Fault debugging
>> enhancements code is moved under CONFIG_TIDSPBRIDGE_BACKTRACE.
>
> Indeed, I added that configuration in order to avoid that possibly
> troublesome code in a production system. I haven't seen it working
> properly yet.
Thanks for the information.
Even I have not used that configuration but in production system, We
could avoid the DSP task information to be printed by the MPU
dspbridge when DSP MMU fault ocurrs.

Venkii,

RE: OMAP3 DSP MMU fault + off mode issue

[Ramirez Luna, Omar]

venki kaps wrote:
...
> 
> My problem is resolved.GPtimer7 was not reset during the MMU FAULT
> occurrence before the first power cycle. So this pending interrupt is
> preventing the system sleep entry. 
> Now it works fine after resetting Gptimer7 in pm suspend path.
> 

That's doesn't sound right, why the problem is not occurring after the first suspend-resume cycle.

DSP is in charge of clearing the overflow interrupt and if it is doing it after the first transition to Core OFF, why wouldn't be doing it for the first one.

Moreover from the logs sent internally (since it is the same issue and oddly the same resolution), the trace log dump printed is generated in the dsp after clearing the interrupts, so the problem could be the gptimer is configured to autoreload instead of oneshoot or the dsp write is not posted to clear the interrupt (which might be valid issues), but also they could happen after the first transition to OFF.

I'm sorry if I didn't ask you for logs but I was seeing this issue internally (and assumed you'll be in the same team of people :)), and given that more information was posted there than here..., but still, if available send the changes you have made.

Regards,

Omar