Thread (36 messages) flat view 36 messages, 6 authors, 2011-10-13

Re: [PATCH V3] input: Fix USB autosuspend on bcm5974

From: Oliver Neukum <oliver@neukum.org>
Date: 2011-10-11 11:09:03

Am Dienstag, 11. Oktober 2011, 13:04:21 schrieb Henrik Rydberg:
On Tue, Oct 11, 2011 at 06:10:12AM +0200, Oliver Neukum wrote:
quoted
Am Dienstag, 11. Oktober 2011, 02:11:03 schrieb Matthew Garrett:
quoted
Ah, right, sorry - I wasn't trying to use the device after it had been 
closed. In an ideal world we'd really want to be able to indicate that 
we don't want a remote wakeup in that situation. Otherwise, the patch 
looks good. Thank you!
It looks like we had exactly that capability until
48826626263d4a61d06fd8c5805da31f925aefa0
removed it.
Hm. Throwing in another related question below.

Problem: the hid keyboard driver refuses to suspend while a key is
pressed, which is fine per se, but there is no indication presented to the power layer,
resulting in a failed suspend and (due to complex reasons it seems) disabled autosuspend.
That is a bug. Autosuspend at a later date should happen.
Question:  If the hid interrupt handler were to actually prevent
suspend during keypress, what would be the natural way to do it?
Firstly we must prevent autosuspension when a key is pressed
because most keyboards do not generate a wakeup upon key release
which is then lost.

Secondly a key pres triggers the mark_busy. We could do an async
get on every key press and an async put on every key release. But you
cannot beat the principal race here because the operation happen
in interrupt and must therefore be async. You must be prepared for
the window to be hit and return an error code.

	Regards
		Oliver
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help