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

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

[Dmitry Torokhov]

Hi Sundar,

On Tue, Oct 05, 2010 at 06:54:42PM +0200, Sundar R IYER wrote:
> Hi Dmitry,
> 
> Meego folks have a requirement for dynamic sysfs switches
> for input drivers. I saw a patch from Samu (Nokia) for the same but which
> lost its way out.  Here is a small modified patch set for the SKE
> driver *only* which completes this requirement and hence a question for
> you. (The idea is only a sysfs implemention; its not yet synced in with the
> mainline code)
> 
> Would you be okay to accept a stand-alone patch like the below for all the
> input drivers that we would be pushing in or do you have some comments
> or improvements suggested to be folded in the original patch set from Nokia,
> so that it can get through into the generic tree?

I am not the biggest fan of such solution and I would prefer having this
facility on a more generic level, maybe tied in with a special for of PM
(something like user-controlled)?  Then most of the devices would simply
reuse existing suspend/resume hooks without the need to add more and
more pretty much duplicate code.

Thanks.

-- 
Dmitry

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

[Trilok Soni]

Hi Sundar,

On 10/5/2010 11:11 PM, Dmitry Torokhov wrote:
> Hi Sundar,
> 
> On Tue, Oct 05, 2010 at 06:54:42PM +0200, Sundar R IYER wrote:
>> Hi Dmitry,
>>
>> Meego folks have a requirement for dynamic sysfs switches
>> for input drivers. I saw a patch from Samu (Nokia) for the same but which
>> lost its way out.  Here is a small modified patch set for the SKE
>> driver *only* which completes this requirement and hence a question for
>> you. (The idea is only a sysfs implemention; its not yet synced in with the
>> mainline code)
>>
>> Would you be okay to accept a stand-alone patch like the below for all the
>> input drivers that we would be pushing in or do you have some comments
>> or improvements suggested to be folded in the original patch set from Nokia,
>> so that it can get through into the generic tree?
> 
> I am not the biggest fan of such solution and I would prefer having this
> facility on a more generic level, maybe tied in with a special for of PM
> (something like user-controlled)?  Then most of the devices would simply
> reuse existing suspend/resume hooks without the need to add more and
> more pretty much duplicate code.

I agree with Dmitry. Meego people or you should explain the real end-to-end
usecase first. Why it can't fit anywhere else?

We should not fill in features very specific to userspace frameworks. I see lately
lot of Android and Meego specific bits into TS and Keypad drivers from many folks.

---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.

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

[Sundar R IYER]

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.

>We should not fill in features very specific to userspace frameworks. I see lately
>lot of Android and Meego specific bits into TS and Keypad drivers from many
>folks.
>

Yeah. IMO it is because people want to mainline and push out all drivers more and more;
And as of today most of these drivers and HW are tested and delivered on such frameworks :)

Regards,
Sundar

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

[Onkalo Samu]

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.

For mobile devices it is not acceptable to filter events away at some
upper SW layer depending on the system state. The HW which generates
those events may not generate events at all to allow longer CPU sleep
periods.

In ideal world it would be nice to control device states based on for
example user count. However, there are several listeners for input
devices and it is hard or impossible to have them all to follow overall
state transition (screen blanked etc.). Instead, there is some system
state controller in the userspace who is responsible to get all the HW
in the correct state. Separate disable / enable entries makes life much
easier.

Hopefully this clears out our point of view.

Regards,
Samu

> 
> >We should not fill in features very specific to userspace frameworks. I see lately
> >lot of Android and Meego specific bits into TS and Keypad drivers from many
> >folks.
> >
> 
> Yeah. IMO it is because people want to mainline and push out all drivers more and more;
> And as of today most of these drivers and HW are tested and delivered on such frameworks :)
> 
> Regards,
> Sundar
> 
> 

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

[Trilok Soni]

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.

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

[Sundar R IYER]

Hi Trilok,

>-----Original Message-----
>From: Trilok Soni [mailto:tsoni@codeaurora.org]
>
>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 no. IMO TS should be disabled only when the user decides to lock off
the phone or screen. This is independent of any suspend or early suspend operation.
As Samu said, lots of back ground operations might keep the CPU running.

>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.
>

Hmm. Yes. Even I think so; but I am not really sure if these run time helpers for
suspend/resume can be invoked from the user space. If I understand correctly, 
a event like a lock-key, keypad slider open/close or MMC slot door close/open
should trigger an event to user space, which can then force devices to suspend/resume.
If this is possible via these runtime_* helpers, then as Dmitry says, it would be up to
the user space to suspend/resume the device; we end up using a single helper for either
run time suspend or platform suspend. Maybe Rafael can comment here.

Regards,
Sundar

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

[Dmitry Torokhov]

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@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.

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

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

[Alan Stern]

On Wed, 6 Oct 2010, Dmitry Torokhov wrote:

> > 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...

Yes; drivers can implement their runtime power policy any way they
want.  For example, a driver could create a sysfs attribute file which
userspace could use to ask for changes in the power state.

The real question is whether the driver is platform-specific.  If it is 
then fine, it can do whatever it wants.  If it isn't then it should 
try to avoid doing things that are tied to a specific platform.

Alan Stern

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

[Dmitry Torokhov]

On Wednesday, October 06, 2010 09:19:13 am Alan Stern wrote:
> On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> > > 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...
> 
> Yes; drivers can implement their runtime power policy any way they
> want.  For example, a driver could create a sysfs attribute file which
> userspace could use to ask for changes in the power state.
> 
> The real question is whether the driver is platform-specific.  If it is
> then fine, it can do whatever it wants.  If it isn't then it should
> try to avoid doing things that are tied to a specific platform.
>

No, I really think it is wrong. This what leads us to the situation we
are in at the moment. Every device [re]implements  its own little knobs
to do power management. Accelerometers export their (often tailored to a
specific platform) attributes in sysfs in nonstandard way. And so on,
and so forth.

Here I'd like to see these (PM) hooks done on device core level, i.e.
the knobs should be unified and live in /sys/devices/.../deviceX/power/

Thanks.

-- 
Dmitry

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

[Alan Stern]

On Wed, 6 Oct 2010, Dmitry Torokhov wrote:

> > > 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...
> > 
> > Yes; drivers can implement their runtime power policy any way they
> > want.  For example, a driver could create a sysfs attribute file which
> > userspace could use to ask for changes in the power state.
> > 
> > The real question is whether the driver is platform-specific.  If it is
> > then fine, it can do whatever it wants.  If it isn't then it should
> > try to avoid doing things that are tied to a specific platform.
> >
> 
> No, I really think it is wrong. This what leads us to the situation we
> are in at the moment. Every device [re]implements  its own little knobs
> to do power management. Accelerometers export their (often tailored to a
> specific platform) attributes in sysfs in nonstandard way. And so on,
> and so forth.
> 
> Here I'd like to see these (PM) hooks done on device core level, i.e.
> the knobs should be unified and live in /sys/devices/.../deviceX/power/

I haven't followed this thread in detail.  What sort of knobs are you 
talking about?  That is, what needs to be done?  Maybe the PM core 
already provides these features.

Alan Stern

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

[Dmitry Torokhov]

On Wed, Oct 06, 2010 at 02:19:03PM -0400, Alan Stern wrote:
> On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> 
> > > > 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...
> > > 
> > > Yes; drivers can implement their runtime power policy any way they
> > > want.  For example, a driver could create a sysfs attribute file which
> > > userspace could use to ask for changes in the power state.
> > > 
> > > The real question is whether the driver is platform-specific.  If it is
> > > then fine, it can do whatever it wants.  If it isn't then it should
> > > try to avoid doing things that are tied to a specific platform.
> > >
> > 
> > No, I really think it is wrong. This what leads us to the situation we
> > are in at the moment. Every device [re]implements  its own little knobs
> > to do power management. Accelerometers export their (often tailored to a
> > specific platform) attributes in sysfs in nonstandard way. And so on,
> > and so forth.
> > 
> > Here I'd like to see these (PM) hooks done on device core level, i.e.
> > the knobs should be unified and live in /sys/devices/.../deviceX/power/
> 
> I haven't followed this thread in detail.  What sort of knobs are you 
> talking about?  That is, what needs to be done?  Maybe the PM core 
> already provides these features.
> 

Mobile folks wish to power down some devices (most often input -
touchscreen, keypad) under certain circumstances to save power.
So far they were doing that by adding "disable" hook to individual
drivers and while I did allow that in for some devices I feel that we
need more standardised solution, preferably one that could re-use
existing PM hooks in drivers.

-- 
Dmitry

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

[Alan Stern]

On Wed, 6 Oct 2010, Dmitry Torokhov wrote:

> On Wed, Oct 06, 2010 at 02:19:03PM -0400, Alan Stern wrote:
> > On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> > 
> > > > > 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...
> > > > 
> > > > Yes; drivers can implement their runtime power policy any way they
> > > > want.  For example, a driver could create a sysfs attribute file which
> > > > userspace could use to ask for changes in the power state.
> > > > 
> > > > The real question is whether the driver is platform-specific.  If it is
> > > > then fine, it can do whatever it wants.  If it isn't then it should
> > > > try to avoid doing things that are tied to a specific platform.
> > > >
> > > 
> > > No, I really think it is wrong. This what leads us to the situation we
> > > are in at the moment. Every device [re]implements  its own little knobs
> > > to do power management. Accelerometers export their (often tailored to a
> > > specific platform) attributes in sysfs in nonstandard way. And so on,
> > > and so forth.
> > > 
> > > Here I'd like to see these (PM) hooks done on device core level, i.e.
> > > the knobs should be unified and live in /sys/devices/.../deviceX/power/
> > 
> > I haven't followed this thread in detail.  What sort of knobs are you 
> > talking about?  That is, what needs to be done?  Maybe the PM core 
> > already provides these features.
> > 
> 
> Mobile folks wish to power down some devices (most often input -
> touchscreen, keypad) under certain circumstances to save power.
> So far they were doing that by adding "disable" hook to individual
> drivers and while I did allow that in for some devices I feel that we
> need more standardised solution, preferably one that could re-use
> existing PM hooks in drivers.

The OMAP people are working on exactly the same problem and are doing 
their best to solve it using the runtime PM framework.  There have been 
a couple of threads about it on the linux-pm mailing list:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-September/028689.html
https://lists.linux-foundation.org/pipermail/linux-pm/2010-September/028868.html

The question is not so much how the driver should be told to power-down
a device (the PM framework takes care of all that); it's how to
recognize when those "certain circumstances" occur.  Can this be done
by the kernel in a reasonably platform-independent way?  Or does the
kernel have to be told by userspace?  The PM framework supports both 
kinds of mechanism.

Alan Stern

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

[Rafael J. Wysocki]

On Wednesday, October 06, 2010, Dmitry Torokhov wrote:
> On Wed, Oct 06, 2010 at 02:19:03PM -0400, Alan Stern wrote:
> > On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> > 
> > > > > 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...
> > > > 
> > > > Yes; drivers can implement their runtime power policy any way they
> > > > want.  For example, a driver could create a sysfs attribute file which
> > > > userspace could use to ask for changes in the power state.
> > > > 
> > > > The real question is whether the driver is platform-specific.  If it is
> > > > then fine, it can do whatever it wants.  If it isn't then it should
> > > > try to avoid doing things that are tied to a specific platform.
> > > >
> > > 
> > > No, I really think it is wrong. This what leads us to the situation we
> > > are in at the moment. Every device [re]implements  its own little knobs
> > > to do power management. Accelerometers export their (often tailored to a
> > > specific platform) attributes in sysfs in nonstandard way. And so on,
> > > and so forth.
> > > 
> > > Here I'd like to see these (PM) hooks done on device core level, i.e.
> > > the knobs should be unified and live in /sys/devices/.../deviceX/power/
> > 
> > I haven't followed this thread in detail.  What sort of knobs are you 
> > talking about?  That is, what needs to be done?  Maybe the PM core 
> > already provides these features.
> > 
> 
> Mobile folks wish to power down some devices (most often input -
> touchscreen, keypad) under certain circumstances to save power.
> So far they were doing that by adding "disable" hook to individual
> drivers and while I did allow that in for some devices I feel that we
> need more standardised solution, preferably one that could re-use
> existing PM hooks in drivers.

There's no interface for that at the PM core level, but I think we should
add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
flag for drivers who want to make their suspend/resume callbacks to be
reachable directly from user space.  Setting that flag would enable a sysfs
attribute in /sys/devices/.../power/ allowing user space to invoke
pm_runtime_suspend() and pm_runtime_resume() for the given device.

Thanks,
Rafael

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

[Pavel Machek]

Hi!
 
> For mobile devices it is not acceptable to filter events away at some
> upper SW layer depending on the system state. The HW which generates
> those events may not generate events at all to allow longer CPU sleep
> periods.

Ok.

> In ideal world it would be nice to control device states based on for
> example user count. However, there are several listeners for input
> devices and it is hard or impossible to have them all to follow overall
> state transition (screen blanked etc.). Instead, there is some
> system

So you have mobile device; why is it impossible to just close the
device when you do not want the events? I guess it is hard for generic
distros, but on your phone, you should be able to modify Xserver to
close touchscreen/keypad device when it is not needed... right?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Ferenc Wagner]

Pavel Machek <pavel@ucw.cz> writes:

>> For mobile devices it is not acceptable to filter events away at some
>> upper SW layer depending on the system state. The HW which generates
>> those events may not generate events at all to allow longer CPU sleep
>> periods.
>
> Ok.
>
>> In ideal world it would be nice to control device states based on for
>> example user count. However, there are several listeners for input
>> devices and it is hard or impossible to have them all to follow overall
>> state transition (screen blanked etc.). Instead, there is some
>> system
>
> So you have mobile device; why is it impossible to just close the
> device when you do not want the events? I guess it is hard for generic
> distros, but on your phone, you should be able to modify Xserver to
> close touchscreen/keypad device when it is not needed... right?

We'd had this discussion before... cf. eg.
http://thread.gmane.org/gmane.linux.kernel.input/9266/focus=9767

The problem was that several processes may have a device open, while
another process should be able to control the state of the device.
Maybe this could be solved by making the controlling process a proxy,
and having all "user" processes going though it.  Then the controlling
(proxy) process could open/close the device as it wants, letting the
runtime PM do its job.  But this would mean duplicating some kernel
functionality (at least multiplexing) in user space.
-- 
Regards,
Feri.

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

[Pavel Machek]

Hi!

On Wed 2010-10-13 19:35:49, Ferenc Wagner wrote:
> Pavel Machek <pavel@ucw.cz> writes:
> 
> >> For mobile devices it is not acceptable to filter events away at some
> >> upper SW layer depending on the system state. The HW which generates
> >> those events may not generate events at all to allow longer CPU sleep
> >> periods.

Actually, I question this, too.

Obviously, touchscreen needs to be turned off, but how common are
accidental button presses?

> >> In ideal world it would be nice to control device states based on for
> >> example user count. However, there are several listeners for input
> >> devices and it is hard or impossible to have them all to follow overall
> >> state transition (screen blanked etc.). Instead, there is some
> >> system
> >
> > So you have mobile device; why is it impossible to just close the
> > device when you do not want the events? I guess it is hard for generic
> > distros, but on your phone, you should be able to modify Xserver to
> > close touchscreen/keypad device when it is not needed... right?
> 
> We'd had this discussion before... cf. eg.
> http://thread.gmane.org/gmane.linux.kernel.input/9266/focus=9767
> 
> The problem was that several processes may have a device open, while
> another process should be able to control the state of the device.
> Maybe this could be solved by making the controlling process a proxy,
> and having all "user" processes going though it.  Then the

Yes, and the proxy is normally called "X server". We already have it.

> (proxy) process could open/close the device as it wants, letting the
> runtime PM do its job.  But this would mean duplicating some kernel
> functionality (at least multiplexing) in user space.

Yes. We already do that.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Alan Stern]

On Wed, 6 Oct 2010, Rafael J. Wysocki wrote:

