OS: Windows CE 6.0 R2
Updates: Rollup and Jan 2008-Apr2008
Arch: ARM

Recently I've noticed that my display driver is not always powering up
after coming out of sleep mode. Through some debugging I've Noticed
that one of three scenarios are occurring when resuming from sleep /
suspend mode. Of these, only one situation results in a success
setup.

When everything is working the Display Driver's DrvEscape routine
(overloaded from DDGPE) gets a Power Request to move to D3 (Suspend)
where it stays until the system is requested to power up. At this
time it gets a request to transition to D2 (Standby) followed by
another request to move to D1 (Low On.)

In one of the situations that fails, it behaves exactly like the
Success case except the final call into Power State D1 never arrives
(or any other power state.)

In the final failure situation after getting a power state change to
D2 it receives a power state change to D4 (Shutdown) instead of D1 or
D0.

I am also using the Default Power Manager, with all Timeouts set to 0
(Disabled) (AC/Batt User/System/Suspend)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power
DisableGWESPowerOff=1
ScreenPowerOff=0
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\States
(These are Keys with the default value)
On=D0
ColdReboot=D4
Reboot=D4
Resuming=D2
Suspend=D3
SystemIdle=D2
UserIdle=D1

SystemIdle has the Display Class ID with D4
Suspend has the NDIS Class ID with D4.

Thank you, any help is appreciated.
Brad.

Re: Display Driver's DrvEscape gets inconsistent Power States Resuming by Michel

Michel
Thu Jun 12 16:42:52 PDT 2008

Build a debug kernel and enable all PM (power manager) zones. Suspend
the device, resume it and post the relevant debug messages.

The PM has very good debug trace in it, and it will definitely point you
to the problem.

Also read & understand the code at
\WINCEX00\PUBLIC\COMMON\OAK\DRIVERS\PM\PDD\DEFAULT\platform.cpp.
Understanding that code, together with the debug trace, will point you
in the right direction.


Good luck,

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

GuruCE Ltd.
Microsoft Embedded Partner
http://GuruCE.com
Consultancy, training and development services.

Bradley Remedios wrote:
> OS: Windows CE 6.0 R2
> Updates: Rollup and Jan 2008-Apr2008
> Arch: ARM
>
> Recently I've noticed that my display driver is not always powering up
> after coming out of sleep mode. Through some debugging I've Noticed
> that one of three scenarios are occurring when resuming from sleep /
> suspend mode. Of these, only one situation results in a success
> setup.
>
> When everything is working the Display Driver's DrvEscape routine
> (overloaded from DDGPE) gets a Power Request to move to D3 (Suspend)
> where it stays until the system is requested to power up. At this
> time it gets a request to transition to D2 (Standby) followed by
> another request to move to D1 (Low On.)
>
> In one of the situations that fails, it behaves exactly like the
> Success case except the final call into Power State D1 never arrives
> (or any other power state.)
>
> In the final failure situation after getting a power state change to
> D2 it receives a power state change to D4 (Shutdown) instead of D1 or
> D0.
>
> I am also using the Default Power Manager, with all Timeouts set to 0
> (Disabled) (AC/Batt User/System/Suspend)
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power
> DisableGWESPowerOff=1
> ScreenPowerOff=0
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\States
> (These are Keys with the default value)
> On=D0
> ColdReboot=D4
> Reboot=D4
> Resuming=D2
> Suspend=D3
> SystemIdle=D2
> UserIdle=D1
>
> SystemIdle has the Display Class ID with D4
> Suspend has the NDIS Class ID with D4.
>
> Thank you, any help is appreciated.
> Brad.

Re: Display Driver's DrvEscape gets inconsistent Power States Resuming from Suspend Mode by Tom

Tom
Thu Jun 12 17:34:02 PDT 2008

Also, assuming you are waking as a result of a power button, failure
to return to the full on power state might be caused by your keypad
driver not calling PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0). This
can result in the system remaining in the lower power state until a
timeout or other external event results in a transition to a different
state.

This link discusses the above mentioned API and the
PPN_POWERBUTTONPRESSED notification -
http://msdn.microsoft.com/en-us/library/bb154521.aspx

Of the reference BSPs included with Platform Builder, only the
OMAP2420 BSP does this.

Tom


On Thu, 12 Jun 2008 16:27:53 -0700 (PDT), Bradley Remedios
<bremedios@gmail.com> wrote:

