Re: Cannot resume after entering WFI or suspend state

Re: Cannot resume after entering WFI or suspend state

[Sudeep Holla]

Hi Amit,

On 11/11/16 06:25, amit mahadik wrote:
> Hi, I am trying to understand  the Linux Power management Unit
> framework. I have an ARM Cortex-A9x4 board.

Is this platform upstreamed ? I mean can I look at all the code executed
in the suspend/resume path ?

> When I enable pm_test or pass initcall_debug parameter through U-boot
> via bootargs the system goes into (wfi/suspend state) and resumes
> properly. However, the issue is when I am not using pm_test and

I thought test_suspend=<x> was the command line for that. I don't see
any code parsing pm_test. Could be your local change ?

> initcall_debug and put my system into WFI/SUSPEND state , it does not
> resume even if the registered wakeup IRQ is generated.
>
That's strange an could be timing related.

> Following are my Queries/observations. 1. Reading the log I find that
> Linux Masks the non-wakeup interrupts. This code was not present in
> linux 3.4.14.

/me confused. You are using v3.4.* or v4.4.* kernel ? Why are you mixing
the reference here ?

> 2. I tried to disable IRQCHIP_MASK_ON_SUSPEND flag from irq_chip.
> Doing so the I was able to resume from wfi state only once.

Unless you understand your IRQ controller and it provide no way to set
the wake up irq and it's taken care elsewhere in the hardware, you
should retain that. Which irq driver is this ? again in upstream ?

> After that the system resumed immediately without any interrupt after
> putting it into wfi state. 3. I tried adding IRQF_NO_SUSPEND flag to
> the wakeup interrupt and also used enable_irq_wake() function but
> with no success.

IRQF_NO_SUSPEND is not meant to be used for wakeup purposes. Read the
documentation, it just makes sure, the interrup is not disabled when
suspending and doesn't guarantee anything around wakeup source.

> The system does not respond to any interrupts once in wfi/suspend
> state. 4. I have attached log messages file for reference.
>

It has a new parameter "suspend", so it must have own driver installing
pm_suspend_ops ? Is that upstream ?

You seem to have lot of custom code which is not in the mainline. It's
difficult to help you if we don't have all the necessary information on
your setup.

-- 
Regards,
Sudeep

Re: Fwd: Cannot resume after entering WFI or suspend state

[Sudeep Holla]

Hi Amit,

You should not use html, please make sure you don't use it in future
when replying on the list. Also try to use some better email client
that doesn't spoil the formatting too much when responding(for me it
looks like you inserted >> manually which is not correct) and never top
post.

On 11/11/16 15:14, amit mahadik wrote:
> Hi Sudeep,
>                 Thanks for your reply.
>
> /*1. Is this platform upstreamed ? I mean can I look at all the code
> executed **in the suspend/resume path *?/
>
>  >>> No. This platform is not upstreamed. Earlier it had kernel version
> 3.4.14 running on it. I am in the process of porting new version
>      4.4.16 on it.
>

OK

> */2. I thought test_suspend=<x> was the command line for that. I don't
> see any code parsing pm_test. Could be your local change ?/*
>
>>>> I tried with test_suspend=mem and gave repeat parameter > 1. But the code is stuck
> after it executes custom power management           code. The same code
> PM code (in mach-xx/pm.c) file works for kernel 3.4.
>>>> If I enable PM debugging kernel option I get a sysfs entry.
> (/sys/power/pm_test). If I select parameter other than none, the kernel
>             code has checkpoints to resume the system. Like
> suspend_test(TEST_PLATFORM / TEST_CORE)
>

So you need to debug that yourself unless it's shared.


> */3. me confused. You are using v3.4.* or v4.4.* kernel ? Why are you
> mixing the reference here ?/*
> */
> /*
>>>> My platform had 3.4.14 kernel running on it. Thats why I am using it as my reference.The PM code is working fine on 3.4.14.
> */
> /*
> */4. Unless you understand your IRQ controller and it provide no way to
> set the wake up irq and it's taken care elsewhere in the       hardware,
> you should retain that. Which irq driver is this ? again in upstream ?/*
> */5. IRQF_NO_SUSPEND is not meant to be used for wakeup purposes. Read
> the documentation, it just makes sure, the interrupt     is not
>  disabled when suspending and doesn't guarantee anything around wakeup
> source./*
> */
> /*
>>>> I have retained the code. IRQ driver is GIC driver (drivers/irqchip/irq-gic.c). The wakeup irq mask is taken care in Hardware.
>       I have also used enable_wake_irq() function.
>

In that case, just retain that flag, GIC has no mechanism to set wake 
up. Also it's better if we mask non wakeup sources on suspend.

> */6. It has a new parameter "suspend", so it must have own driver
> installing pm_suspend_ops ? Is that upstream ?/*
> */
> /*
>>>> Yes suspend is a new parameter, having its own driver installing pm_suspend_ops. The code is not upstream.
>        My issue is that after giving suspend command (echo suspend >
> /sys/power/state) my code reaches my own driver and executes the
>        corresponding suspend code. However., the platform does not
> recognize my wakeup irq.
>

Is it enabled at the interrupt controller ? Is GIC also powered down in 
the suspend path ? If so, the power controller need to have logic to 
listen to your wakeup source. BTW what's your wakeup source ? Is it 
enabled ? You can check the sysfs entry.

-- 
Regards,
Sudeep