[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <p2jd6200be21005061953y497b0766k15123f69ff7db630@mail.gmail.com>
Date: Thu, 6 May 2010 19:53:02 -0700
From: Arve Hjønnevåg <arve@...roid.com>
To: James Kosin <james.kosin.04@....edu>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.
On Thu, May 6, 2010 at 7:41 PM, James Kosin <james.kosin.04@....edu> wrote:
> On 5/5/2010 8:10 PM, Tony Lindgren wrote:
>> * Brian Swetland <swetland@...gle.com> [100505 16:51]:
>>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@...mide.com> wrote:
>>>> * Brian Swetland <swetland@...gle.com> [100505 14:34]:
>>>>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> <<-- snip -->>
>>>>>> 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.
>
One if the benefit we get from using suspend is that an unprivileged
app that does not have access to suspend blockers cannot prevent
suspend. You lose this advantage if you trigger suspend only from the
idle task.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists