Hi!
> > >
> > >> > This suggests we forget about power/wakeup == "off" and introduce an
> > >> > "inhibit" attribute instead.
> > >>
> > >> If we do that, can it still be regarded as a PM attribute?
> > >
> > > Why not? Consider this: Is there any reason to support inhibit when
> > > CONFIG_PM is
On Mon, 28 Sep 2015, Rafael J. Wysocki wrote:
> Hi Alan,
>
> On Mon, Sep 28, 2015 at 4:29 PM, Alan Stern wrote:
> > On Mon, 28 Sep 2015, Rafael J. Wysocki wrote:
> >
> >> > This suggests we forget about power/wakeup == "off" and introduce an
> >> > "inhibit" attribute instead.
> >>
> >> If we do
Hi Alan,
On Mon, Sep 28, 2015 at 4:29 PM, Alan Stern wrote:
> On Mon, 28 Sep 2015, Rafael J. Wysocki wrote:
>
>> > This suggests we forget about power/wakeup == "off" and introduce an
>> > "inhibit" attribute instead.
>>
>> If we do that, can it still be regarded as a PM attribute?
>
> Why not?
On Mon, 28 Sep 2015, Rafael J. Wysocki wrote:
> > This suggests we forget about power/wakeup == "off" and introduce an
> > "inhibit" attribute instead.
>
> If we do that, can it still be regarded as a PM attribute?
Why not? Consider this: Is there any reason to support inhibit when
CONFIG_PM i
On Sunday, September 27, 2015 07:02:17 PM Pavel Machek wrote:
> Hi!
Hi,
> > > > > That, or there may be an additional value, say "aggressive", to write
> > > > > to the
> > > > > control file in which case it becomes just
> > > > >
> > > > > echo aggressive >/sys/.../power/control
> > > >
> >
On Sunday, September 27, 2015 10:27:25 AM Alan Stern wrote:
> On Sun, 27 Sep 2015, Rafael J. Wysocki wrote:
>
> > On Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote:
> > > On Sat, 26 Sep 2015, Rafael J. Wysocki wrote:
> > >
> > > > > > So something like:
> > > > > >
> > > > > > ech
Hi!
> > > > That, or there may be an additional value, say "aggressive", to write
> > > > to the
> > > > control file in which case it becomes just
> > > >
> > > > echo aggressive >/sys/.../power/control
> > >
> > > That said I suppose that the "off" value for the "wakeup" file might also
> >
On Sun, 27 Sep 2015, Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote:
> > On Sat, 26 Sep 2015, Rafael J. Wysocki wrote:
> >
> > > > > So something like:
> > > > >
> > > > > echo on >/sys/.../power/control (in case the device was
> > > > >
On Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote:
> On Sat, 26 Sep 2015, Rafael J. Wysocki wrote:
>
> > > > So something like:
> > > >
> > > > echo on >/sys/.../power/control (in case the device was
> > > > already in runtime suspend with wakeups enabl
On Sat, 26 Sep 2015, Rafael J. Wysocki wrote:
> > > So something like:
> > >
> > > echo on >/sys/.../power/control (in case the device was
> > > already in runtime suspend with wakeups enabled)
> > > echo off >/sys/.../power/wakeup
> > > echo auto >/sys/.../power/control
On Friday, September 25, 2015 11:52:23 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 05:13:04 PM Alan Stern wrote:
> > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> >
> > > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> > > > On Fri, 25 Sep 2015, Rafael J. Wysocki wr
On Friday, September 25, 2015 05:13:04 PM Alan Stern wrote:
> On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
>
> > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> > >
> > > > We are missing the "no remote wakeup" bit now (well, ther
On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> >
> > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS
> > > flag,
> > > but it isn't very useful, so I'd prefer
On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
>
> > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag,
> > but it isn't very useful, so I'd prefer to replace it with a "no remote
> > wakeup"
> > bit in struct
On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag,
> but it isn't very useful, so I'd prefer to replace it with a "no remote
> wakeup"
> bit in struct dev_pm_info or something similar).
>
> That is actually quite important
On Wednesday, September 23, 2015 10:55:52 AM Alan Stern wrote:
> On Wed, 23 Sep 2015, Oliver Neukum wrote:
>
> > On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> > > On Tue, 22 Sep 2015, Oliver Neukum wrote:
> > >
> > > > Cancel, yes, going to low power is a consequence which needn't bothe
On Wed, 23 Sep 2015, Oliver Neukum wrote:
> On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> > On Tue, 22 Sep 2015, Oliver Neukum wrote:
> >
> > > Cancel, yes, going to low power is a consequence which needn't bother
> > > the power subsystem.
> >
> > Going to low power needn't involve th
On Wed, Sep 23, 2015 at 6:03 AM, Oliver Neukum wrote:
>
> On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> > On Tue, 22 Sep 2015, Oliver Neukum wrote:
> >
> > > Cancel, yes, going to low power is a consequence which needn't bother
> > > the power subsystem.
> >
> > Going to low power needn't
On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> On Tue, 22 Sep 2015, Oliver Neukum wrote:
>
> > Cancel, yes, going to low power is a consequence which needn't bother
> > the power subsystem.
>
> Going to low power needn't involve the power subsystem? That sounds
> weird.
Think of it li
On Tue, 22 Sep 2015, Oliver Neukum wrote:
> > I'm not sure I understand what you're saying. Are you suggesting that
> > this "inhibit" mechanism should involve a new callback different from
>
> Yes, there is no necessary relation to power management. If you put
> your phone into your pocket, you
On Tue, 2015-09-22 at 10:15 -0400, Alan Stern wrote:
> On Tue, 22 Sep 2015, Oliver Neukum wrote:
>
> > Indeed. We can handle output to suspended devices by waking them.
> > I don't see why this case is different. We are talking about input
> > only.
> >
> > > The runtime-PM "usage" value for thes
On Tue, 22 Sep 2015, Oliver Neukum wrote:
> Indeed. We can handle output to suspended devices by waking them.
> I don't see why this case is different. We are talking about input
> only.
>
> > The runtime-PM "usage" value for these devices is a little tricky to
> > calculate. It should be nonze
On Mon, 2015-09-21 at 16:02 -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
>
> > > What happens if the "inhibit" control is turned on and the driver puts
> > > the device into runtime suspend, but then an I/O request arrives?
> > >
> > > If the I/O request originated fr
On Mon, Sep 21, 2015 at 04:02:01PM -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
>
> > > What happens if the "inhibit" control is turned on and the driver puts
> > > the device into runtime suspend, but then an I/O request arrives?
> > >
> > > If the I/O request origin
On Mon 2015-09-21 10:38:46, Alan Stern wrote:
> On Mon, 21 Sep 2015, Pavel Machek wrote:
>
> > > > In fact, then, what you need seems to be the feature discussed by Alan
> > > > and me some time ago allowing remote wakeup do be disabled for runtime
> > > > PM from user space as that in combination
On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
> > What happens if the "inhibit" control is turned on and the driver puts
> > the device into runtime suspend, but then an I/O request arrives?
> >
> > If the I/O request originated from userspace, it means the
> > user is violating the terms
On Mon, Sep 21, 2015 at 01:32:38PM -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
>
> > > It sounds like you are suggesting there should be a general mechanism
> > > for userspace to tell the kernel (or the input core) to ignore all
> > > events from a particular input devi
On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
> > It sounds like you are suggesting there should be a general mechanism
> > for userspace to tell the kernel (or the input core) to ignore all
> > events from a particular input device -- or even from all input devices
> > -- thereby allowing those dev
On Mon, Sep 21, 2015 at 12:34:56PM -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
>
> > On Mon, Sep 21, 2015 at 10:38:46AM -0400, Alan Stern wrote:
> > > On Mon, 21 Sep 2015, Pavel Machek wrote:
> > >
> > > > > > In fact, then, what you need seems to be the feature discuss
On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
> On Mon, Sep 21, 2015 at 10:38:46AM -0400, Alan Stern wrote:
> > On Mon, 21 Sep 2015, Pavel Machek wrote:
> >
> > > > > In fact, then, what you need seems to be the feature discussed by Alan
> > > > > and me some time ago allowing remote wakeup do be d
On Mon, Sep 21, 2015 at 10:38:46AM -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Pavel Machek wrote:
>
> > > > In fact, then, what you need seems to be the feature discussed by Alan
> > > > and me some time ago allowing remote wakeup do be disabled for runtime
> > > > PM from user space as that
On Mon, 21 Sep 2015, Pavel Machek wrote:
> > > In fact, then, what you need seems to be the feature discussed by Alan
> > > and me some time ago allowing remote wakeup do be disabled for runtime
> > > PM from user space as that in combination with autosuspend should
> > > address your use case.
>
On Wed 2015-09-09 11:20:25, Alan Stern wrote:
> On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:
>
> > > The best example and actually the very specific problem we want to
> > > solve is handling touchscreens on a phone / tablet. When the screen is
> > > turned off, it is ideal to suspend the touchscr
> > >> In fact, then, what you need seems to be the feature discussed by Alan
> > >> and me some time ago allowing remote wakeup do be disabled for runtime
> > >> PM from user space as that in combination with autosuspend should
> > >> address your use case.
> > >
> > > I'd doubt that. Suppose you
On Wed, 2015-09-09 at 22:25 +0200, Rafael J. Wysocki wrote:
> > >
> > > I'd doubt that. Suppose you put the phone into your pocket while
> > > the device isn't suspended. The continuous stream of spurious
> events
> > > will keep it awake.
>
> Why would they be regarded as spurious then? They are
On Wed, Sep 9, 2015 at 1:35 PM, Rafael J. Wysocki wrote:
>
> On Wednesday, September 09, 2015 11:20:25 AM Alan Stern wrote:
> > On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:
> >
> > > > The best example and actually the very specific problem we want to
> > > > solve is handling touchscreens on a ph
On Wednesday, September 09, 2015 11:20:25 AM Alan Stern wrote:
> On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:
>
> > > The best example and actually the very specific problem we want to
> > > solve is handling touchscreens on a phone / tablet. When the screen is
> > > turned off, it is ideal to sus
On Wednesday, September 09, 2015 06:02:02 PM Octavian Purdila wrote:
> On Wed, Sep 9, 2015 at 4:55 PM, Oliver Neukum wrote:
> > On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
> >> > Note that when the screen is turned-on again, we want to resume the
> >> > touchscreen so that it can s
On Tue, 8 Sep 2015, Rafael J. Wysocki wrote:
> Hi,
>
> On Tue, Sep 8, 2015 at 5:00 PM, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Rafael J. Wysocki wrote:
> >
> >> > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2
> >> >
> >> > Purely as a matter of interest, in that email Rafael also
On Wed, 9 Sep 2015, Rafael J. Wysocki wrote:
> > The best example and actually the very specific problem we want to
> > solve is handling touchscreens on a phone / tablet. When the screen is
> > turned off, it is ideal to suspend the touchscreen for two reasons: to
> > lower the power consumption
On Wed, Sep 9, 2015 at 4:55 PM, Oliver Neukum wrote:
> On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
>> > Note that when the screen is turned-on again, we want to resume the
>> > touchscreen so that it can send events again.
>
> Why is it impractical to close the fd for the touchscre
On Wed, 9 Sep 2015, Oliver Neukum wrote:
> On Tue, 2015-09-08 at 10:44 -0400, Alan Stern wrote:
> > It would not put the device into runtime suspend immediately, like you
> > are proposing. Instead it would mean the same as the "auto" mode,
> > except that remote wakeup should be disabled during
On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
> > Note that when the screen is turned-on again, we want to resume the
> > touchscreen so that it can send events again.
Why is it impractical to close the fd for the touchscreen?
>
> In fact, then, what you need seems to be the feature
Hi,
On Wed, Sep 9, 2015 at 1:13 PM, Octavian Purdila
wrote:
> On Wed, Sep 9, 2015 at 2:50 AM, Rafael J. Wysocki wrote:
>>
>> Hi,
>>
>> On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson wrote:
>> > On 8 September 2015 at 22:56, Rafael J. Wysocki wrote:
>> >> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Ne
On Wed, Sep 9, 2015 at 2:50 AM, Rafael J. Wysocki wrote:
>
> Hi,
>
> On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson wrote:
> > On 8 September 2015 at 22:56, Rafael J. Wysocki wrote:
> >> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum wrote:
> >>> On Tue, 2015-09-08 at 01:10 +, Tirdea, Irina wr
On Tue, 2015-09-08 at 10:44 -0400, Alan Stern wrote:
> It would not put the device into runtime suspend immediately, like you
> are proposing. Instead it would mean the same as the "auto" mode,
> except that remote wakeup should be disabled during runtime suspend.
Hi,
this proposal is incomplete
Hi,
On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson wrote:
> On 8 September 2015 at 22:56, Rafael J. Wysocki wrote:
>> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum wrote:
>>> On Tue, 2015-09-08 at 01:10 +, Tirdea, Irina wrote:
>>
>> [cut]
>>
this would work except for adding a sysfs attr
On 8 September 2015 at 22:56, Rafael J. Wysocki wrote:
> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum wrote:
>> On Tue, 2015-09-08 at 01:10 +, Tirdea, Irina wrote:
>
> [cut]
>
>>> this would work except for adding a sysfs attribute that would trigger
>>> a runtime suspend while ignoring usag
On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum wrote:
> On Tue, 2015-09-08 at 01:10 +, Tirdea, Irina wrote:
[cut]
>> this would work except for adding a sysfs attribute that would trigger
>> a runtime suspend while ignoring usage count. Would that be a
>> better direction?
>
> No. If we want
Hi,
On Tue, Sep 8, 2015 at 5:00 PM, Alan Stern wrote:
> On Tue, 8 Sep 2015, Rafael J. Wysocki wrote:
>
>> > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2
>> >
>> > Purely as a matter of interest, in that email Rafael also mentioned
>> > that he and I had discussed a way to disable r
On Tue, 8 Sep 2015, Rafael J. Wysocki wrote:
> > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2
> >
> > Purely as a matter of interest, in that email Rafael also mentioned
> > that he and I had discussed a way to disable remote wakeup during
> > runtime suspend. Oddly enough, the m
On Tuesday, September 08, 2015 10:44:04 AM Alan Stern wrote:
> On Tue, 8 Sep 2015, Tirdea, Irina wrote:
>
> > In the previous discussion thread , there were a couple of options
> > mentioned, but none seemed to reach a consensus. You mentioned
> > adding a "more aggressive runtime PM mode" [1]. I'
On Tue, 8 Sep 2015, Tirdea, Irina wrote:
> In the previous discussion thread , there were a couple of options
> mentioned, but none seemed to reach a consensus. You mentioned
> adding a "more aggressive runtime PM mode" [1]. I'm not sure how
> this would work except for adding a sysfs attribute th
On Tue, 2015-09-08 at 01:10 +, Tirdea, Irina wrote:
> However, in the scenario I mentioned this is exactly what is happening.
> When turning off the screen of a mobile device, the user space
Would you explain why user space doesn't simply stop using those
devices, which in turn will make them
.org;
> linux-ker...@vger.kernel.org; Brown, Len; Pavel Machek;
> Purdila, Octavian; Dmitry Torokhov
> Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing
> runtime suspend
>
> On Monday, September 07, 2015 11:42:41 PM Irina Tirdea wrote:
> > Add new optio
On Monday, September 07, 2015 11:42:41 PM Irina Tirdea wrote:
> Add new option to sysfs control interface, allowing the user to force
> suspend the device.
Had we thought this had been a good idea, we'd have added that thing to
the interface from the start.
The problem with it is that user space
Add new option to sysfs control interface, allowing the user to force
suspend the device. This is useful for devices that need to be
suspended when closing the lid of a laptop or the screen of a mobile
device, while userspace still holds open handles to it and the
system does not enter system suspe
57 matches
Mail list logo