> > Mobile folks wish to power down some devices (most often input -
> > touchscreen, keypad) under certain circumstances to save power.
> > So far they were doing that by adding "disable" hook to individual
> > drivers and while I did allow that in for some devices I feel that we
> > need more standardised solution, preferably one that could re-use
> > existing PM hooks in drivers.
> 
> There's no interface for that at the PM core level, but I think we should
> add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
> flag for drivers who want to make their suspend/resume callbacks to be
> reachable directly from user space.  Setting that flag would enable a sysfs
> attribute in /sys/devices/.../power/ allowing user space to invoke
> pm_runtime_suspend() and pm_runtime_resume() for the given device.

We already have power/control.  If the subsystem sets it to "on" by 
default and the driver suspends the device whenever it is idle, then 
userspace can control the power level by writing "auto" or "on" to 
power/control.

Alan Stern

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

[Rafael J. Wysocki]

On Wednesday, October 06, 2010, Alan Stern wrote:
> On Wed, 6 Oct 2010, Rafael J. Wysocki wrote:
> 
> > > Mobile folks wish to power down some devices (most often input -
> > > touchscreen, keypad) under certain circumstances to save power.
> > > So far they were doing that by adding "disable" hook to individual
> > > drivers and while I did allow that in for some devices I feel that we
> > > need more standardised solution, preferably one that could re-use
> > > existing PM hooks in drivers.
> > 
> > There's no interface for that at the PM core level, but I think we should
> > add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
> > flag for drivers who want to make their suspend/resume callbacks to be
> > reachable directly from user space.  Setting that flag would enable a sysfs
> > attribute in /sys/devices/.../power/ allowing user space to invoke
> > pm_runtime_suspend() and pm_runtime_resume() for the given device.
> 
> We already have power/control.  If the subsystem sets it to "on" by 
> default and the driver suspends the device whenever it is idle, then 
> userspace can control the power level by writing "auto" or "on" to 
> power/control.

The problem is that with the 'auto' setting the driver decides when to suspend
and the driver need not know it's the right time.

Suspending a graphics adapter when the user presses a "turn screen off"
button it a good example of this.  The graphics driver may not know the button
was pressed and it has to be told about that.  OTOH the button driver need
not know what exactly should be done when it is pressed.  There may be a user
space component in between that processes the button event and should be able
to tell the graphics driver to suspend.

Thanks,
Rafael

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

[Alan Stern]

On Sat, 9 Oct 2010, Rafael J. Wysocki wrote:

> On Wednesday, October 06, 2010, Alan Stern wrote:
> > On Wed, 6 Oct 2010, Rafael J. Wysocki wrote:
> > 
> > > > Mobile folks wish to power down some devices (most often input -
> > > > touchscreen, keypad) under certain circumstances to save power.
> > > > So far they were doing that by adding "disable" hook to individual
> > > > drivers and while I did allow that in for some devices I feel that we
> > > > need more standardised solution, preferably one that could re-use
> > > > existing PM hooks in drivers.
> > > 
> > > There's no interface for that at the PM core level, but I think we should
> > > add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
> > > flag for drivers who want to make their suspend/resume callbacks to be
> > > reachable directly from user space.  Setting that flag would enable a sysfs
> > > attribute in /sys/devices/.../power/ allowing user space to invoke
> > > pm_runtime_suspend() and pm_runtime_resume() for the given device.
> > 
> > We already have power/control.  If the subsystem sets it to "on" by 
> > default and the driver suspends the device whenever it is idle, then 
> > userspace can control the power level by writing "auto" or "on" to 
> > power/control.
> 
> The problem is that with the 'auto' setting the driver decides when to suspend
> and the driver need not know it's the right time.
> 
> Suspending a graphics adapter when the user presses a "turn screen off"
> button it a good example of this.  The graphics driver may not know the button
> was pressed and it has to be told about that.  OTOH the button driver need
> not know what exactly should be done when it is pressed.  There may be a user
> space component in between that processes the button event and should be able
> to tell the graphics driver to suspend.

You are clearly right; userspace has to tell the driver when it is okay
to suspend.  My point was that we already have a mechanism in the PM
core for doing this -- assuming the driver is written appropriately (to 
assume that it should try to suspend whenever possible).  We shouldn't 
need to add another mechanism.

Alan Stern

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

[Rafael J. Wysocki]

On Sunday, October 10, 2010, Alan Stern wrote:
> On Sat, 9 Oct 2010, Rafael J. Wysocki wrote:
> 
> > On Wednesday, October 06, 2010, Alan Stern wrote:
> > > On Wed, 6 Oct 2010, Rafael J. Wysocki wrote:
> > > 
> > > > > Mobile folks wish to power down some devices (most often input -
> > > > > touchscreen, keypad) under certain circumstances to save power.
> > > > > So far they were doing that by adding "disable" hook to individual
> > > > > drivers and while I did allow that in for some devices I feel that we
> > > > > need more standardised solution, preferably one that could re-use
> > > > > existing PM hooks in drivers.
> > > > 
> > > > There's no interface for that at the PM core level, but I think we should
> > > > add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
> > > > flag for drivers who want to make their suspend/resume callbacks to be
> > > > reachable directly from user space.  Setting that flag would enable a sysfs
> > > > attribute in /sys/devices/.../power/ allowing user space to invoke
> > > > pm_runtime_suspend() and pm_runtime_resume() for the given device.
> > > 
> > > We already have power/control.  If the subsystem sets it to "on" by 
> > > default and the driver suspends the device whenever it is idle, then 
> > > userspace can control the power level by writing "auto" or "on" to 
> > > power/control.
> > 
> > The problem is that with the 'auto' setting the driver decides when to suspend
> > and the driver need not know it's the right time.
> > 
> > Suspending a graphics adapter when the user presses a "turn screen off"
> > button it a good example of this.  The graphics driver may not know the button
> > was pressed and it has to be told about that.  OTOH the button driver need
> > not know what exactly should be done when it is pressed.  There may be a user
> > space component in between that processes the button event and should be able
> > to tell the graphics driver to suspend.
> 
> You are clearly right; userspace has to tell the driver when it is okay
> to suspend.  My point was that we already have a mechanism in the PM
> core for doing this -- assuming the driver is written appropriately (to 
> assume that it should try to suspend whenever possible).  We shouldn't 
> need to add another mechanism.

OK, so how is a graphics driver going to figure out it should suspend when the
button is pressed in the example above?

Rafael

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

[Alan Stern]

On Sun, 10 Oct 2010, Rafael J. Wysocki wrote:

> > > > > There's no interface for that at the PM core level, but I think we should
> > > > > add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
> > > > > flag for drivers who want to make their suspend/resume callbacks to be
> > > > > reachable directly from user space.  Setting that flag would enable a sysfs
> > > > > attribute in /sys/devices/.../power/ allowing user space to invoke
> > > > > pm_runtime_suspend() and pm_runtime_resume() for the given device.
> > > > 
> > > > We already have power/control.  If the subsystem sets it to "on" by 
> > > > default and the driver suspends the device whenever it is idle, then 
> > > > userspace can control the power level by writing "auto" or "on" to 
> > > > power/control.

...

> > You are clearly right; userspace has to tell the driver when it is okay
> > to suspend.  My point was that we already have a mechanism in the PM
> > core for doing this -- assuming the driver is written appropriately (to 
> > assume that it should try to suspend whenever possible).  We shouldn't 
> > need to add another mechanism.
> 
> OK, so how is a graphics driver going to figure out it should suspend when the
> button is pressed in the example above?

The graphics driver doesn't have to figure that out at all.  It merely
has to suspend the display whenever it can, i.e., whenever the usage
count drops to 0 (or equivalently, whenever the runtime_idle callback
runs).

It's up to userspace to make sure that the display's usage count goes
to 0 at the proper time, i.e., when the button is pressed.  Contrary to
what you wrote above, we _do_ have an interface for this at the PM core
level: power/control.

Alan Stern

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

[Dmitry Torokhov]

