Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

[Tony Lindgren]

* Brian Swetland <swetland@xxxxxxxxxx> [100505 14:34]:
> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> Oh, like tell the modem that user mode has handled the ring event and
> >> its ok to un-block?
> >
> > No, that's not how it works. ÂIt would go like this:
> >
> > Â Â Â ÂThe modem IRQ handler queues its event to the input subsystem.
> > Â Â Â ÂAs it does so the input subsystem enables a suspend blocker,
> > Â Â Â Âcausing the system to stay awake after the IRQ is done.

How about instead the modem driver fails to suspend until it's done?

Each driver could have a suspend_policy sysfs entry with options such
as [ forced | safe ]. The default would be forced. Forced would
be the current behaviour, while safe would refuse suspend until the
driver is done processing.

> > Â Â Â ÂThe user program enables its own suspend blocker before reading
> > Â Â Â Âthe input queue. ÂWhen the queue is empty, the input subsystem
> > Â Â Â Âreleases its suspend blocker.

And also the input layer could refuse to suspend until it's done.

> > Â Â Â ÂWhen the user program finishes processing the event, it
> > Â Â Â Âreleases its suspend blocker. ÂNow the system can go back to
> > Â Â Â Âsleep.

And here the user space just tries to suspend again when it's done?
It's not like you're trying to suspend all the time, so it should be
OK to retry a few times.

> > At no point does the user program have to communicate anything to the
> > modem driver, and at no point does it have to do anything out of the
> > ordinary except to enable and disable a suspend blocker.
> 
> Exactly -- and you can use the same style of overlapping suspend
> blockers with other drivers than input, if the input interface is not
> suitable for the particular interaction.

Would the suspend blockers still be needed somewhere in the example
above?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/