Fail to enter retention

Fail to enter retention

[Ran Shalit]

Hello,

I'm using OMAP3530 with custom board. I have enabled all power mode
features as described in PSP wiki, but it still fails to enter any
state different from state0.

~ # cat /dbg/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:3,INA:4,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
neon_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
per_clkdm->per_pwrdm (11)
usbhost_clkdm->usbhost_pwrdm (3)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (2)
core_l4_clkdm->core_pwrdm (12)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
sgx_clkdm->sgx_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)

The next thing was trying to get the uart to sleep (though there might
be also problems with other domains ?) .

On trying to enable uart as wakeup source I get the following:

echo enabled >  /sys/devices/platform/omap/omap_uart.2/power/wakeup

cat  /sys/devices/platform/omap/omap_uart.2/power/wakeup

#> disabled      (?????)

echo 1 >  /sys/devices/platform/omap/omap_uart.2/sleep_timeout
~ # [   85.006622] omap_device: omap_uart.2: new worst case deactivate
latency 0: 61035
[   85.559844] omap_device: omap_uart.2: new worst case activate
latency 0: 61035
[  982.415161] omap_device: omap_uart.2: new worst case deactivate
latency 0: 91552

< console hangs here >



Thanks for any suggestions,

Ran

Re: Fail to enter retention

[Tony Lindgren]

* Ran Shalit <ranshalit@gmail.com> [141116 12:13]:
> Hello,
> 
> I'm using OMAP3530 with custom board. I have enabled all power mode
> features as described in PSP wiki, but it still fails to enter any
> state different from state0.

Works for me with pretty much all omap3 boards I have here with
mainline kernel since v3.17 using omap2plus_defconfig. And the
following script to idle uarts and enable off-idle (or retention).

USB needs to be disconnected and EHCI probably still cannot be
enabled.
 
> The next thing was trying to get the uart to sleep (though there might
> be also problems with other domains ?) .
> 
> On trying to enable uart as wakeup source I get the following:
> 
> echo enabled >  /sys/devices/platform/omap/omap_uart.2/power/wakeup
> 
> cat  /sys/devices/platform/omap/omap_uart.2/power/wakeup
> 
> #> disabled      (?????)
> 
> echo 1 >  /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> ~ # [   85.006622] omap_device: omap_uart.2: new worst case deactivate
> latency 0: 61035
> [   85.559844] omap_device: omap_uart.2: new worst case activate
> latency 0: 61035
> [  982.415161] omap_device: omap_uart.2: new worst case deactivate
> latency 0: 91552
> 
> < console hangs here >

Sounds like you need to enable the wake-up interrupt for the UART.
See the interrupts-extended entry for many omap3-*.dts files:

interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;

If you get it working, care to update the instructions in the wiki
too?

Regards,

Tony

8< ----------------------
#!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
	echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/ttyO*/power/ -type d 2>/dev/null)
for uart in $uarts; do
	echo enabled > $uart/wakeup 2>&1
	echo auto > $uart/control 2>&1
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode

Re: Fail to enter retention

[Ran Shalit]

Hi Tony,

Thanks very much for suggestions,
I am able to wakeup the uart (though it takes about 10 seconds till it wakeup).
Anyway, after wakeup when I try to see the state I get:
~ # cat /dbg/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:3,INA:4,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
neon_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
per_clkdm->per_pwrdm (11)
usbhost_clkdm->usbhost_pwrdm (3)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (2)
core_l4_clkdm->core_pwrdm (12)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
sgx_clkdm->sgx_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)

~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state0/time
811807044
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state2/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state3/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state5/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state6/time
0

Do you have any suggestion, how I can understnad why it did not get
into retention and how to continue from this point ?

Thanks very much,
Ran