On Sun, Oct 10, 2010 at 04:34:38PM -0400, Alan Stern wrote:
> On Sun, 10 Oct 2010, Rafael J. Wysocki wrote:
> 
> > > > > > There's no interface for that at the PM core level, but I think we should
> > > > > > add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
> > > > > > flag for drivers who want to make their suspend/resume callbacks to be
> > > > > > reachable directly from user space.  Setting that flag would enable a sysfs
> > > > > > attribute in /sys/devices/.../power/ allowing user space to invoke
> > > > > > pm_runtime_suspend() and pm_runtime_resume() for the given device.
> > > > > 
> > > > > We already have power/control.  If the subsystem sets it to "on" by 
> > > > > default and the driver suspends the device whenever it is idle, then 
> > > > > userspace can control the power level by writing "auto" or "on" to 
> > > > > power/control.
> 
> ...
> 
> > > You are clearly right; userspace has to tell the driver when it is okay
> > > to suspend.  My point was that we already have a mechanism in the PM
> > > core for doing this -- assuming the driver is written appropriately (to 
> > > assume that it should try to suspend whenever possible).  We shouldn't 
> > > need to add another mechanism.
> > 
> > OK, so how is a graphics driver going to figure out it should suspend when the
> > button is pressed in the example above?
> 
> The graphics driver doesn't have to figure that out at all.  It merely
> has to suspend the display whenever it can, i.e., whenever the usage
> count drops to 0 (or equivalently, whenever the runtime_idle callback
> runs).

That makes sense for drivers that do very agressive PM, but fails for
cases when you have bigger timeouts. My phone shuts off its display
automatically after 30 seconds or a minute but I have an option of
pressing a button which causes it to shut off immediately.

> 
> It's up to userspace to make sure that the display's usage count goes
> to 0 at the proper time, i.e., when the button is pressed.  Contrary to
> what you wrote above, we _do_ have an interface for this at the PM core
> level: power/control.
> 

I think that while using power/control is a _very_ good option "auto"
and "on" are not enough, we need 3 states: "on", "off" and "auto".

Thanks.

-- 
Dmitry

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

[Alan Stern]

On Sun, 10 Oct 2010, Dmitry Torokhov wrote:

> > > OK, so how is a graphics driver going to figure out it should suspend when the
> > > button is pressed in the example above?
> > 
> > The graphics driver doesn't have to figure that out at all.  It merely
> > has to suspend the display whenever it can, i.e., whenever the usage
> > count drops to 0 (or equivalently, whenever the runtime_idle callback
> > runs).
> 
> That makes sense for drivers that do very agressive PM, but fails for
> cases when you have bigger timeouts. My phone shuts off its display
> automatically after 30 seconds or a minute but I have an option of
> pressing a button which causes it to shut off immediately.
> 
> > 
> > It's up to userspace to make sure that the display's usage count goes
> > to 0 at the proper time, i.e., when the button is pressed.  Contrary to
> > what you wrote above, we _do_ have an interface for this at the PM core
> > level: power/control.
> > 
> 
> I think that while using power/control is a _very_ good option "auto"
> and "on" are not enough, we need 3 states: "on", "off" and "auto".

Will the driver use autosuspend for the 30-second delay?  Then all you
have to do is this: When the button is pressed, write 0 to
power/autosuspend_delay_ms, causing an immediate runtime suspend.  
Then before turning the display back on, write 30000 to set the delay
to 30 seconds again.  You can leave power/control set to "auto" the
whole time.

I don't like the idea of having an "off" setting in power/control.  
What happens if the user turns a disk drive controller "off" and the 
system needs to read or write something on that disk drive?

Alan Stern

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

[Rafael J. Wysocki]

On Sunday, October 10, 2010, Alan Stern wrote:
> On Sun, 10 Oct 2010, Dmitry Torokhov wrote:
... 
> > > 
> > > It's up to userspace to make sure that the display's usage count goes
> > > to 0 at the proper time, i.e., when the button is pressed.  Contrary to
> > > what you wrote above, we _do_ have an interface for this at the PM core
> > > level: power/control.

I think that power/control is not sufficient, because drivers may generally not
have enough information to make a decision to suspend the device.  What you're
saying basically means that for every driver there should be an interface for
user space to tell it when the device is not used (and therefore may be
suspended), which is pretty much what I'm saying.  The difference seems to be
that I think it's better to put this interface into /sys/devices/.../power/,
while your opinion seems to be that the interface should be driver-specific.

> > 
> > I think that while using power/control is a _very_ good option "auto"
> > and "on" are not enough, we need 3 states: "on", "off" and "auto".
> 
> Will the driver use autosuspend for the 30-second delay?  Then all you
> have to do is this: When the button is pressed, write 0 to
> power/autosuspend_delay_ms, causing an immediate runtime suspend.  
> Then before turning the display back on, write 30000 to set the delay
> to 30 seconds again.  You can leave power/control set to "auto" the
> whole time.
> 
> I don't like the idea of having an "off" setting in power/control.  
> What happens if the user turns a disk drive controller "off" and the 
> system needs to read or write something on that disk drive?

That's why I said about a new flag that will only be set by drivers
_knowing_ that they can suspend "on demand".

Thanks,
Rafael

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

[Dmitry Torokhov]

On Sun, Oct 10, 2010 at 05:09:09PM -0400, Alan Stern wrote:
> On Sun, 10 Oct 2010, Dmitry Torokhov wrote:
> 
> > > > OK, so how is a graphics driver going to figure out it should suspend when the
> > > > button is pressed in the example above?
> > > 
> > > The graphics driver doesn't have to figure that out at all.  It merely
> > > has to suspend the display whenever it can, i.e., whenever the usage
> > > count drops to 0 (or equivalently, whenever the runtime_idle callback
> > > runs).
> > 
> > That makes sense for drivers that do very agressive PM, but fails for
> > cases when you have bigger timeouts. My phone shuts off its display
> > automatically after 30 seconds or a minute but I have an option of
> > pressing a button which causes it to shut off immediately.
> > 
> > > 
> > > It's up to userspace to make sure that the display's usage count goes
> > > to 0 at the proper time, i.e., when the button is pressed.  Contrary to
> > > what you wrote above, we _do_ have an interface for this at the PM core
> > > level: power/control.
> > > 
> > 
> > I think that while using power/control is a _very_ good option "auto"
> > and "on" are not enough, we need 3 states: "on", "off" and "auto".
> 
> Will the driver use autosuspend for the 30-second delay?  Then all you
> have to do is this: When the button is pressed, write 0 to
> power/autosuspend_delay_ms, causing an immediate runtime suspend.  
> Then before turning the display back on, write 30000 to set the delay
> to 30 seconds again.  You can leave power/control set to "auto" the
> whole time.
> 

This means messing up with the currently set timeout. If userspace could
have an option of "accelerating" expiring of the current timeout that
would be better.

> I don't like the idea of having an "off" setting in power/control.  
> What happens if the user turns a disk drive controller "off" and the 
> system needs to read or write something on that disk drive?
> 

I see. Well, for some devices "sicky off" maybe the one that makes most
sense. For others we may need an option that would put them into low
power mode while allowing bringing them back if they are needed.

In case of touchscreens/keypads they are most likely configured as
wakeup sources so when user actually tried to use the device they'll be
brought online.

-- 
Dmitry

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

[Alan Stern]

On Mon, 11 Oct 2010, Rafael J. Wysocki wrote:

> On Sunday, October 10, 2010, Alan Stern wrote:
> > On Sun, 10 Oct 2010, Dmitry Torokhov wrote:
> ... 
> > > > 
> > > > It's up to userspace to make sure that the display's usage count goes
> > > > to 0 at the proper time, i.e., when the button is pressed.  Contrary to
> > > > what you wrote above, we _do_ have an interface for this at the PM core
> > > > level: power/control.
> 
> I think that power/control is not sufficient, because drivers may generally not
> have enough information to make a decision to suspend the device.  What you're
> saying basically means that for every driver there should be an interface for
> user space to tell it when the device is not used (and therefore may be
> suspended), which is pretty much what I'm saying.  The difference seems to be
> that I think it's better to put this interface into /sys/devices/.../power/,
> while your opinion seems to be that the interface should be driver-specific.

This has to depend on how the device is going to be used.  Will there
be multiple user processes, each using it independently?  In that case
a single attribute value won't work; some sort of counter will be
needed.  Will all access funnel through a single process?  Then a
single attribute value will work, and that attribute might as well be
power/control.

