On 5/5/2010 8:10 PM, Tony Lindgren wrote:
quoted text
> * Brian Swetland <swetland@google.com> [100505 16:51]:
>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Brian Swetland <swetland@google.com> [100505 14:34]:
>>>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
<<-- snip -->>
quoted text
>>>>> 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.
>  

Tony,
Wouldn't this be handled by the idle task, or task manager?

When all tasks are suspended and not doing anything that should be the
first clue that a real suspend cycle could be attempted.

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