Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes:
> On Mon, 30 Nov 2009, Dmitry Torokhov wrote:
>
>> On Sun, Nov 29, 2009 at 11:04:57AM -0500, Alan Stern wrote:
>>
>>> On Sun, 29 Nov 2009, Ferenc Wagner wrote:
>>>
>>>> I thought we'd better ask our friends over at linux-pm, if they've got
>>>> some interface for this task. To summarize: an embedded application
>>>> wants to go into a "locked" state, where some input devices (gpio keys
>>>> in this case) are "muted", ie. they don't even generate interrupts to
>>>> minimize power consumption. This could be solved by adding a new
>>>> interface to gpio-keys, but the problem seems more general, so I wonder
>>>> if something like the USB selective runtime suspend is already available
>>>> (or preferable to develop) for such tasks.
>>>
>>> See Documentation/power/runtime_pm.txt. I don't know to what extent
>>> the input layer has implemented any runtime PM.
>>
>> Input layer is not implementing any PM since it consists of virtual, not
>> physical devices, and leaves PM for the appropriate bus drivers (USB,
>> serio, platform, etc.).
>>
>> Also, it is not really runtime PM but rather user-initiated action of
>> putting device into lower power state we are talking about here.
>
> This is in fact the definition of runtime PM -- except for the
> "user-initiated" restriction (runtime PM can be initiated by anything
> or anybody). So it really _is_ runtime PM.
But runtime-pm.txt says for example:
Generally, remote wake-up should be enabled for all input devices
put into a low power state at run time.
But in this case the requirement is to suppress input events from a
given device, effectively muting and putting it into low power state,
even though it's still open by some other parties. Runtime PM, on the
other hand tries not to interfere with the normal usage of the device.
Later:
(3) ->runtime_idle() and ->runtime_suspend() can only be executed for a
device the usage counter of which is equal to zero _and_ [...]
which underlines the difference again: the usage counter (defined by
common sense) won't be zero in our case, because the device is
constantly kept open, while we want to mute it, putting it into a low
power state. Probably, the rules could be bent so that the platform bus
could suspend these devices and achieve our aim, but I'd consider that
an abuse of the runtime PM infrastructure. Don't you?
Actually, this could be implemented by the various users cooperating in
closing the device, letting it go to sleep automatically. But this
requires strictly cooperating parties and is more complicated that
flipping some master switch of the device. We're looking for this
master switch, before needlessly building our own.
> But if you prefer to implement it without using the runtime PM
> framework, that's fine.
We're also looking for a framework to implement it in. Now I feel like
the runtime PM framework is not a good fit for what we want, but it's
the first time I'm reading its documentation, so please correct my
misunderstandings. That's why I cross posted linux-pm, after all. :)
--
Thanks,
Feri.
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