I'm not fully convinced that we are yet in a good position to do
anything along these lines.  A driver can generally tell when it is
being used easily enough: If there are I/O calls then it is in use.  
Of course there are exceptions, like a display screen that is in use
when the user is looking at it, not when the display is being updated.

To the extent that drivers can tell what's going on just by monitoring
their own activities, we don't need a new interface.  For anything
beyond that, it seems likely that the situation will vary considerably
from one device to another.  At this point we don't have enough
experience to specify a single approach that will work everywhere.

Especially since I haven't seen any scenarios so far that can't be
solved using the existing interfaces under power/.

> > I don't like the idea of having an "off" setting in power/control.  
> > What happens if the user turns a disk drive controller "off" and the 
> > system needs to read or write something on that disk drive?
> 
> That's why I said about a new flag that will only be set by drivers
> _knowing_ that they can suspend "on demand".

For such drivers, the only question is "Does userspace want me to
suspend now?"  This question can be answered by
power/autosuspend_delay_ms or by power/control.  Why is a new flag
needed?

Alan Stern

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

[Alan Stern]

On Sun, 10 Oct 2010, Dmitry Torokhov wrote:

> > Will the driver use autosuspend for the 30-second delay?  Then all you
> > have to do is this: When the button is pressed, write 0 to
> > power/autosuspend_delay_ms, causing an immediate runtime suspend.  
> > Then before turning the display back on, write 30000 to set the delay
> > to 30 seconds again.  You can leave power/control set to "auto" the
> > whole time.
> > 
> 
> This means messing up with the currently set timeout. If userspace could
> have an option of "accelerating" expiring of the current timeout that
> would be better.

Accelerating the expiration of the timeout _is_ a form of messing with
the currently-set timeout.  It can't be "better".

> > I don't like the idea of having an "off" setting in power/control.  
> > What happens if the user turns a disk drive controller "off" and the 
> > system needs to read or write something on that disk drive?
> > 
> 
> I see. Well, for some devices "sicky off"

"sticky off"?

>  maybe the one that makes most
> sense. For others we may need an option that would put them into low
> power mode while allowing bringing them back if they are needed.

Can you give any examples where "sticky off" is really useful (other
than just for debugging)?

> In case of touchscreens/keypads they are most likely configured as
> wakeup sources so when user actually tried to use the device they'll be
> brought online.

I agree, but it's important to distinguish between wakeup sources in 
particular and interrupt sources in general.  As long as the system 
as a whole isn't suspended (it might be running or it might be in 
cpuidle), any interrupt source can cause a runtime resume.  By 
contrast, when the system is suspended then only wakeup sources will 
cause anything to happen.

Alan Stern

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

[Dmitry Torokhov]

On Mon, Oct 11, 2010 at 12:06:32PM -0400, Alan Stern wrote:
> On Sun, 10 Oct 2010, Dmitry Torokhov wrote:
> 
> > > Will the driver use autosuspend for the 30-second delay?  Then all you
> > > have to do is this: When the button is pressed, write 0 to
> > > power/autosuspend_delay_ms, causing an immediate runtime suspend.  
> > > Then before turning the display back on, write 30000 to set the delay
> > > to 30 seconds again.  You can leave power/control set to "auto" the
> > > whole time.
> > > 
> > 
> > This means messing up with the currently set timeout. If userspace could
> > have an option of "accelerating" expiring of the current timeout that
> > would be better.
> 
> Accelerating the expiration of the timeout _is_ a form of messing with
> the currently-set timeout.  It can't be "better".

I was thinking about the case where timeout is user-supplied setting.
Instead of having application store the original value, write 0, and
later on restore it, I thought it would be better (as in simpler) to
have a separate sysfs entry to "expire" the original timeout
immediately.

> 
> > > I don't like the idea of having an "off" setting in power/control.  
> > > What happens if the user turns a disk drive controller "off" and the 
> > > system needs to read or write something on that disk drive?
> > > 
> > 
> > I see. Well, for some devices "sicky off"
> 
> "sticky off"?

The device that stays off and doe snot power itself up even if it is
needed.

> 
> >  maybe the one that makes most
> > sense. For others we may need an option that would put them into low
> > power mode while allowing bringing them back if they are needed.
> 
> Can you give any examples where "sticky off" is really useful (other
> than just for debugging)?
> 

A mobile device might have a set of keys that, once device is put into
lower power mode, should not bring the device out of that mode. This I
would call a "sticky off" case.

> > In case of touchscreens/keypads they are most likely configured as
> > wakeup sources so when user actually tried to use the device they'll be
> > brought online.
> 
> I agree, but it's important to distinguish between wakeup sources in 
> particular and interrupt sources in general.  As long as the system 
> as a whole isn't suspended (it might be running or it might be in 
> cpuidle), any interrupt source can cause a runtime resume.  By 
> contrast, when the system is suspended then only wakeup sources will 
> cause anything to happen.

Right.

-- 
Dmitry

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

[Alan Stern]

On Mon, 11 Oct 2010, Dmitry Torokhov wrote:

> > > This means messing up with the currently set timeout. If userspace could
> > > have an option of "accelerating" expiring of the current timeout that
> > > would be better.
> > 
> > Accelerating the expiration of the timeout _is_ a form of messing with
> > the currently-set timeout.  It can't be "better".
> 
> I was thinking about the case where timeout is user-supplied setting.
> Instead of having application store the original value, write 0, and
> later on restore it, I thought it would be better (as in simpler) to
> have a separate sysfs entry to "expire" the original timeout
> immediately.

What you're suggesting can be added.  For example, writing a blank line
to power/autosuspend_delay_ms could be defined to have this effect.  
I'm not sure how beneficial it would turn out to be in the long run.

> > Can you give any examples where "sticky off" is really useful (other
> > than just for debugging)?
> > 
> 
> A mobile device might have a set of keys that, once device is put into
> lower power mode, should not bring the device out of that mode. This I
> would call a "sticky off" case.

But here the "sticky off" refers to the entire mobile device, not to 
any particular driver.  In other words, it isn't a runtime-PM issue.

An example of runtime-PM "sticky off" would be a mouse that gets set to
low power and is forced to remain that way even when the user moves or
clicks it.  I don't see how that would be useful.

Alan Stern

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

[Dmitry Torokhov]

On Mon, Oct 11, 2010 at 12:53:11PM -0400, Alan Stern wrote:
> On Mon, 11 Oct 2010, Dmitry Torokhov wrote:
> 
> > > > This means messing up with the currently set timeout. If userspace could
> > > > have an option of "accelerating" expiring of the current timeout that
> > > > would be better.
> > > 
> > > Accelerating the expiration of the timeout _is_ a form of messing with
> > > the currently-set timeout.  It can't be "better".
> > 
> > I was thinking about the case where timeout is user-supplied setting.
> > Instead of having application store the original value, write 0, and
> > later on restore it, I thought it would be better (as in simpler) to
> > have a separate sysfs entry to "expire" the original timeout
> > immediately.
> 
> What you're suggesting can be added.  For example, writing a blank line
> to power/autosuspend_delay_ms could be defined to have this effect.  
> I'm not sure how beneficial it would turn out to be in the long run.
> 
> > > Can you give any examples where "sticky off" is really useful (other
> > > than just for debugging)?
> > > 
> > 
> > A mobile device might have a set of keys that, once device is put into
> > lower power mode, should not bring the device out of that mode. This I
> > would call a "sticky off" case.
> 
> But here the "sticky off" refers to the entire mobile device, not to 
> any particular driver.

Where did I say that? The device is still running, playing your favorite
song collection for example. Still you probably do not want your car
keys compose and e-mail for you while you are jogging, thus the main
keypad would be forced off.

-- 
Dmitry

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

[Alan Stern]

On Mon, 11 Oct 2010, Dmitry Torokhov wrote:

> > > > Can you give any examples where "sticky off" is really useful (other
> > > > than just for debugging)?
> > > > 
> > > 
> > > A mobile device might have a set of keys that, once device is put into
> > > lower power mode, should not bring the device out of that mode. This I
> > > would call a "sticky off" case.
> > 
> > But here the "sticky off" refers to the entire mobile device, not to 
> > any particular driver.
> 
> Where did I say that?

