> > > The changes look good to me.
> >
> > They feel unfinished to me though. :)
> >
> > Like using "jiffies" instead of a clocksource, which makes trouble
> > since the timing covers periods with IRQs disabled. And the test
> > mode parameter needs work.
>
> Well, I'd say that timing has bigger problem, right?
>
> It is
>
> set alarm
> suspend system
> | poweroff
> alarm expires
> system resumes
>
> ... so you are measuring resume time + sleep time, no?
There's no "poweroff" step when entering STR or STANDBY!
But more specifically, I avoided that issue by comparing times between
(a) start and end of the "suspend devices" steps;
(b) start and end of the "resume devices" steps.
Example output, with the relevant lines highlighted by "*":
PM: test RTC wakeup from 'mem' suspend
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
PM: Entering mem sleep
Suspending console(s)
* PM: suspend devices took 0.000 seconds
GPIO-A may wake for 00080000
GPIO-C may wake for 00000008
GPIO-D may wake for 00000020
AT91: PM - wake mask 00000036, pm state 3
AT91: PM - no slow clock mode yet ...
AT91: PM - wakeup 00000002
* PM: resume devices took 0.132 seconds
PM: Finishing wakeup.
Restarting tasks ... done.
The underlying clocksource has resolution of 32 KiHz, while HZ=128;
the "suspend" more typically reports 7 msec. And there should be a
few more wakeup GPIOs, except I seem to not have enabled gpio_keys.
That "wakeup 00000002" means the heavily-overloaded "system" IRQ
woke the system ... the RTC is on that IRQ line.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
