> Sigh. No. Forced suspend is a fact of life
'Fact of life' isn't a useful reasoning basis. It tells me nothing about
how you got to that pronouncement.
> Drivers should enable wakeups before they disable interrupts. So either
> the packet hits the IRQ handler and the driver takes a suspend block
> (aborting suspend in the process) or it doesn't, the GPE goes high and
> the system resumes immediately after entering S3.
>
> > Set wake flags
> > Check if idle
> > If idle
> > Suspend
> > else
> > Clear wake flags
> > Unwind
> >
> > and the wake flags guarantee that an event at any point after the wake
> > flags are set until they are cleared will cause a suspend to be resumed,
> > possibly immediately after the suspend.
>
> Exactly. So the 5 nanosecond case is already handled. The interesting
> case is where userspace makes the decision to go to sleep and starts
> performing various housekeeping tasks before triggering the suspend. You
> need some way to abort that suspend.
See above. You can't always abort the suspend you may have to go full
circle. Not only that but the exactly algorithm above can be applied
user to kernel as well as kernel to hardware.
Given your average app author I think I'd rather just run their suspend
then their resume handling back to back anyway because it's a single
tested code path, while half way through cases in apps will *never* get
tested or work properly.
So I guess if you are driving this rom user space (which I take it you
are given you talk about housekeeping)
foreach app we need to suspend
kick app to suspend (signal)
(policy) kick harder if needed (SIGSTOP/bitch/shall I
kill it dialogue)
rendezvous (apps now all sleeping or dead)
X
if (we still want to suspend) {
prod kernel
kernel suspends
kernel resumes
}
resume all the apps
The important msising bit from that is 'set wake flags'.
Now what actually happens here beyond point X. Any event that gets kernel
processed moves the task into RUNNING. Any event that occurs after that
point causes the hardware to go suspend/resume. If not the driver is
buggy.
Now replace "kernel suspends" with "let the kernel know it can drop into
suspend level idle". The power management code will handle the races
beyond point X for you.
So for that you simply need a constraint to remain above suspend level
idle that you drop where it says "prod kernel" and pick up on "resume"
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