Just above.  The difficulty here is caused by the fact that you used
the word "device" instead of "system".  You wrote "... should not bring
the device out of that mode", with the word "device" referring back to
"a mobile device" -- which is the entire system.  That is, we have the
mobile system and we have the keypad device; calling the mobile system
a "device" leads to confusion.

>  The device is still running, playing your favorite
> song collection for example. Still you probably do not want your car
> keys compose and e-mail for you while you are jogging, thus the main
> keypad would be forced off.

Then I can't answer this question without knowing more about how the 
keypad works.

	Does suspending the keypad truly put it in low-power mode?

	What happens if a key is pressed while the keypad is suspended?

	Do you want to prevent all the keys from working or just some 
	of them?

	How would the user un-suspend the keypad if the system no 
	longer responds to keystrokes?

Alan Stern

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

[Dmitry Torokhov]

On Mon, Oct 11, 2010 at 05:54:27PM -0400, Alan Stern wrote:
> On Mon, 11 Oct 2010, Dmitry Torokhov wrote:
> 
> > > > > Can you give any examples where "sticky off" is really useful (other
> > > > > than just for debugging)?
> > > > > 
> > > > 
> > > > A mobile device might have a set of keys that, once device is put into
> > > > lower power mode, should not bring the device out of that mode. This I
> > > > would call a "sticky off" case.
> > > 
> > > But here the "sticky off" refers to the entire mobile device, not to 
> > > any particular driver.
> > 
> > Where did I say that?
> 
> Just above.

Hm, indeed I did ;)

>  The difficulty here is caused by the fact that you used
> the word "device" instead of "system".  You wrote "... should not bring
> the device out of that mode", with the word "device" referring back to
> "a mobile device" -- which is the entire system.  That is, we have the
> mobile system and we have the keypad device; calling the mobile system
> a "device" leads to confusion.

Right. I guess the scenario I wanted to describe is when we press a key
to put mobile sysem in a lower power mode (shut of screen, block
certain keys, and so on) but that not necessarily means that entire
system is sleeping.

> 
> >  The device is still running, playing your favorite
> > song collection for example. Still you probably do not want your car
> > keys compose and e-mail for you while you are jogging, thus the main
> > keypad would be forced off.
> 
> Then I can't answer this question without knowing more about how the 
> keypad works.
> 
> 	Does suspending the keypad truly put it in low-power mode?

Could be, it depends.

> 
> 	What happens if a key is pressed while the keypad is suspended?

It may or it may not wake up the device and/or system.

> 
> 	Do you want to prevent all the keys from working or just some 
> 	of them?

It depends.

> 
> 	How would the user un-suspend the keypad if the system no 
> 	longer responds to keystrokes?

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 :)

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.

-- 
Dmitry

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

[Sundar R IYER]

Hi,

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

>-----Original Message-----
>From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
>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

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

[Rafael J. Wysocki]

On Monday, October 11, 2010, you wrote:
> On Mon, 11 Oct 2010, Rafael J. Wysocki wrote:
> 
> > On Sunday, October 10, 2010, Alan Stern wrote:
> > > On Sun, 10 Oct 2010, Dmitry Torokhov wrote:
> > ... 
> > > > > 
> > > > > It's up to userspace to make sure that the display's usage count goes
> > > > > to 0 at the proper time, i.e., when the button is pressed.  Contrary to
> > > > > what you wrote above, we _do_ have an interface for this at the PM core
> > > > > level: power/control.
> > 
> > I think that power/control is not sufficient, because drivers may generally not
> > have enough information to make a decision to suspend the device.  What you're
> > saying basically means that for every driver there should be an interface for
> > user space to tell it when the device is not used (and therefore may be
> > suspended), which is pretty much what I'm saying.  The difference seems to be
> > that I think it's better to put this interface into /sys/devices/.../power/,
> > while your opinion seems to be that the interface should be driver-specific.
> 
> This has to depend on how the device is going to be used.  Will there
> be multiple user processes, each using it independently?  In that case
> a single attribute value won't work; some sort of counter will be
> needed.  Will all access funnel through a single process?  Then a
> single attribute value will work, and that attribute might as well be
> power/control.
> 
> I'm not fully convinced that we are yet in a good position to do
> anything along these lines.  A driver can generally tell when it is
> being used easily enough: If there are I/O calls then it is in use.  
> Of course there are exceptions, like a display screen that is in use
> when the user is looking at it, not when the display is being updated.
>
> To the extent that drivers can tell what's going on just by monitoring
> their own activities, we don't need a new interface.  For anything
> beyond that, it seems likely that the situation will vary considerably
> from one device to another.  At this point we don't have enough
> experience to specify a single approach that will work everywhere.
> 
> Especially since I haven't seen any scenarios so far that can't be
> solved using the existing interfaces under power/.

The question is not whether they can be solved _somehow_, but whether it is
_sufficiently_ _convenient_ to solve them using the existing interfaces.

It seems to me that for some devices it might be more convenient to have
an "execute pm_runtime_idle() for this device right now" sysfs trigger
(and analogously for resume).

Anyway, please note that the scenario in which the driver detects inactivity
and suspends the device in response is not the only one possible.  The other
one is that the driver is told to suspend the device and then blocks apps
wanting to access it until resumed.  Right now we have interfaces for the
former, but not for the latter.

> > > I don't like the idea of having an "off" setting in power/control.  
> > > What happens if the user turns a disk drive controller "off" and the 
> > > system needs to read or write something on that disk drive?
> > 
> > That's why I said about a new flag that will only be set by drivers
> > _knowing_ that they can suspend "on demand".
> 
> For such drivers, the only question is "Does userspace want me to
> suspend now?"  This question can be answered by
> power/autosuspend_delay_ms or by power/control.

Not necessarily.

> Why is a new flag needed?

For the second scenario above to be possible.

Thanks,
Rafael

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

[Alan Stern]

On Tue, 12 Oct 2010, Rafael J. Wysocki wrote:

> It seems to me that for some devices it might be more convenient to have
> an "execute pm_runtime_idle() for this device right now" sysfs trigger
> (and analogously for resume).

Indeed, or even "execute pm_runtime_suspend()".  If the driver uses
autosuspend then the runtime_idle callback will call
pm_runtime_autosuspend, which won't do what you want.

> Anyway, please note that the scenario in which the driver detects inactivity
> and suspends the device in response is not the only one possible.  The other
> one is that the driver is told to suspend the device and then blocks apps
> wanting to access it until resumed.

But it initiates a resume as soon as an app tries to use the device, 
right?  Otherwise you've got a "sticky off", as Dmitry would say.

>  Right now we have interfaces for the
> former, but not for the latter.

If it's not a "sticky off", power/control implements the latter 
interface.

Alan Stern

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

[Alan Stern]

On Tue, 12 Oct 2010, Sundar R IYER wrote:

> Hi,
> 
> Sorry to be jumping in late. My few comments dispersed with
> individual replies
> 
> >-----Original Message-----
> >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> >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.

We're not talking about waking up the system.  I'm concerned more about
how the keypad is supposed to work in the scenario Dmitry brought up.  
But evidently things are too variable to say much for certain.

I get the impression that in many cases the entire keypad will have to 
remain functional, and it will be up to userspace to discard keys that 
aren't wanted at a particular time.

> >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.

"Kicking devices into low power mode" is ambiguous.  How about 
"requesting that an idle device go into low-power mode" instead?  This 
doesn't carry an implication that the user could force a non-idle 
device to suspend or could force the driver to do something against its 
will.

Of course, if the device is idle then it's natural to ask why it isn't 
already in low-power mode.  Maybe it's waiting for an autosuspend 
timer to expire; anything else doesn't make much sense.

> 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.

Stop after "communicate specific events to individual devices" (or
drivers).  I don't agree that userspace should always have the ability
to put devices into specific power states.

> - 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)

I don't understand this at all.  How does autosuspend conflict with 
system suspend?  Your example isn't clear.

> - PM ATM doesn't provide a sysfs attribute for enabling/disabling or forcing
>   an individual device into low power mode unlike for platform.