On Mon, Nov 17, 2014 at 6:22 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ran Shalit <ranshalit@gmail.com> [141116 12:13]:
>> Hello,
>>
>> I'm using OMAP3530 with custom board. I have enabled all power mode
>> features as described in PSP wiki, but it still fails to enter any
>> state different from state0.
>
> Works for me with pretty much all omap3 boards I have here with
> mainline kernel since v3.17 using omap2plus_defconfig. And the
> following script to idle uarts and enable off-idle (or retention).
>
> USB needs to be disconnected and EHCI probably still cannot be
> enabled.
>
>> The next thing was trying to get the uart to sleep (though there might
>> be also problems with other domains ?) .
>>
>> On trying to enable uart as wakeup source I get the following:
>>
>> echo enabled >  /sys/devices/platform/omap/omap_uart.2/power/wakeup
>>
>> cat  /sys/devices/platform/omap/omap_uart.2/power/wakeup
>>
>> #> disabled      (?????)
>>
>> echo 1 >  /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>> ~ # [   85.006622] omap_device: omap_uart.2: new worst case deactivate
>> latency 0: 61035
>> [   85.559844] omap_device: omap_uart.2: new worst case activate
>> latency 0: 61035
>> [  982.415161] omap_device: omap_uart.2: new worst case deactivate
>> latency 0: 91552
>>
>> < console hangs here >
>
> Sounds like you need to enable the wake-up interrupt for the UART.
> See the interrupts-extended entry for many omap3-*.dts files:
>
> interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;
>
> If you get it working, care to update the instructions in the wiki
> too?
>
> Regards,
>
> Tony
>
> 8< ----------------------
> #!/bin/bash
>
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
>         echo 3000 > $uart/autosuspend_delay_ms 2>&1
> done
>
> uarts=$(find /sys/class/tty/ttyO*/power/ -type d 2>/dev/null)
> for uart in $uarts; do
>         echo enabled > $uart/wakeup 2>&1
>         echo auto > $uart/control 2>&1
> done
>
> echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode

Re: Fail to enter retention

[Tony Lindgren]

* Ran Shalit <ranshalit@gmail.com> [141117 09:14]:
> Hi Tony,
> 
> Thanks very much for suggestions,
> I am able to wakeup the uart (though it takes about 10 seconds till it wakeup).

The wake-up should happen within few hundred milliseconds at most.
Sounds like you're waking on some timer event instead.

> Do you have any suggestion, how I can understnad why it did not get
> into retention and how to continue from this point ?

You need to look if you have some devices blocking deeper
idle states in cm_idlest*_core and cm_idlest_per registers.

The device will automatically idle whatever it can if there
are no blockers. I believe at least EHCI still is blocking,
and MUSB if configured and cable connected.

Regards,

Tony

Re: Fail to enter retention

[Ran Shalit]

>You need to look if you have some devices blocking deeper
>idle states in cm_idlest*_core and cm_idlest_per registers.

>The device will automatically idle whatever it can if there
>are no blockers. I believe at least EHCI still is blocking,
>and MUSB if configured and cable connected.

I'll check the registers value, should I then try to modify this
registers in order to get into retention ?
I will still have to disable serial right ? Maybe some kernel process
which run in background prevents retention ?
Is there some simple way to debug this or do I need to modify these registers ?

Thank you very much,
Ran

On Mon, Nov 17, 2014 at 8:09 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ran Shalit <ranshalit@gmail.com> [141117 09:14]:
>> Hi Tony,
>>
>> Thanks very much for suggestions,
>> I am able to wakeup the uart (though it takes about 10 seconds till it wakeup).
>
> The wake-up should happen within few hundred milliseconds at most.
> Sounds like you're waking on some timer event instead.
>
>> Do you have any suggestion, how I can understnad why it did not get
>> into retention and how to continue from this point ?
>
> You need to look if you have some devices blocking deeper
> idle states in cm_idlest*_core and cm_idlest_per registers.
>
> The device will automatically idle whatever it can if there
> are no blockers. I believe at least EHCI still is blocking,
> and MUSB if configured and cable connected.
>
> Regards,
>
> Tony

Re: Fail to enter retention

[Tony Lindgren]

* Ran Shalit <ranshalit@gmail.com> [141117 11:48]:
> >You need to look if you have some devices blocking deeper
> >idle states in cm_idlest*_core and cm_idlest_per registers.
> 
> >The device will automatically idle whatever it can if there
> >are no blockers. I believe at least EHCI still is blocking,
> >and MUSB if configured and cable connected.
> 
> I'll check the registers value, should I then try to modify this
> registers in order to get into retention ?

No, those are read-only status registers. You need idle the
drivers that show as blocking in those registers.

> I will still have to disable serial right ? Maybe some kernel process
> which run in background prevents retention ?

Yes otherwise the UART bits will show as blocking in those
registers.

> Is there some simple way to debug this or do I need to modify these registers ?

Just printing them out in the idle loop most likely will give
you the info you need.

Regards,

Tony

