Re: [PATCH] Input: Add ioctl to block suspend while event queue isnot empty.

[Arve Hjønnevåg]

2012/2/11 Rafael J. Wysocki <rjw@xxxxxxx>:
> Hi,
>
> On Saturday, January 21, 2012, Arve Hjønnevåg wrote:
>> Add an ioctl, EVIOCSSUSPENDBLOCK, to block suspend while the event
>> queue is not empty. This allows userspace code to process input
>> events while the device appears to be asleep.
>
> I have two questions to start with, if you don't mind:
>
> (1) Does Android user space use an analogous interface right now or is it
>    a prototype?
>

Yes (for the next version), but with a wakelock based implementation.

> (2) What exactly are the use cases for it (ie. what problem does it address
>    that cannot be addressed in a different way)?
>

The reason for adding an ioctl versus the old android version with
used a wakelock for all input events, is that not all input events are
wakeup events. Specifically some sensors generate input events at such
a high rate that they prevent suspend while the sensor is on even
though the driver has a suspend hook that turns the sensor off.

If you are asking why input events need to block suspend at all, this
was the example used in the suspend blocker documentation:
- The Keypad driver gets an interrupt. It then calls suspend_block on the
  keypad-scan suspend_blocker and starts scanning the keypad matrix.
- The keypad-scan code detects a key change and reports it to the input-event
  driver.
- The input-event driver sees the key change, enqueues an event, and calls
  suspend_block on the input-event-queue suspend_blocker.
- The keypad-scan code detects that no keys are held and calls suspend_unblock
  on the keypad-scan suspend_blocker.
- The user-space input-event thread returns from select/poll, calls
  suspend_block on the process-input-events suspend_blocker and then calls read
  on the input-event device.
- The input-event driver dequeues the key-event and, since the queue is now
  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
- The user-space input-event thread returns from read. If it determines that
  the key should be ignored, it calls suspend_unblock on the
  process_input_events suspend_blocker and then calls select or poll. The
  system will automatically suspend again, since now no suspend blockers are
  active.


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