PM does indeed provide a sysfs attribute for enabling/disabling
individual devices for low-power mode.  It doesn't provide an attribute
for _forcing_ a device into low-power mode, and I don't think it
should.  The driver should always be in charge.

> 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.

This has not yet been settled.  Why do we need an "ondemand" flag when 
we already have power/control?

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

Including some sort of interface for cutting short an autosuspend delay
makes sense (and doing it doesn't require a new attribute), but I'm not 
convinced that anything else is needed.

Alan Stern

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

[Dmitry Torokhov]

On Tue, Oct 12, 2010 at 11:34:18AM -0400, Alan Stern wrote:
> On Tue, 12 Oct 2010, Sundar R IYER wrote:
> 
> > Hi,
> > 
> > Sorry to be jumping in late. My few comments dispersed with
> > individual replies
> > 
> > >-----Original Message-----
> > >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> > >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.
> 
> We're not talking about waking up the system.  I'm concerned more about
> how the keypad is supposed to work in the scenario Dmitry brought up.  
> But evidently things are too variable to say much for certain.
> 
> I get the impression that in many cases the entire keypad will have to 
> remain functional, and it will be up to userspace to discard keys that 
> aren't wanted at a particular time.

Again, depends on the hardware. If it is basically a single interrupt
line - then yes, you need to wake up the whoke device (although I have
an idea at the very back of my queue about alowing consumers to
subscribe to certain events so that userspace does not get woken up for
events it does not care about).

If there are several interrupts available you can partition the device
into several components.

> 
> > >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.
> 
> "Kicking devices into low power mode" is ambiguous.  How about 
> "requesting that an idle device go into low-power mode" instead?  This 
> doesn't carry an implication that the user could force a non-idle 
> device to suspend or could force the driver to do something against its 
> will.

Yes, of course. I used "kick" to add some flavor to this conversation, the
API is of course should only provide ways to do "request".

> 
> Of course, if the device is idle then it's natural to ask why it isn't 
> already in low-power mode.  Maybe it's waiting for an autosuspend 
> timer to expire; anything else doesn't make much sense.

Right. I expect that standard screen/keyboard autosuspend shoudl be in
10s of seconds (30-60 i guess) but users might accelerate suspending by
pressing a button. Or software might do the same for userspace when
proximity sensor fires up.

> > 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.
> 
> Stop after "communicate specific events to individual devices" (or
> drivers).  I don't agree that userspace should always have the ability
> to put devices into specific power states.

I think we agree that it should read "request devices go into different
power state".

-- 
Dmitry

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

[Sundar R IYER]

>-----Original Message-----
>From: Alan Stern [mailto:stern@rowland.harvard.edu]
>Sent: Tuesday, October 12, 2010 9:04 PM
>To: Sundar R IYER
>>
>> >-----Original Message-----
>> >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
>> >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 :)
>> >
>>
>We're not talking about waking up the system.  I'm concerned more about
>how the keypad is supposed to work in the scenario Dmitry brought up.
>But evidently things are too variable to say much for certain.
>
>I get the impression that in many cases the entire keypad will have to
>remain functional, and it will be up to userspace to discard keys that
>aren't wanted at a particular time.

What I meant was that various keypad controllers provide different options.
For one TC35893 keypad controller I know, it allows putting the keypad module
into the deepest low power mode while enabling the keypad module to wakeup
via a combination of specific keys. In such a case, the user space isn't even going
to get events to ignore.

>"Kicking devices into low power mode" is ambiguous.  How about
>"requesting that an idle device go into low-power mode" instead?  This
>doesn't carry an implication that the user could force a non-idle
>device to suspend or could force the driver to do something against its
>will.
>
>Of course, if the device is idle then it's natural to ask why it isn't
>already in low-power mode.  Maybe it's waiting for an autosuspend
>timer to expire; anything else doesn't make much sense.
>

Okay. I messed up the kicking part; but why should the device solely wait 
for an auto suspend timer to expire. Don't you agree that the keypad module 
be turned off when a keypad slider is pushed back into a phone?

>> 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.
>
>Stop after "communicate specific events to individual devices" (or
>drivers).  I don't agree that userspace should always have the ability
>to put devices into specific power states.
>

Yes not always; but examples of keypads, touch panels could.

>> - 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)
>
>I don't understand this at all.  How does autosuspend conflict with
>system suspend?  Your example isn't clear.

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?

>PM does indeed provide a sysfs attribute for enabling/disabling
>individual devices for low-power mode.  It doesn't provide an attribute
>for _forcing_ a device into low-power mode, and I don't think it
>should.  The driver should always be in charge.
>

Agree.

>> 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.
>
>This has not yet been settled.  Why do we need an "ondemand" flag when
>we already have power/control?
>

Oh am sorry again; my bad choice of words :( I didn't intend to settle that as
the final outcome). Well the idea of accelerated suspend too looks promising.

Also, for some of the keypad behavior, apart from Dmitry's replies,

> On Tue, Oct 12, 2010 at 3:24 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>        Does suspending the keypad truly put it in low-power mode?
>

The examples that I can see are truly low power states; the STMPE/TC35893(or X)
and ones have the ability to disable the keypad clocks and as explained above ability
to either come back to active mode via magic key presses or some host activity on
the usual MFD.

>        What happens if a key is pressed while the keypad is suspended?
>        Do you want to prevent all the keys from working or just some
>        of them?
>        How would the user un-suspend the keypad if the system no
>        longer responds to keystrokes?

As Dmitry replied, there are variations possible. Controllers part of a MFD group
usually allow returning to active mode via specific bus transactions between the
MFD host and the CPU; dedicated controllers on SoCs cannot wakeup via themselves;
but some dedicated GPIO lines wakeup the CPU and in turn the CPU can wake up the
controller and etc etc

Cheers!

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

[Mark Brown]

On Tue, Oct 12, 2010 at 11:34:18AM -0400, Alan Stern wrote:

> Of course, if the device is idle then it's natural to ask why it isn't 
> already in low-power mode.  Maybe it's waiting for an autosuspend 
> timer to expire; anything else doesn't make much sense.

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.

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

[Alan Stern]

On Tue, 12 Oct 2010, Dmitry Torokhov wrote:

> > Of course, if the device is idle then it's natural to ask why it isn't 
> > already in low-power mode.  Maybe it's waiting for an autosuspend 
> > timer to expire; anything else doesn't make much sense.
> 
> Right. I expect that standard screen/keyboard autosuspend shoudl be in
> 10s of seconds (30-60 i guess) but users might accelerate suspending by
> pressing a button. Or software might do the same for userspace when
> proximity sensor fires up.

On Tue, 12 Oct 2010, Sundar R IYER wrote:

> Okay. I messed up the kicking part; but why should the device solely wait 
> for an auto suspend timer to expire. Don't you agree that the keypad module 
> be turned off when a keypad slider is pushed back into a phone?

Okay, we can agree on this.  Adding an interface to accelerate (or cut
short) an autosuspend timeout makes sense, and it should handle all the 
cases the two of you have mentioned.

Rafael might want more, however, although I'm not sure exactly what he
would like to have.

> >> 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.
> >
> >Stop after "communicate specific events to individual devices" (or
> >drivers).  I don't agree that userspace should always have the ability
> >to put devices into specific power states.
> >
> 
> Yes not always; but examples of keypads, touch panels could.

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.

> >> - 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)
> >
> >I don't understand this at all.  How does autosuspend conflict with
> >system suspend?  Your example isn't clear.
> 
> 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.  But I still don't see how this is
connected with system suspend, or how autosuspend conflicts with system
suspend.

Alan Stern

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

[Alan Stern]

On Tue, 12 Oct 2010, Mark Brown wrote:

> On Tue, Oct 12, 2010 at 11:34:18AM -0400, Alan Stern wrote:
> 
> > Of course, if the device is idle then it's natural to ask why it isn't 
> > already in low-power mode.  Maybe it's waiting for an autosuspend 
> > timer to expire; anything else doesn't make much sense.
> 
> 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.

Alan Stern

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

[Mark Brown]

On Tue, Oct 12, 2010 at 02:27:21PM -0400, Alan Stern wrote:
> On Tue, 12 Oct 2010, Mark Brown wrote:

> > 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.

Right, yes.