Re: Fail to enter retention

[Ran Shalit]

Hi Tony,

>Just printing the registers out in the idle loop most likely will give
>you the info you need.

Probably a dumb question... But if I try to print them won't it
automatically wakes up the serial (by the way should the serial wakeup
be configured to RX pin only ?)
Another thing I don't understand... Can it be that there is some
ongoing kernel process that also prevent me for entering retention ?
I think maybe I should try first to suspend (instead of trying to
enter retention in idle) , maybe it might bring better result ?

Thanks very much,
Ran

On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ran Shalit <ranshalit@gmail.com> [141117 11:48]:
>> >You need to look if you have some devices blocking deeper
>> >idle states in cm_idlest*_core and cm_idlest_per registers.
>>
>> >The device will automatically idle whatever it can if there
>> >are no blockers. I believe at least EHCI still is blocking,
>> >and MUSB if configured and cable connected.
>>
>> I'll check the registers value, should I then try to modify this
>> registers in order to get into retention ?
>
> No, those are read-only status registers. You need idle the
> drivers that show as blocking in those registers.
>
>> I will still have to disable serial right ? Maybe some kernel process
>> which run in background prevents retention ?
>
> Yes otherwise the UART bits will show as blocking in those
> registers.
>
>> Is there some simple way to debug this or do I need to modify these registers ?
>
> Just printing them out in the idle loop most likely will give
> you the info you need.
>
> Regards,
>
> Tony

Re: Fail to enter retention

[Ran Shalit]

Hi Tony,

When I try to do suspend from userspace, I get better results and it
seems that all domain been put to RET or OFF but on checking power
state time it still shows 0. Do you know why ?

usbhost_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:5,INA:4,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
neon_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
per_clkdm->per_pwrdm (11)
usbhost_clkdm->usbhost_pwrdm (3)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (2)
core_l4_clkdm->core_pwrdm (12)
core_l3_clkdm->core_pwrdm (4)
d2d_clkdm->core_pwrdm (0)
sgx_clkdm->sgx_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)

Thank you,
Ran

On Mon, Nov 17, 2014 at 11:09 PM, Ran Shalit <ranshalit@gmail.com> wrote:
> Hi Tony,
>
>>Just printing the registers out in the idle loop most likely will give
>>you the info you need.
>
> Probably a dumb question... But if I try to print them won't it
> automatically wakes up the serial (by the way should the serial wakeup
> be configured to RX pin only ?)
> Another thing I don't understand... Can it be that there is some
> ongoing kernel process that also prevent me for entering retention ?
> I think maybe I should try first to suspend (instead of trying to
> enter retention in idle) , maybe it might bring better result ?
>
> Thanks very much,
> Ran
>
> On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Ran Shalit <ranshalit@gmail.com> [141117 11:48]:
>>> >You need to look if you have some devices blocking deeper
>>> >idle states in cm_idlest*_core and cm_idlest_per registers.
>>>
>>> >The device will automatically idle whatever it can if there
>>> >are no blockers. I believe at least EHCI still is blocking,
>>> >and MUSB if configured and cable connected.
>>>
>>> I'll check the registers value, should I then try to modify this
>>> registers in order to get into retention ?
>>
>> No, those are read-only status registers. You need idle the
>> drivers that show as blocking in those registers.
>>
>>> I will still have to disable serial right ? Maybe some kernel process
>>> which run in background prevents retention ?
>>
>> Yes otherwise the UART bits will show as blocking in those
>> registers.
>>
>>> Is there some simple way to debug this or do I need to modify these registers ?
>>
>> Just printing them out in the idle loop most likely will give
>> you the info you need.
>>
>> Regards,
>>
>> Tony

Re: Fail to enter retention

[Ran Shalit]

Hi,

In coninuity to my previous message, thse is the log for time in state
0-state 6:

0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state0/time
761849079

~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state1/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state2/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state3/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state5/time
0
~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state6/time
0

Regards,
Ran

