On Monday, May 19, 2014 02:18:31 AM Jacob Pan wrote:
> On Fri, 16 May 2014 23:08:01 +0200
> "Rafael J. Wysocki" wrote:
>
> > On Friday, May 16, 2014 08:20:55 AM Jacob Pan wrote:
> > > On Thu, 15 May 2014 11:58:55 -0400 (EDT)
> > > Alan Stern wrote:
> > >
> > > > On Thu, 15 May 2014, Jacob Pan
On Monday, May 19, 2014 03:53:58 PM Alan Stern wrote:
> On Mon, 19 May 2014, Jacob Pan wrote:
>
> > > Wouldn't that go a bit too far? It seems to be based on the
> > > assumption that all devices having no ->prepare() callback can be
> > > safely left in runtime suspend over a system
On Mon, 19 May 2014, Jacob Pan wrote:
> > Wouldn't that go a bit too far? It seems to be based on the
> > assumption that all devices having no ->prepare() callback can be
> > safely left in runtime suspend over a system suspend/resume cycle,
> > but is that assumption actually satisfied for all
On Fri, 16 May 2014 23:08:01 +0200
"Rafael J. Wysocki" wrote:
> On Friday, May 16, 2014 08:20:55 AM Jacob Pan wrote:
> > On Thu, 15 May 2014 11:58:55 -0400 (EDT)
> > Alan Stern wrote:
> >
> > > On Thu, 15 May 2014, Jacob Pan wrote:
> > >
> > > > On Thu, 15 May 2014 10:29:42 -0400 (EDT)
> > >
On Fri, 16 May 2014 23:08:01 +0200
Rafael J. Wysocki r...@rjwysocki.net wrote:
On Friday, May 16, 2014 08:20:55 AM Jacob Pan wrote:
On Thu, 15 May 2014 11:58:55 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 15 May 2014, Jacob Pan wrote:
On Thu, 15 May 2014
On Mon, 19 May 2014, Jacob Pan wrote:
Wouldn't that go a bit too far? It seems to be based on the
assumption that all devices having no -prepare() callback can be
safely left in runtime suspend over a system suspend/resume cycle,
but is that assumption actually satisfied for all such
On Monday, May 19, 2014 03:53:58 PM Alan Stern wrote:
On Mon, 19 May 2014, Jacob Pan wrote:
Wouldn't that go a bit too far? It seems to be based on the
assumption that all devices having no -prepare() callback can be
safely left in runtime suspend over a system suspend/resume cycle,
On Monday, May 19, 2014 02:18:31 AM Jacob Pan wrote:
On Fri, 16 May 2014 23:08:01 +0200
Rafael J. Wysocki r...@rjwysocki.net wrote:
On Friday, May 16, 2014 08:20:55 AM Jacob Pan wrote:
On Thu, 15 May 2014 11:58:55 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu,
On Friday, May 16, 2014 08:20:55 AM Jacob Pan wrote:
> On Thu, 15 May 2014 11:58:55 -0400 (EDT)
> Alan Stern wrote:
>
> > On Thu, 15 May 2014, Jacob Pan wrote:
> >
> > > On Thu, 15 May 2014 10:29:42 -0400 (EDT)
> > > Alan Stern wrote:
> > >
> > > > On Thu, 15 May 2014, Jacob Pan wrote:
> > >
On Thu, 15 May 2014 11:58:55 -0400 (EDT)
Alan Stern wrote:
> On Thu, 15 May 2014, Jacob Pan wrote:
>
> > On Thu, 15 May 2014 10:29:42 -0400 (EDT)
> > Alan Stern wrote:
> >
> > > On Thu, 15 May 2014, Jacob Pan wrote:
> > >
> > > > > > should we respect ignore_children flag here? not all
On Thu, 15 May 2014 11:58:55 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 15 May 2014, Jacob Pan wrote:
On Thu, 15 May 2014 10:29:42 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 15 May 2014, Jacob Pan wrote:
should we respect
On Friday, May 16, 2014 08:20:55 AM Jacob Pan wrote:
On Thu, 15 May 2014 11:58:55 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 15 May 2014, Jacob Pan wrote:
On Thu, 15 May 2014 10:29:42 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 15 May
Alan Stern writes:
> On Tue, 13 May 2014, Rafael J. Wysocki wrote:
>
>> > A wakeup request from the hardware could cause a runtime resume to
>> > occur at this time. The barrier wouldn't prevent that.
>> >
>> > It's unlikely, I agree, but not impossible.
>>
>> Yeah, I didn't think about
On Thu, 15 May 2014, Jacob Pan wrote:
> On Thu, 15 May 2014 10:29:42 -0400 (EDT)
> Alan Stern wrote:
>
> > On Thu, 15 May 2014, Jacob Pan wrote:
> >
> > > > > should we respect ignore_children flag here? not all parent
> > > > > devices create children with proper .prepare() function. this
> >
On Thu, 15 May 2014 10:29:42 -0400 (EDT)
Alan Stern wrote:
> On Thu, 15 May 2014, Jacob Pan wrote:
>
> > > > should we respect ignore_children flag here? not all parent
> > > > devices create children with proper .prepare() function. this
> > > > allows parents override children.
> > > > I am
On Thu, 15 May 2014, Jacob Pan wrote:
> > > should we respect ignore_children flag here? not all parent devices
> > > create children with proper .prepare() function. this allows parents
> > > override children.
> > > I am looking at USB, a USB device could have logical children such
> > > as
On Thu, 15 May 2014 13:11:15 +0200
"Rafael J. Wysocki" wrote:
> On Wednesday, May 14, 2014 03:24:21 PM Jacob Pan wrote:
> > On Tue, 13 May 2014 03:10:19 +0200
> > "Rafael J. Wysocki" wrote:
> >
> > > From: Rafael J. Wysocki
> > >
> > > Currently, some subsystems (e.g. PCI and the ACPI PM
On Thursday, May 15, 2014 02:06:59 PM Ulf Hansson wrote:
> > Do we want to allow ->prepare() to return > 0 if the device isn't
> > runtime suspended? If we do then non-suspended devices may be a common
> > case. We should then avoid the extra overhead of disable + enable.
> > So I would write:
>
> Do we want to allow ->prepare() to return > 0 if the device isn't
> runtime suspended? If we do then non-suspended devices may be a common
> case. We should then avoid the extra overhead of disable + enable.
> So I would write:
>
> if (dev->power.direct_complete) {
> if
On Wednesday, May 14, 2014 10:53:16 AM Alan Stern wrote:
> On Tue, 13 May 2014, Rafael J. Wysocki wrote:
>
> > > It would be surprising if ->prepare() needed to make any difficult
> > > checks. This would imply that the device could have multiple
> > > runtime-suspend states, some of which are
On Wednesday, May 14, 2014 03:24:21 PM Jacob Pan wrote:
> On Tue, 13 May 2014 03:10:19 +0200
> "Rafael J. Wysocki" wrote:
>
> > From: Rafael J. Wysocki
> >
> > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
> > resume all runtime-suspended devices during system suspend,
On Wednesday, May 14, 2014 03:24:21 PM Jacob Pan wrote:
On Tue, 13 May 2014 03:10:19 +0200
Rafael J. Wysocki r...@rjwysocki.net wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended
On Wednesday, May 14, 2014 10:53:16 AM Alan Stern wrote:
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
It would be surprising if -prepare() needed to make any difficult
checks. This would imply that the device could have multiple
runtime-suspend states, some of which are appropriate
Do we want to allow -prepare() to return 0 if the device isn't
runtime suspended? If we do then non-suspended devices may be a common
case. We should then avoid the extra overhead of disable + enable.
So I would write:
if (dev-power.direct_complete) {
if
On Thursday, May 15, 2014 02:06:59 PM Ulf Hansson wrote:
Do we want to allow -prepare() to return 0 if the device isn't
runtime suspended? If we do then non-suspended devices may be a common
case. We should then avoid the extra overhead of disable + enable.
So I would write:
On Thu, 15 May 2014 13:11:15 +0200
Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, May 14, 2014 03:24:21 PM Jacob Pan wrote:
On Tue, 13 May 2014 03:10:19 +0200
Rafael J. Wysocki r...@rjwysocki.net wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently,
On Thu, 15 May 2014, Jacob Pan wrote:
should we respect ignore_children flag here? not all parent devices
create children with proper .prepare() function. this allows parents
override children.
I am looking at USB, a USB device could have logical children such
as ep_xx, they don't
On Thu, 15 May 2014 10:29:42 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 15 May 2014, Jacob Pan wrote:
should we respect ignore_children flag here? not all parent
devices create children with proper .prepare() function. this
allows parents override children.
On Thu, 15 May 2014, Jacob Pan wrote:
On Thu, 15 May 2014 10:29:42 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 15 May 2014, Jacob Pan wrote:
should we respect ignore_children flag here? not all parent
devices create children with proper .prepare() function.
Alan Stern st...@rowland.harvard.edu writes:
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
A wakeup request from the hardware could cause a runtime resume to
occur at this time. The barrier wouldn't prevent that.
It's unlikely, I agree, but not impossible.
Yeah, I didn't think
On Tue, 13 May 2014 03:10:19 +0200
"Rafael J. Wysocki" wrote:
> From: Rafael J. Wysocki
>
> Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
> resume all runtime-suspended devices during system suspend, mostly
> because those devices may need to be reprogrammed due to
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
> > It would be surprising if ->prepare() needed to make any difficult
> > checks. This would imply that the device could have multiple
> > runtime-suspend states, some of which are appropriate for system
> > suspend while others aren't. Not
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
It would be surprising if -prepare() needed to make any difficult
checks. This would imply that the device could have multiple
runtime-suspend states, some of which are appropriate for system
suspend while others aren't. Not impossible, but
On Tue, 13 May 2014 03:10:19 +0200
Rafael J. Wysocki r...@rjwysocki.net wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may
On Tuesday, May 13, 2014 12:19:14 PM Alan Stern wrote:
> On Tue, 13 May 2014, Rafael J. Wysocki wrote:
>
> > > Maybe the call to __pm_runtime_disable() should be moved from
> > > __device_suspend_late() to __device_suspend(), after the callback has
> > > been invoked (or skipped, as the case may
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
> > Maybe the call to __pm_runtime_disable() should be moved from
> > __device_suspend_late() to __device_suspend(), after the callback has
> > been invoked (or skipped, as the case may be). Then after runtime PM
> > has been disabled, you can check
On Tuesday, May 13, 2014 11:46:55 AM Alan Stern wrote:
> On Tue, 13 May 2014, Rafael J. Wysocki wrote:
>
> > > A wakeup request from the hardware could cause a runtime resume to
> > > occur at this time. The barrier wouldn't prevent that.
> > >
> > > It's unlikely, I agree, but not impossible.
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
> > A wakeup request from the hardware could cause a runtime resume to
> > occur at this time. The barrier wouldn't prevent that.
> >
> > It's unlikely, I agree, but not impossible.
>
> Yeah, I didn't think about that.
Come to think of it, if the
On Tuesday, May 13, 2014 11:12:28 AM Alan Stern wrote:
> On Tue, 13 May 2014, Rafael J. Wysocki wrote:
>
> > > > + dev->power.direct_complete = ret > 0 && state.event ==
> > > > PM_EVENT_SUSPEND
> > > > + && pm_runtime_suspended(dev);
> > >
> > >
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
> > > + dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND
> > > + && pm_runtime_suspended(dev);
> >
> > Shouldn't the flag be set under the spinlock?
>
> I guess you're worried about runtime PM
On Tuesday, May 13, 2014 10:49:32 AM Alan Stern wrote:
> On Tue, 13 May 2014, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki
> >
> > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
> > resume all runtime-suspended devices during system suspend, mostly
> > because
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
> resume all runtime-suspended devices during system suspend, mostly
> because those devices may need to be reprogrammed due to different
> wakeup
On 13 May 2014 03:10, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
> resume all runtime-suspended devices during system suspend, mostly
> because those devices may need to be reprogrammed due to different
> wakeup
On 13 May 2014 03:10, Rafael J. Wysocki r...@rjwysocki.net wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to
On Tuesday, May 13, 2014 10:49:32 AM Alan Stern wrote:
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend,
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
+ dev-power.direct_complete = ret 0 state.event == PM_EVENT_SUSPEND
+ pm_runtime_suspended(dev);
Shouldn't the flag be set under the spinlock?
I guess you're worried about runtime PM flags being
On Tuesday, May 13, 2014 11:12:28 AM Alan Stern wrote:
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
+ dev-power.direct_complete = ret 0 state.event ==
PM_EVENT_SUSPEND
+pm_runtime_suspended(dev);
Shouldn't the flag be set
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
A wakeup request from the hardware could cause a runtime resume to
occur at this time. The barrier wouldn't prevent that.
It's unlikely, I agree, but not impossible.
Yeah, I didn't think about that.
Come to think of it, if the hardware
On Tuesday, May 13, 2014 11:46:55 AM Alan Stern wrote:
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
A wakeup request from the hardware could cause a runtime resume to
occur at this time. The barrier wouldn't prevent that.
It's unlikely, I agree, but not impossible.
Yeah, I
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
Maybe the call to __pm_runtime_disable() should be moved from
__device_suspend_late() to __device_suspend(), after the callback has
been invoked (or skipped, as the case may be). Then after runtime PM
has been disabled, you can check the
On Tuesday, May 13, 2014 12:19:14 PM Alan Stern wrote:
On Tue, 13 May 2014, Rafael J. Wysocki wrote:
Maybe the call to __pm_runtime_disable() should be moved from
__device_suspend_late() to __device_suspend(), after the callback has
been invoked (or skipped, as the case may be). Then
From: Rafael J. Wysocki
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for
54 matches
Mail list logo
