From: Brian Swetland on
On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern(a)rowland.harvard.edu> 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.
>
>        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.
>
>        When the user program finishes processing the event, it
>        releases its suspend blocker.  Now the system can go back to
>        sleep.
>
> 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.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on
* Brian Swetland <swetland(a)google.com> [100505 14:34]:
> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern(a)rowland.harvard.edu> 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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on
On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony(a)atomide.com> wrote:
> * Brian Swetland <swetland(a)google.com> [100505 14:34]:
>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern(a)rowland.harvard.edu> 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.

We actually are trying to suspend all the time -- that's our basic
model -- suspend whenever we can when something doesn't prevent it.

>> > 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?

How often would we retry suspending?

If we fail to suspend, don't we have to resume all the drivers that
suspended before the one that failed? (Maybe I'm mistaken here)

With the suspend block model we know the moment we're capable of
suspending and then can suspend at that moment. Continually trying to
suspend seems like it'd be inefficient power-wise (we're going to be
doing a lot more work as we try to suspend over and over, or we're
going to retry after a timeout and spend extra time not suspended).

We can often spend minutes (possibly many) at a time preventing
suspend when the system is doing work that would be interrupted by a
full suspend.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on
* Brian Swetland <swetland(a)google.com> [100505 16:51]:
> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony(a)atomide.com> wrote:
> > * Brian Swetland <swetland(a)google.com> [100505 14:34]:
> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern(a)rowland.harvard.edu> 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.
>
> We actually are trying to suspend all the time -- that's our basic
> model -- suspend whenever we can when something doesn't prevent it.

Maybe that state could be kept in some userspace suspend policy manager?

> >> > 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?
>
> How often would we retry suspending?

Well based on some timer, the same way the screen blanks? Or five
seconds of no audio play? So if the suspend fails, then reset whatever
userspace suspend policy timers.

> If we fail to suspend, don't we have to resume all the drivers that
> suspended before the one that failed? (Maybe I'm mistaken here)

Sure, but I guess that should be a rare event that only happens when
you try to suspend and something interrupts the suspend.

> With the suspend block model we know the moment we're capable of
> suspending and then can suspend at that moment. Continually trying to
> suspend seems like it'd be inefficient power-wise (we're going to be
> doing a lot more work as we try to suspend over and over, or we're
> going to retry after a timeout and spend extra time not suspended).
>
> We can often spend minutes (possibly many) at a time preventing
> suspend when the system is doing work that would be interrupted by a
> full suspend.

Maybe you a userspace suspend policy manager would do the trick if
it knows when the screen is blanked and no audio has been played for
five seconds etc?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on
On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren <tony(a)atomide.com> wrote:
> * Brian Swetland <swetland(a)google.com> [100505 16:51]:
>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony(a)atomide.com> wrote:
>> > * Brian Swetland <swetland(a)google.com> [100505 14:34]:
>> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern(a)rowland.harvard.edu> 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.
>>
>> We actually are trying to suspend all the time -- that's our basic
>> model -- suspend whenever we can when something doesn't prevent it.
>
> Maybe that state could be kept in some userspace suspend policy manager?
>
>> >> > 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?
>>
>> How often would we retry suspending?
>
> Well based on some timer, the same way the screen blanks? Or five
> seconds of no audio play? So if the suspend fails, then reset whatever
> userspace suspend policy timers.
>
>> If we fail to suspend, don't we have to resume all the drivers that
>> suspended before the one that failed? �(Maybe I'm mistaken here)
>
> Sure, but I guess that should be a rare event that only happens when
> you try to suspend and something interrupts the suspend.
>

This is not a rare event. For example, the matrix keypad driver blocks
suspend when a key is down so it can scan the matrix.

>> With the suspend block model we know the moment we're capable of
>> suspending and then can suspend at that moment. �Continually trying to
>> suspend seems like it'd be inefficient power-wise (we're going to be
>> doing a lot more work as we try to suspend over and over, or we're
>> going to retry after a timeout and spend extra time not suspended).
>>
>> We can often spend minutes (possibly many) at a time preventing
>> suspend when the system is doing work that would be interrupted by a
>> full suspend.
>
> Maybe you a userspace suspend policy manager would do the trick if
> it knows when the screen is blanked and no audio has been played for
> five seconds etc?
>

If user space has to initiate every suspend attempt, then you are
forcing it to poll whenever a driver needs to block suspend.

--
Arve Hj�nnev�g
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/