On Tue, Nov 18, 2014 at 10:21 AM, Ran Shalit <ranshalit@gmail.com> wrote:
> Hi Tony,
>
> When I try to do suspend from userspace, I get better results and it
> seems that all domain been put to RET or OFF but on checking power
> state time it still shows 0. Do you know why ?
>
> usbhost_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> dss_pwrdm (ON),OFF:0,RET:5,INA:4,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
> neon_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0
> mpu_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
> per_clkdm->per_pwrdm (11)
> usbhost_clkdm->usbhost_pwrdm (3)
> cam_clkdm->cam_pwrdm (0)
> dss_clkdm->dss_pwrdm (2)
> core_l4_clkdm->core_pwrdm (12)
> core_l3_clkdm->core_pwrdm (4)
> d2d_clkdm->core_pwrdm (0)
> sgx_clkdm->sgx_pwrdm (0)
> iva2_clkdm->iva2_pwrdm (0)
> neon_clkdm->neon_pwrdm (0)
> mpu_clkdm->mpu_pwrdm (0)
> prm_clkdm->wkup_pwrdm (0)
> cm_clkdm->core_pwrdm (0)
>
> Thank you,
> Ran
>
> On Mon, Nov 17, 2014 at 11:09 PM, Ran Shalit <ranshalit@gmail.com> wrote:
>> Hi Tony,
>>
>>>Just printing the registers out in the idle loop most likely will give
>>>you the info you need.
>>
>> Probably a dumb question... But if I try to print them won't it
>> automatically wakes up the serial (by the way should the serial wakeup
>> be configured to RX pin only ?)
>> Another thing I don't understand... Can it be that there is some
>> ongoing kernel process that also prevent me for entering retention ?
>> I think maybe I should try first to suspend (instead of trying to
>> enter retention in idle) , maybe it might bring better result ?
>>
>> Thanks very much,
>> Ran
>>
>> On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Ran Shalit <ranshalit@gmail.com> [141117 11:48]:
>>>> >You need to look if you have some devices blocking deeper
>>>> >idle states in cm_idlest*_core and cm_idlest_per registers.
>>>>
>>>> >The device will automatically idle whatever it can if there
>>>> >are no blockers. I believe at least EHCI still is blocking,
>>>> >and MUSB if configured and cable connected.
>>>>
>>>> I'll check the registers value, should I then try to modify this
>>>> registers in order to get into retention ?
>>>
>>> No, those are read-only status registers. You need idle the
>>> drivers that show as blocking in those registers.
>>>
>>>> I will still have to disable serial right ? Maybe some kernel process
>>>> which run in background prevents retention ?
>>>
>>> Yes otherwise the UART bits will show as blocking in those
>>> registers.
>>>
>>>> Is there some simple way to debug this or do I need to modify these registers ?
>>>
>>> Just printing them out in the idle loop most likely will give
>>> you the info you need.
>>>
>>> Regards,
>>>
>>> Tony

Re: Fail to enter retention

[Tony Lindgren]

* Ran Shalit <ranshalit@gmail.com> [141118 00:26]:
> 
> In coninuity to my previous message, thse is the log for time in state
> 0-state 6:
> 
> On Tue, Nov 18, 2014 at 10:21 AM, Ran Shalit <ranshalit@gmail.com> wrote:
> >
> > When I try to do suspend from userspace, I get better results and it
> > seems that all domain been put to RET or OFF but on checking power
> > state time it still shows 0. Do you know why ?

Looks like you still have some hardware blocking off states. Maybe the
state time shows only that?

> >> Probably a dumb question... But if I try to print them won't it
> >> automatically wakes up the serial (by the way should the serial wakeup
> >> be configured to RX pin only ?)

Yes for the RX pin only as that's where the wake-up event comes from.

> >> Another thing I don't understand... Can it be that there is some
> >> ongoing kernel process that also prevent me for entering retention ?

Could be if you have something CPU intensive going on like tracing.

> >> I think maybe I should try first to suspend (instead of trying to
> >> enter retention in idle) , maybe it might bring better result ?

Yes from the hardware point of view suspend does the same thing as
the deeper idle states.

Regards,

Tony

Re: Fail to enter retention

[Ran Shalit]

Hi Tony,

 I eventually managed to enter retention :))

I did the following changes:
 1. added CONFIG_SUSPEND (though I do not use suspend/resume but only
 cpuidle, it seems to have some effect, I think without it the wakeup in
 console did not function correctly.
 2. enabled sleep for all uart not just the console uart (as I did at first)
 3. uart rx was configured as wakeup source

 Than I can see that cpu0/state4/time is incremented. As I understand state4
 is retention in OMAP3530.

 The only bit strange thing is that I still see picture in screen. I wander
 how omap can enter retention can be while screen is on.

 Thanks very much for your assistance,
 Ran