Re: [RFD] Automatic suspend

[Arve Hjønnevåg]

On Sat, Feb 21, 2009 at 12:20 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> On Saturday 21 February 2009, Arve Hjønnevåg wrote:
>> On Sat, Feb 21, 2009 at 1:47 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> > On Saturday 21 February 2009, Arve Hjønnevåg wrote:
>> >> On Fri, Feb 20, 2009 at 3:57 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> >> > On Saturday 21 February 2009, Arve Hjønnevåg wrote:
>> >> >> On Fri, Feb 20, 2009 at 7:56 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> >> >> > On Friday 20 February 2009, Arve Hjønnevåg wrote:
>> >> >> >> On Fri, Feb 20, 2009 at 2:49 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> >> >> >> > On Friday 20 February 2009, Arve Hjønnevåg wrote:
>> >> >> >> >> On Thu, Feb 19, 2009 at 2:08 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> [--snip--]
>> >> > The idea is to have both /sys/power/state and /sys/power/sleep at the same
>> >> > time, where /sys/power/state will work just like it does right now.  Sure,
>> >> > there must be mutual exclusion between the two, but that's a matter of
>> >> > implementation IMO.
>> >>
>> >> If you want to only prevent suspend though one interface, you have to
>> >> also pass information to the driver about its suspend hook is being
>> >> called so it can conditionally return -EBUSY. The wakelock interface
>> >> requires less code in each driver.
>> >
>> > Well, I don't think so.  Moreover, it requires you to spread wakelocks all
>> > over the place if you don't use the timeouted ones which, let's face it, is
>> > hardly acceptable.
>>
>> Your method does not reduce the number of places that has to be
>> modified. Any component where we add a wakelock, you have to add a
>> suspend handler to abort suspend when we would have held a wakelock.
>
> Well, maybe not, but it doesn't introduce entirely new API for device drivers.
> Instead, it extends the existing interfaces which I think is more appropriate.

The existing interfaces require polling. I don't think extending these
interfaces to make the polling faster is a better solution than adding
an interface to avoid polling.

Also, with your solution, how would you modify evdev.c to prevent
suspend while the event queue is not empty. This code does not have
any suspend hooks and the queue is not tied to any thread.

-- 
Arve Hjønnevåg
--
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/