>OS: Windows CE 6.0 R2
>Updates: Rollup and Jan 2008-Apr2008
>Arch: ARM
>
>Recently I've noticed that my display driver is not always powering up
>after coming out of sleep mode. Through some debugging I've Noticed
>that one of three scenarios are occurring when resuming from sleep /
>suspend mode. Of these, only one situation results in a success
>setup.
>
>When everything is working the Display Driver's DrvEscape routine
>(overloaded from DDGPE) gets a Power Request to move to D3 (Suspend)
>where it stays until the system is requested to power up. At this
>time it gets a request to transition to D2 (Standby) followed by
>another request to move to D1 (Low On.)
>
>In one of the situations that fails, it behaves exactly like the
>Success case except the final call into Power State D1 never arrives
>(or any other power state.)
>
>In the final failure situation after getting a power state change to
>D2 it receives a power state change to D4 (Shutdown) instead of D1 or
>D0.
>
>I am also using the Default Power Manager, with all Timeouts set to 0
>(Disabled) (AC/Batt User/System/Suspend)
>
>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power
> DisableGWESPowerOff=1
> ScreenPowerOff=0
>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\States
> (These are Keys with the default value)
> On=D0
> ColdReboot=D4
> Reboot=D4
> Resuming=D2
> Suspend=D3
> SystemIdle=D2
> UserIdle=D1
>
>SystemIdle has the Display Class ID with D4
>Suspend has the NDIS Class ID with D4.
>
>Thank you, any help is appreciated.
>Brad.

Re: Display Driver's DrvEscape gets inconsistent Power States by Bradley

Bradley
Fri Jun 13 09:28:09 PDT 2008

On Jun 12, 4:42 pm, "Michel Verhagen (eMVP)" <mic...@nospam.box>
wrote:
> Build a debug kernel and enable all PM (power manager) zones. Suspend
> the device, resume it and post the relevant debug messages.

I did a debug build earlier with the default debug zones but nothing
out of the ordinary came out the port. I'll reload a debug build on
the device and enable all of the debug zones and will post again.

Power Manager Output:
Bailing on save bits because someone has an open DC!
Powering Off System
Calling GWES power proc.
Calling device manager power proc
Calling OEMPowerOff...
Returning to normally scheduled programming.
[System Suspended]
Back from OEMPowerOff
Calling device manager power proc
Calling GWES power proc.
Returning to normally scheduled programming.
Back from PowerOffSystem.
Multiple Event happens during SentSystemPowerState 0, Event will
evaluated in new state.

Thank you,
Brad.

Re: Display Driver's DrvEscape gets inconsistent Power States by Bradley

Bradley
Fri Jun 13 09:30:24 PDT 2008

On Jun 12, 5:34 pm, "Tom Gensel (eMVP)"
<tgensel.at.ptgsystems.dot.com> wrote:
> Also, assuming you are waking as a result of a power button, failure
> to return to the full on power state might be caused by your keypad
> driver not calling PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0). This
> can result in the system remaining in the lower power state until a
> timeout or other external event results in a transition to a different
> state.

We don't have a power button on our device, however we are using two
methods to test the wakeup. The first method is using a Keypad, and
the Second method is using the RTC Alarm and a Time Notification
Event.

I'll take a look at that API and see what happens.

> Of the reference BSPs included with Platform Builder, only the
> OMAP2420 BSP does this.

Thank you,
Brad.

Re: Display Driver's DrvEscape gets inconsistent Power States by Bradley

Bradley
Wed Jun 18 09:42:50 PDT 2008

I just wanted to followup on the list as I have found the solution.

The problem was actually in the registry, by default the OS comes
configured to have a Power State for Display Class Guids of D4 for the
SystemIdle state. So whenever the platform resumed from suspend and
entered SystemIdle it would send the D4 notification to the Display
Driver. I've changed SystemIdle to be D1 in the registry and this has
fixed our problems.

Thanks to everyone who took a look at the problem and provided
suggestions.
Brad.

On Jun 13, 9:28 am, Bradley Remedios <bremed...@gmail.com> wrote:
> On Jun 12, 4:42 pm, "Michel Verhagen (eMVP)" <mic...@nospam.box>
> wrote:
>
> > Build a debug kernel and enable all PM (power manager) zones. Suspend
> > the device, resume it and post the relevant debug messages.
>
> I did a debug build earlier with the default debug zones but nothing
> out of the ordinary came out the port. I'll reload a debug build on
> the device and enable all of the debug zones and will post again.
>
> Power Manager Output:
> Bailing on save bits because someone has an open DC!
> Powering Off System
> Calling GWES power proc.
> Calling device manager power proc
> Calling OEMPowerOff...
> Returning to normally scheduled programming.
> [System Suspended]
> Back from OEMPowerOff
> Calling device manager power proc
> Calling GWES power proc.
> Returning to normally scheduled programming.
> Back from PowerOffSystem.
> Multiple Event happens during SentSystemPowerState 0, Event will
> evaluated in new state.
>
> Thank you,
> Brad.