iMX31 power management

iMX31 power management

[Thomas Nemeth]

    Hi.

    I'm currently struggling trying to make suspend to RAM work for the
    iMX31 processor. As the pm functions were not implemented, I added
    a pretty straightforward pm "driver".

    It works to a point. The processor seems really sleeping. But where
    the heck is Prince Charming ? It does not want to wakeup else :( I
    can't make the DOZE mode, State Retention mode and Deep Sleep mode
    to work. Does anybody know how ?

    I added in attachment the code I adapted from 2.6.22 so that it
    integrates better with current kernels.


Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pm.c
Type: text/x-csrc
Size: 4152 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100830/d8328997/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100830/d8328997/attachment.sig>

iMX31 power management

[Andy Green]

On 08/30/10 13:44, Somebody in the thread at some point said:

Hi -

>      I'm currently struggling trying to make suspend to RAM work for the
>      iMX31 processor. As the pm functions were not implemented, I added
>      a pretty straightforward pm "driver".
>
>      It works to a point. The processor seems really sleeping. But where
>      the heck is Prince Charming ? It does not want to wakeup else :( I
>      can't make the DOZE mode, State Retention mode and Deep Sleep mode
>      to work. Does anybody know how ?
>
>      I added in attachment the code I adapted from 2.6.22 so that it
>      integrates better with current kernels.

I ported this similar stuff from the Freescale tree to 2.6.32 last 
December, it sleeps and wakes fine (using stop clock) on that txtr board 
since then.

http://git.warmcat.com/cgi-bin/cgit/txtr-kernel/commit/?h=txtr-tracking&id=34685e9c378c865885ad6a8f2fc06fc36ad48482

There was no enable_irq_wake(); platform support at that time so I guess 
maybe there is now and you need to make sure your wake interrupts are 
marked as wake sources?

-Andy

iMX31 power management

[Thomas Nemeth]

Le lundi 30 ao?t 2010, Andy Green a ?crit?:
> On 08/30/10 13:44, Somebody in the thread at some point said:
>
> Hi -

    Hi Andy.


> >      I added in attachment the code I adapted from 2.6.22 so that
> > it integrates better with current kernels.
>
> I ported this similar stuff from the Freescale tree to 2.6.32 last
> December, it sleeps and wakes fine (using stop clock) on that txtr
> board since then.

    I did this piece of code because it wasn't in 2.6.34 mainline :)
    Should we make something to have it marged ?


> http://git.warmcat.com/cgi-bin/cgit/txtr-kernel/commit/?h=txtr-tracki
>ng&id=34685e9c378c865885ad6a8f2fc06fc36ad48482
>
> There was no enable_irq_wake(); platform support at that time so I

    I wasn't aware of that function. It indeed may be of a great help.
    I've seen that a lot of drivers use directly set_irq_wake(). Is
    there a "prefered" way of using this facility ?

    I think the set_wake() field in the irq_chip structure from
    arch/arm/plat-mxc/irq.c should be created, didn't it ?


> guess maybe there is now and you need to make sure your wake
> interrupts are marked as wake sources?

    In a more recent version of my pm.c source file, I have :
       __raw_writel(0, MXC_CCM_WIMR);
    in mx31_pm_prepare(), in order to enable all interrupts to wake the
    processor up. But to no use :(


    Thanks a lot.


Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100830/9e6cd356/attachment.sig>

iMX31 power management

[Andy Green]

On 08/30/10 15:41, Somebody in the thread at some point said:

Hi -

>> I ported this similar stuff from the Freescale tree to 2.6.32 last
>> December, it sleeps and wakes fine (using stop clock) on that txtr
>> board since then.
>
>      I did this piece of code because it wasn't in 2.6.34 mainline :)
>      Should we make something to have it marged ?

Yeah if it works for more than just my board ^^

>> http://git.warmcat.com/cgi-bin/cgit/txtr-kernel/commit/?h=txtr-tracki
>> ng&id=34685e9c378c865885ad6a8f2fc06fc36ad48482
>>
>> There was no enable_irq_wake(); platform support at that time so I
>
>      I wasn't aware of that function. It indeed may be of a great help.
>      I've seen that a lot of drivers use directly set_irq_wake(). Is
>      there a "prefered" way of using this facility ?

No idea, when I looked up that patch I saw I had gone and commented out 
that call at the time too, and remembered getting some unclear OOPS or 
warning telling me that the stuff wasn't implemented.  On the txtr 
device, it wakes fine from PMIC interrupt including RTC and its touchpad 
interrupt without having to meddle anything.

>      I think the set_wake() field in the irq_chip structure from
>      arch/arm/plat-mxc/irq.c should be created, didn't it ?

It may well be by now, that tree is still on 2.6.32.

>> guess maybe there is now and you need to make sure your wake
>> interrupts are marked as wake sources?
>
>      In a more recent version of my pm.c source file, I have :
>         __raw_writel(0, MXC_CCM_WIMR);
>      in mx31_pm_prepare(), in order to enable all interrupts to wake the
>      processor up. But to no use :(
>
>      Thanks a lot.

I recall having to fix something in the Freescale code, it might be 
worth checking through the patch I pointed to because I don't think it's 
just the freescale code any more.  I had a quick look and see if I did 
anything in the mach-*.c file but I didn't see anything relevant.

How're you provoking the suspend?  What worked for me was echo mem > 
/sys/power/state.

BTW we go 30mA from battery with clock stop suspend on iMX31 and 
everything else left up, so that's not so wonderful.  However the resume 
was well under 500ms, so the waking touchpad gesture can be seen and 
processed by the resumed driver in an unbroken fashion.

-Andy

iMX31 power management

[Thomas Nemeth]

Le lundi 30 ao?t 2010, Andy Green a ?crit?:
> On 08/30/10 15:41, Somebody in the thread at some point said:
> >      I did this piece of code because it wasn't in 2.6.34 mainline
> > :) Should we make something to have it marged ?
>
> Yeah if it works for more than just my board ^^

    I'm trying to make it work at least on mine too ;)


> >> guess maybe there is now and you need to make sure your wake
> >> interrupts are marked as wake sources?
> >
> >      In a more recent version of my pm.c source file, I have :
> >         __raw_writel(0, MXC_CCM_WIMR);
> >      in mx31_pm_prepare(), in order to enable all interrupts to
> > wake the processor up. But to no use :(
>
> I recall having to fix something in the Freescale code, it might be
> worth checking through the patch I pointed to because I don't think
> it's just the freescale code any more.  I had a quick look and see if
> I did anything in the mach-*.c file but I didn't see anything
> relevant.

    Except using local_irq_*() in your code, it looks a lot like what I
    already have. The mxc_ccm_modify_reg() function is also present in
    your code although not used everywhere MXC_CCM_CCMR is modified.


> How're you provoking the suspend?  What worked for me was echo mem >
> /sys/power/state.

    I did that too. And also with "standby" instead of "mem".


> BTW we go 30mA from battery with clock stop suspend on iMX31 and

    30mA is also what we get (with WinCE) though it should be ten
    percent of that.


> everything else left up, so that's not so wonderful.  However the
> resume was well under 500ms, so the waking touchpad gesture can be
> seen and processed by the resumed driver in an unbroken fashion.

    That's a good news :)


Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100830/c03f29ca/attachment.sig>