Thread (8 messages) 8 messages, 5 authors, 2014-07-07

Re: [PATCH] gpio_keys, twl4030-pwrbutton: stay awake for 1sec on resume

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2014-06-28 21:58:42
Also in: lkml

On Sat, 28 Jun 2014, Pavel Machek wrote:
Hi!
quoted
quoted
quoted
This gives the userspace (Replicant) a chance to fully handle the
pm_wakeup_event, before autosleep suspends the system alltogether
again.

This fixes suspend/resume on the OpenPhoenux GTA04, in combination with
the Replicant 4.2.2 userspace, which needs to execute this to stay
awake: 'echo on > /sys/power/state'

Signed-off-by: Lukas M�rdian <redacted>
Signed-off-by: H. Nikolaus Schaller <redacted>
I'm sorry, but we should not be doing this.

You basically put a delay in driver to work around userspace bug.
Do you think it is a user-space bug if the kernel goes to sleep again
before giving user space any chance to react to an event?
Well, who says 1000msec is enough? Some userspace may need
more. ... for example on PC when you keyboard-handling deamon is
swapped out.
quoted
And the msec parameter is described as:

@msec: Anticipated event processing time (in milliseconds).

Isn't calling pm_wakeup_event() with a non-zero msec the standard
method to handle this situation? And it is used in other drivers. E.g. in
_mmc_detect_change() or hub_suspend().
 * Notify the PM core of a wakeup event whose source is @ws that will
   take                    
 * approximately @msec milliseconds to be processed by the kernel.  If
   @ws is                 
 * not active, activate it.  If @msec is nonzero, set up the @ws'
   timer to                    
 * execute pm_wakeup_timer_fn() in future.                                                    

Will take @msec milliseconds to be processed by the _kernel_. Yes, USB
probing takes a lot of time in kernel. But you are using this
parameter to wait for userspace...
quoted
quoted
There must be better
solution....
 
I am not sure how it could look like.
Rafael, do you have any idea how this is supposed to work?

Original patch is at https://lkml.org/lkml/2014/4/10/156 .
One possibility is not to use autosleep at all.  The user program,
instead of writing "on" to /sys/power/state to stay awake, would have
to write "mem" to go to sleep when no more work remained to be handled.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help