• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1066 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3352: DMTimer2 kernel suspend failure

Joe G.
Mastermind 25966 points

Part Number: AM3352

Tool/software: Linux

Are any known issues around timer2 system timer interrupts causing suspend failures in Processor-SDK 1.03?

A customer reporting they sporadically see the “Kernel suspend failure” message during Deepsleep0 (DS0) suspend/resume test cycles.

Further study seems to point to the DMtimer2 interrupts in /arc/arm/mach-omap2/timer.c _suspend() and _resume() functions

Does that make sense?

Please see detailed debug steps below:

I have been able to reproduce an instance of “Kernel suspend failure” on my [hardware] with debug code in place to read the INTC_SIR_IRQ register after the nonzero return from cpu_suspend(). The value is 0x44, which is decimal 68.  From this, I look at /proc/interrupts and see that INTC 68 is ‘gp_timer’.  This interrupt is set up in …/arch/arm/mach-omap2/timer.c and is the hardware timer2 interrupt, which is the ‘clockevent’ system timer.

the previous debug code read each of the four INTC_PENDING_IRQn registers, but they were all 0.  The TRM seems to imply that these will not show masked interrupts. That’s why I switched to reading INTC_SIR_IRQ.

Timer.c does have _suspend() and _resume() functions. Omap_clkevt_suspend() only performs a module idle operation, and I have verified that AM33XX_CM_PER_TIMER2_CLKCTRL register is 0x00030000, which is the disabled state.  But the _suspend does not disable the interrupt.

So I’m asking if there are any known issues around timer2 system timer interrupts causing suspend failures in Processor-SDK 1.03?

  • 0
    TI__Guru**** 393215 points
    The PM experts have been notified. They will respond here.
  • 0
    TI__Guru**** 170625 points
    Hi Joe,

    I checked the list with know issues for PSDK 1.03, but I can not find anything related to timer2:

    processors.wiki.ti.com/index.php

    Have you test this issue on the AM335x TI EVM?

    We have one errata that might be related, have a look in Advisory 1.0.39 GPTimer: Delay Needed to Read Some GPTimer Registers After Wakeup

    See also if the below e2e thread will be in help:
    e2e.ti.com/.../497845

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    TI__Mastermind 25966 points
    Thanks, do we have any more detail on the following and how it was fixed?:
    >>D-02035 Medium AM335x: Power: Kernel suspend failure seen sometimes None X

    (Also believe your above E2E link is internal so not externally accessible).
  • 0 in reply to Joe G.
    TI__Guru**** 170625 points

    Joe George said:
    Thanks, do we have any more detail on the following and how it was fixed?:
    >>D-02035 Medium AM335x: Power: Kernel suspend failure seen sometimes None X

    What I was able to find is that issue goes up till PSDK 3.0 under the name "LCPD-985 Power: Kernel suspend failure seen sometimes". This issue has been fixed in PSDK 3.1

    URL: git://git.ti.com/processor-sdk/processor-sdk-linux.git
    Branch: processor-sdk-linux-03.01.00
    Commit ID: db0b54cdadef2d754ef7c2d8dd7300ef085985ef

    You can check the git logs to find which patch exactly (or multiple patches) fix this issue, check the logs between PSDK 3.0 and PSDK 3.1. You can also make a search in our JIRA system regarding LCPD-985

    Joe George said:
    (Also believe your above E2E link is internal so not externally accessible).

    Also believe you can access this link.

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    TI__Guru**** 170625 points
    Update from e-mail correspondence:

    Kernel suspend failures are still seen rarely in all of our kernels, they are caused by a late abort during the suspend path which is caused by an interrupt. The window of time in which an interrupt causes this is very small so these are rare, and in the case the kernel suspend failure occurs a second immediate attempt should succeed without issue.