Re: [RFC] input: syfs switches for SKE keypad

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Wed, Oct 06, 2010 at 05:11:07PM +0530, Trilok Soni wrote:
> Hi Samu,
> 
> On 10/6/2010 3:18 PM, Onkalo Samu wrote:
> > On Wed, 2010-10-06 at 10:56 +0200, ext Sundar R IYER wrote:
> >> Hi,
> >>
> >>> -----Original Message-----
> >>> From: Trilok Soni [mailto:tsoni@codeaurora.org]
> >>> Sent: Wednesday, October 06, 2010 2:02 PM
> >>>
> >>> I agree with Dmitry. Meego people or you should explain the real end-to-end
> >>> usecase first. Why it can't fit anywhere else?
> >>
> >> I don't know the full details; but what I can think of (or did I read it somewhere?)
> >> is events like phones with slider keypad; you can power save keypad controller
> >> when the keypad is not active. And these events are probably issued from the user
> >> space to the kernel and that's why the requirement probably. And I do remember
> >> Samu mentioning about unwanted wakeup events which were avoided via these switches.
> >>
> >> Adding Samu who can explain more on this.
> > 
> > This is how I see this issue
> > 
> > I tried to push enable / disable entries to generic input layer to avoid
> > driver specific controls. That was not accepted.
> > 
> > The need for keypad locking is not following any global PM transition.
> > In phones (like N900), global suspend / resume is not used at all. Phone
> > is running all the time. For example phone must be able to handle
> > incoming calls all the time. Instead suspend / resume, system is in deep
> > idle state as much as possible. Wake up from that takes couple of
> > milliseconds and everything is running again. Powers, clocks and any
> > extra activity must be turned off when ever possile depending on the
> > overall system state.
> > 
> > For input devices this means that keypad, touch controller etc. are
> > turned off or partially disabled for example when the screen is blanked.
> > Meanwhile system may still have other activity ongoing like mp3
> > playback. When the screen is off, there must be some way to tell to
> > touch controller that please turn off and save some power.

So exactly like I was saying it is all about the PM and thus input layer
is really the wrong place to solve this.

> >  This not
> > following pm transitions.

What do you mean? It may not follow system-whide PM transtitions but it
is per-device PM transition that I believe everyone wants to have
support for. You shut off devices individually and in subtrees when they
are not in use/needed.

> >  On the other hand, disable entry may trig
> > pm_runtime suspend transifion for that device.
> > 
> 
> I think what you are referring is similar to Android specific early suspend/resume
> framework. For example, what is the use of TS (if not used as wakeup) resources
> when the screen goes blank, so better to early suspend it rather than waiting
> upto the platform suspend to happen.
> 
> I think this can be solved with pm_runtime, isn't it? Though I am not expert
> at pm_runtime, but this framework can be explored to enable these features.

I think last time Rafael mentioned that runtime PM did not allow for
forcing power state from userspace but I wonder if it would be possible
for userspace to signal and "accelerate" the idle state for a device and
then standard runtime PM framework would kick in...

-- 
Dmitry