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@xxxxxxxxxxxxxx] > >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