> If that's what this is about, then the answer is simple: Don't use 
> runtime PM to try to suppress events.

I tend to agree that runtime PM usage ought to fall out of the disabling
of the input device rather than the other way around.

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

[Sundar R IYER]

>-----Original Message-----
>From: Alan Stern [mailto:stern@rowland.harvard.edu]
>>
>> 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@rowland.harvard.edu]
>
>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!

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

[Mark Brown]

On Wed, Oct 13, 2010 at 08:16:20AM +0200, Sundar R IYER wrote:

> >> 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.

This is the opposite way around to expectations - the expectation is
that runtime power management will flow from the device becoming idle
enough to turn off rather than the other way around.

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

[Rafael J. Wysocki]

On Tuesday, October 12, 2010, Alan Stern wrote:
> On Tue, 12 Oct 2010, Rafael J. Wysocki wrote:
> 
> > It seems to me that for some devices it might be more convenient to have
> > an "execute pm_runtime_idle() for this device right now" sysfs trigger
> > (and analogously for resume).
> 
> Indeed, or even "execute pm_runtime_suspend()".  If the driver uses
> autosuspend then the runtime_idle callback will call
> pm_runtime_autosuspend, which won't do what you want.
> 
> > Anyway, please note that the scenario in which the driver detects inactivity
> > and suspends the device in response is not the only one possible.  The other
> > one is that the driver is told to suspend the device and then blocks apps
> > wanting to access it until resumed.
> 
> But it initiates a resume as soon as an app tries to use the device, 
> right?  Otherwise you've got a "sticky off", as Dmitry would say.

Yes, that's the "sticky off" thing.

Rafael

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

[Alan Stern]

On Wed, 13 Oct 2010, Mark Brown wrote:

> On Wed, Oct 13, 2010 at 08:16:20AM +0200, Sundar R IYER wrote:
> 
> > >> 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.
> 
> This is the opposite way around to expectations - the expectation is
> that runtime power management will flow from the device becoming idle
> enough to turn off rather than the other way around.

Absolutely.  Another point worth mentioning is that a device in
runtime-suspend can be resumed at any time, for a variety of reasons
unconnected with anything the user does.  While it is back at full
power, there is nothing to stop it from generating events.

Alan Stern

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

[Sundar]

On Wed, Oct 13, 2010 at 7:40 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> Absolutely.  Another point worth mentioning is that a device in
> runtime-suspend can be resumed at any time, for a variety of reasons
> unconnected with anything the user does.  While it is back at full
> power, there is nothing to stop it from generating events.
>

Well, so are you still aligned that we can support low power or enable/disable
switches for devices via the standard PM helpers; even if it is the "accelerated
suspend" way ( if Rafael thinks otherwise)

Cheers!

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

[Alan Stern]

On Wed, 13 Oct 2010, Sundar wrote:

> On Wed, Oct 13, 2010 at 7:40 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > Absolutely.  Another point worth mentioning is that a device in
> > runtime-suspend can be resumed at any time, for a variety of reasons
> > unconnected with anything the user does.  While it is back at full
> > power, there is nothing to stop it from generating events.
> >
> 
> Well, so are you still aligned that we can support low power or enable/disable
> switches for devices via the standard PM helpers; even if it is the "accelerated
> suspend" way ( if Rafael thinks otherwise)

Sorry, I don't quite understand your question.  I think it would be
okay to add an interface for userspace to cut short a runtime-suspend
delay, but I don't think anything more is needed.

Alan Stern

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

[Sundar]

On Wed, Oct 13, 2010 at 11:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> Sorry, I don't quite understand your question.  I think it would be
> okay to add an interface for userspace to cut short a runtime-suspend
> delay, but I don't think anything more is needed.
>

I was just confirming that it is agreed by all that we can definitely wrap
this up via the standard PM helpers; through the accelerated suspend
if no one has any other reservations.

Cheers!

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

[Sundar]

On Wed, Oct 13, 2010 at 11:12 PM, Sundar <sunder.svit@gmail.com> wrote:
> On Wed, Oct 13, 2010 at 11:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>
>> Sorry, I don't quite understand your question.  I think it would be
>> okay to add an interface for userspace to cut short a runtime-suspend
>> delay, but I don't think anything more is needed.
>>
>
> I was just confirming that it is agreed by all that we can definitely wrap
> this up via the standard PM helpers; through the accelerated suspend
> if no one has any other reservations.
>

And I forgot one more point. Since this switch feature was one of the
requirements for the Meego framework, wouldnt it be nice if the Meego
people also put out their opinions on this newer solution?

Cheers!

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

[Rafael J. Wysocki]

On Wednesday, October 13, 2010, Sundar wrote:
> On Wed, Oct 13, 2010 at 11:12 PM, Sundar <sunder.svit@gmail.com> wrote:
> > On Wed, Oct 13, 2010 at 11:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> >>
> >> Sorry, I don't quite understand your question.  I think it would be
> >> okay to add an interface for userspace to cut short a runtime-suspend
> >> delay, but I don't think anything more is needed.

I'm not 100% sure how that interface is supposed to work.  Can you elaborate
a bit, please?

> > I was just confirming that it is agreed by all that we can definitely wrap
> > this up via the standard PM helpers; through the accelerated suspend
> > if no one has any other reservations.
> >
> 
> And I forgot one more point. Since this switch feature was one of the
> requirements for the Meego framework, wouldnt it be nice if the Meego
> people also put out their opinions on this newer solution?

Yes, it would.

There's a PM track at the Linux Plumbers conference in a few weeks and I think
it would be good to discuss the issue in there.

Thanks,
Rafael

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

[Alan Stern]

On Wed, 13 Oct 2010, Rafael J. Wysocki wrote:

> On Wednesday, October 13, 2010, Sundar wrote:
> > On Wed, Oct 13, 2010 at 11:12 PM, Sundar <sunder.svit@gmail.com> wrote:
> > > On Wed, Oct 13, 2010 at 11:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > >>
> > >> Sorry, I don't quite understand your question.  I think it would be
> > >> okay to add an interface for userspace to cut short a runtime-suspend
> > >> delay, but I don't think anything more is needed.
> 
> I'm not 100% sure how that interface is supposed to work.  Can you elaborate
> a bit, please?

There could be a new attribute file, or we could use a blank line
written to autosuspend_delay_ms for this purpose.  Either way, the
result would be to call pm_runtime_suspend.  If the device is idle,
merely awaiting the timer expiration for a scheduled suspend or
autosuspend, this would cause it to suspend immediately.

Alan Stern

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

[Rafael J. Wysocki]

On Thursday, October 14, 2010, Alan Stern wrote:
> On Wed, 13 Oct 2010, Rafael J. Wysocki wrote:
> 
> > On Wednesday, October 13, 2010, Sundar wrote:
> > > On Wed, Oct 13, 2010 at 11:12 PM, Sundar <sunder.svit@gmail.com> wrote:
> > > > On Wed, Oct 13, 2010 at 11:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > >>
> > > >> Sorry, I don't quite understand your question.  I think it would be
> > > >> okay to add an interface for userspace to cut short a runtime-suspend
> > > >> delay, but I don't think anything more is needed.
> > 
> > I'm not 100% sure how that interface is supposed to work.  Can you elaborate
> > a bit, please?
> 
> There could be a new attribute file, or we could use a blank line
> written to autosuspend_delay_ms for this purpose.  Either way, the
> result would be to call pm_runtime_suspend.  If the device is idle,
> merely awaiting the timer expiration for a scheduled suspend or
> autosuspend, this would cause it to suspend immediately.

That sounds reasonable.

I wonder what the interested people think about it.

Thanks,
Rafael

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

[Sundar]

On Fri, Oct 15, 2010 at 12:30 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> There could be a new attribute file, or we could use a blank line
>> written to autosuspend_delay_ms for this purpose.  Either way, the
>> result would be to call pm_runtime_suspend.  If the device is idle,
>> merely awaiting the timer expiration for a scheduled suspend or
>> autosuspend, this would cause it to suspend immediately.
>

I personally think the blank line method is fine :). But yes, if we get
to hear something more from the Meego guys, then it would be more
better to fit everyone in.

Cheers!