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

[Trilok Soni <tsoni@codeaurora.org>]

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. This not
> following pm transitions. 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.

---Trilok Soni

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.