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

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

 



>-----Original Message-----
>From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx]
>>
>> This isn't *really* about saving power in the individual device; it's
>> more about stopping the device generating events that disrupt the rest
>> of the system.  Suspending the device can be one way of doing that and
>> is useful if it can be done but is not really the immediate goal here.
>
>Runtime PM is _not_ a reliable way of preventing a device from
>generating events.  It is meant for saving energy, nothing else.
>
>If that's what this is about, then the answer is simple: Don't use
>runtime PM to try to suppress events.
>

I think it is unfair to discriminate here about saving power and turning off
events. I believe putting the device into power save leads to, if device permits
preventing generating events is valid to hook up run time PM.

>-----Original Message-----
>From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx]
>
>I still disagree.  The user should be able to tell the driver that he's
>not going to be using the keypad, touch panel, or whatever in the near
>future... but it's up the driver to decide whether or not to go to low
>power.

Why cannot the driver decide to return failure in such a case? But why stop
the user space from requesting a power save mode?

>> Hmm. I was looking at the case with touch screen. I set my display backlight
>> to go off after say 30 seconds; my touch screen idle begins only when the
>display
>> goes off; meaning I still expect the touch screen to respond to any events before
>> the timeout. This in turn requires that the timeouts for the backlight and the touch
>> be synchronized, failing which the user might interpret the touch to be non-
>functional
>> in case the touch timeout and backlight timeout vary. Am I wrong to think that
>> such inter-dependency between devices should be avoided?
>
>Although such dependencies do sometimes make things awkward,
>occasionally you need to have them.  

Hmmm...I am not convinced that such sync'ed timeouts between devices are necessary;
I still prefer it would be better if a single user space monitor could make sure that all listed
devices are communicated for a power save rather than introduce dependencies between a
touch and the display device.

I was thinking about an another case too where device autosuspend could create issues: Imagine
a slider cover for the camera which enables the camera and the live playback on a screen; In such 
a case you have now not 2, but 3 components to sync up: the auto idle for touch, auto idle for camera;
auto idle for the display. 

Cheers!
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux