RE: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Sorry to be jumping in late. My few comments dispersed with
individual replies

>-----Original Message-----
>From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx]
>Sent: Tuesday, October 12, 2010 3:39 AM
>
>
>I do not believe there is a generic answer - different devices,
>different options. For example I could see buttons split into 2 groups -
>"important" ones that bring the system from sleep or "stupor" and "not
>so important" that gets to be ignored. Or user woudl need to "flick"
>the screen. Or toss the phone into a corner cussing :)
>

Yes. At least on the U8500 (and couple of OMAPs as well), it is the 
always-on power button on AB8500/TWLs that is the necessary event 
to turn off the display/keypad. The entire display/keypad themselves
cannot wakeup the system. But on the older phones, we generally had
to have the menu + star combination to unlock the phone, which falls into
the main keypad.

>The point is that there seems to be a need for kicking devices into low
>power mode and I woudl like to have generic interface for that,
>preferrably reusing (as far as kernel drivers go) existing PM
>infrastructure.

Coming in late, I would just like to summarize some of the points; please
correct if I am wrong:

- user space intervention is required to communicate specific events
  to individual devices to put them into an appropriate power state.

- auto suspend isn't the correct choice for input devices as they may
  conflict with system suspend (touch screen off/idle needs to be sync'ed
  with system suspend as with a lock switch)

- PM ATM doesn't provide a sysfs attribute for enabling/disabling or forcing
  an individual device into low power mode unlike for platform. However a new
  "suspend_ondemand" flag can enable such devices to be put into appropriate
  states via a /sys/devices/.../power/ by the user space.

If my above summarization is correct, I personally feel the on demand flag is a clean
option for the current requirement.

Cheers!
Sundar
--
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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux