On Sunday, June 22, 2014 12:45:42 PM Alan Stern wrote:
> On Sun, 22 Jun 2014, Rafael J. Wysocki wrote:
>
> > > How would you treat them specially? Add a "runtime_pm_not_supported"
> > > flag?
> >
> > I thought about a "runtime PM has been enabled at least once" flag rather
> > that would be
On Sunday, June 22, 2014 12:45:42 PM Alan Stern wrote:
On Sun, 22 Jun 2014, Rafael J. Wysocki wrote:
How would you treat them specially? Add a runtime_pm_not_supported
flag?
I thought about a runtime PM has been enabled at least once flag rather
that would be set by
Alan Stern writes:
[...]
> What we really need to figure out is how to tell the PM core which
> devices may safely have their runtime callbacks invoked during system
> suspend. For those devices, the core can avoid calling
> pm_runtime_disable() during the suspend_late phase. That would
Alan Stern st...@rowland.harvard.edu writes:
[...]
What we really need to figure out is how to tell the PM core which
devices may safely have their runtime callbacks invoked during system
suspend. For those devices, the core can avoid calling
pm_runtime_disable() during the suspend_late
On Sun, 22 Jun 2014, Rafael J. Wysocki wrote:
> > How would you treat them specially? Add a "runtime_pm_not_supported"
> > flag?
>
> I thought about a "runtime PM has been enabled at least once" flag rather
> that would be set by pm_runtime_enable() every time it is called and never
> cleared.
On Friday, June 20, 2014 02:34:14 PM Kevin Hilman wrote:
> Alan Stern writes:
>
> > On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
> >
> >> > For a general device, the fact that dev->power.is_suspended is set
> >> > means the device _has_ been powered down. Even though the
> >> > runtime_status
On Saturday, June 21, 2014 09:34:28 AM Alan Stern wrote:
> On Fri, 20 Jun 2014, Kevin Hilman wrote:
>
> > > For a general device, the fact that dev->power.is_suspended is set
> > > means the device _has_ been powered down. Even though the
> > > runtime_status may not have changed, the PM core
On Friday, June 20, 2014 10:48:09 AM Alan Stern wrote:
> On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
>
> > > For a general device, the fact that dev->power.is_suspended is set
> > > means the device _has_ been powered down. Even though the
> > > runtime_status may not have changed, the PM core
On Friday, June 20, 2014 10:43:11 AM Alan Stern wrote:
> On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
>
> > On Thursday, June 19, 2014 10:34:01 AM Alan Stern wrote:
> > > On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
> > >
> > > > Well, we used to have the notion that runtime_status is not
On Friday, June 20, 2014 10:43:11 AM Alan Stern wrote:
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
On Thursday, June 19, 2014 10:34:01 AM Alan Stern wrote:
On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
Well, we used to have the notion that runtime_status is not meaningful
On Friday, June 20, 2014 10:48:09 AM Alan Stern wrote:
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
For a general device, the fact that dev-power.is_suspended is set
means the device _has_ been powered down. Even though the
runtime_status may not have changed, the PM core has to
On Saturday, June 21, 2014 09:34:28 AM Alan Stern wrote:
On Fri, 20 Jun 2014, Kevin Hilman wrote:
For a general device, the fact that dev-power.is_suspended is set
means the device _has_ been powered down. Even though the
runtime_status may not have changed, the PM core has to assume
On Friday, June 20, 2014 02:34:14 PM Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
For a general device, the fact that dev-power.is_suspended is set
means the device _has_ been powered down. Even though the
On Sun, 22 Jun 2014, Rafael J. Wysocki wrote:
How would you treat them specially? Add a runtime_pm_not_supported
flag?
I thought about a runtime PM has been enabled at least once flag rather
that would be set by pm_runtime_enable() every time it is called and never
cleared. That would
On Fri, 20 Jun 2014, Kevin Hilman wrote:
> > For a general device, the fact that dev->power.is_suspended is set
> > means the device _has_ been powered down. Even though the
> > runtime_status may not have changed, the PM core has to assume the
> > device is not available for use.
>
> This is
On Fri, 20 Jun 2014, Kevin Hilman wrote:
For a general device, the fact that dev-power.is_suspended is set
means the device _has_ been powered down. Even though the
runtime_status may not have changed, the PM core has to assume the
device is not available for use.
This is where things
Alan Stern writes:
> On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
>
>> > For a general device, the fact that dev->power.is_suspended is set
>> > means the device _has_ been powered down. Even though the
>> > runtime_status may not have changed, the PM core has to assume the
>> > device is not
Alan Stern writes:
> On Thu, 19 Jun 2014, Kevin Hilman wrote:
>
>> Alan Stern writes:
>>
>> > On Thu, 19 Jun 2014, Allen Yu wrote:
>> >
>> >> So what's the exact state of device if dev->power.is_suspended flag
>> >> is set and runtime_status is RPM_ACTIVE? Is it a state like
>> >> "suspended
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
> > For a general device, the fact that dev->power.is_suspended is set
> > means the device _has_ been powered down. Even though the
> > runtime_status may not have changed, the PM core has to assume the
> > device is not available for use.
>
> This
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
> On Thursday, June 19, 2014 10:34:01 AM Alan Stern wrote:
> > On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
> >
> > > Well, we used to have the notion that runtime_status is not meaningful for
> > > devices with dev->power.disable_depth greater than
On Thursday, June 19, 2014 10:34:51 PM Allen Yu wrote:
> On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
> > On Thursday, June 19, 2014 04:23:29 PM Allen Yu wrote:
> > > On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
[cut]
> > > > Well, we used to have the notion that runtime_status
On Thursday, June 19, 2014 10:34:01 AM Alan Stern wrote:
> On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
>
> > Well, we used to have the notion that runtime_status is not meaningful for
> > devices with dev->power.disable_depth greater than 0 (except for the special
> > case in the suspend code
On Thursday, June 19, 2014 04:13:07 PM Alan Stern wrote:
> On Thu, 19 Jun 2014, Kevin Hilman wrote:
>
> > Alan Stern writes:
> >
> > > On Thu, 19 Jun 2014, Allen Yu wrote:
> > >
> > >> So what's the exact state of device if dev->power.is_suspended flag
> > >> is set and runtime_status is
On Thursday, June 19, 2014 04:13:07 PM Alan Stern wrote:
On Thu, 19 Jun 2014, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 19 Jun 2014, Allen Yu wrote:
So what's the exact state of device if dev-power.is_suspended flag
is set and runtime_status is
On Thursday, June 19, 2014 10:34:01 AM Alan Stern wrote:
On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
Well, we used to have the notion that runtime_status is not meaningful for
devices with dev-power.disable_depth greater than 0 (except for the special
case in the suspend code path where
On Thursday, June 19, 2014 10:34:51 PM Allen Yu wrote:
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
On Thursday, June 19, 2014 04:23:29 PM Allen Yu wrote:
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
[cut]
Well, we used to have the notion that runtime_status is not
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
On Thursday, June 19, 2014 10:34:01 AM Alan Stern wrote:
On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
Well, we used to have the notion that runtime_status is not meaningful for
devices with dev-power.disable_depth greater than 0 (except
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
For a general device, the fact that dev-power.is_suspended is set
means the device _has_ been powered down. Even though the
runtime_status may not have changed, the PM core has to assume the
device is not available for use.
This seems to
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 19 Jun 2014, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 19 Jun 2014, Allen Yu wrote:
So what's the exact state of device if dev-power.is_suspended flag
is set and runtime_status is RPM_ACTIVE? Is it a
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 20 Jun 2014, Rafael J. Wysocki wrote:
For a general device, the fact that dev-power.is_suspended is set
means the device _has_ been powered down. Even though the
runtime_status may not have changed, the PM core has to assume the
On Thu, 19 Jun 2014, Kevin Hilman wrote:
> Alan Stern writes:
>
> > On Thu, 19 Jun 2014, Allen Yu wrote:
> >
> >> So what's the exact state of device if dev->power.is_suspended flag
> >> is set and runtime_status is RPM_ACTIVE? Is it a state like
> >> "suspended but still can be accessed"?
> >>
Alan Stern writes:
> On Thu, 19 Jun 2014, Allen Yu wrote:
>
>> So what's the exact state of device if dev->power.is_suspended flag
>> is set and runtime_status is RPM_ACTIVE? Is it a state like
>> "suspended but still can be accessed"?
>>
>> I'm just afraid the existing code would cause a
On Thu, 19 Jun 2014, Allen Yu wrote:
> So what's the exact state of device if dev->power.is_suspended flag
> is set and runtime_status is RPM_ACTIVE? Is it a state like
> "suspended but still can be accessed"?
>
> I'm just afraid the existing code would cause a device hang if we
> allow it to be
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
> On Thursday, June 19, 2014 04:23:29 PM Allen Yu wrote:
> > On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
> > > On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
> > > > On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
> > > >
> > >
On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
> Well, we used to have the notion that runtime_status is not meaningful for
> devices with dev->power.disable_depth greater than 0 (except for the special
> case in the suspend code path where we know why it is greater than 0). I
> think
> it was
On Thursday, June 19, 2014 04:23:29 PM Allen Yu wrote:
> On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
> > On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
> > > On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
> > >
> > > > On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
> On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
> > On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
> >
> > > On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
> > > > On Tuesday, June 17, 2014 10:26:14 PM Rafael J.
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
On Thursday, June 19, 2014 04:23:29 PM Allen Yu wrote:
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
On
On Thu, 19 Jun 2014, Rafael J. Wysocki wrote:
Well, we used to have the notion that runtime_status is not meaningful for
devices with dev-power.disable_depth greater than 0 (except for the special
case in the suspend code path where we know why it is greater than 0). I
think
it was useful.
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
On Thursday, June 19, 2014 04:23:29 PM Allen Yu wrote:
On Thursday, June 19, 2014, Rafael J. Wysocki wrote:
On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
On Tuesday,
On Thu, 19 Jun 2014, Allen Yu wrote:
So what's the exact state of device if dev-power.is_suspended flag
is set and runtime_status is RPM_ACTIVE? Is it a state like
suspended but still can be accessed?
I'm just afraid the existing code would cause a device hang if we
allow it to be accessed
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 19 Jun 2014, Allen Yu wrote:
So what's the exact state of device if dev-power.is_suspended flag
is set and runtime_status is RPM_ACTIVE? Is it a state like
suspended but still can be accessed?
I'm just afraid the existing code would
On Thu, 19 Jun 2014, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 19 Jun 2014, Allen Yu wrote:
So what's the exact state of device if dev-power.is_suspended flag
is set and runtime_status is RPM_ACTIVE? Is it a state like
suspended but still can be
On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
> On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
>
> > On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
> > > On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
> > > > On Tuesday, June 17, 2014 10:11:32 AM Alan
On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
> On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
> > On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
> > > On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
> > > > On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
> >
On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
On Wednesday, June 18, 2014 11:30:51 AM Alan Stern wrote:
On Tue, 17 Jun 2014, Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
> On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
> > On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
> > > On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
> > >
> > > > > For reasons having nothing to do with
On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
> On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
> > On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
> >
> > > > For reasons having nothing to do with Allen's suggested change, I
> > > > wonder if we shouldn't replace this line
On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
> On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
>
> > > For reasons having nothing to do with Allen's suggested change, I
> > > wonder if we shouldn't replace this line with something like:
> > >
> > > - else if (dev->power.disable_depth ==
On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
> > For reasons having nothing to do with Allen's suggested change, I
> > wonder if we shouldn't replace this line with something like:
> >
> > - else if (dev->power.disable_depth == 1 && dev->power.is_suspended
> > + else if (dev->power.disable
On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
For reasons having nothing to do with Allen's suggested change, I
wonder if we shouldn't replace this line with something like:
- else if (dev-power.disable_depth == 1 dev-power.is_suspended
+ else if (dev-power.disable 0
On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
For reasons having nothing to do with Allen's suggested change, I
wonder if we shouldn't replace this line with something like:
- else if (dev-power.disable_depth == 1
On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
For reasons having nothing to do with Allen's suggested change, I
wonder if we shouldn't replace this line with
On Tuesday, June 17, 2014 10:37:03 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:26:14 PM Rafael J. Wysocki wrote:
On Tuesday, June 17, 2014 10:11:32 AM Alan Stern wrote:
On Mon, 16 Jun 2014, Rafael J. Wysocki wrote:
For reasons having nothing to do with Allen's suggested
On Monday, June 16, 2014 01:40:05 PM Alan Stern wrote:
> On Sat, 14 Jun 2014, Allen Yu wrote:
>
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -608,7 +608,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
> > repeat:
> > if
On Sat, 14 Jun 2014, Allen Yu wrote:
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -608,7 +608,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
> repeat:
> if (dev->power.runtime_error)
> retval = -EINVAL;
> - else if
On Mon, 16 Jun 2014, Allen Yu wrote:
> On Sat, 14 Jun 2014, Alan Stern wrote:
>
> > > dev->power.is_suspended is set after core suspends device during system
> > suspend.
> > > This flag mostly means device is not operational (all I/O been
> > > quiesced, no more data read or write acceptible,
On Mon, 16 Jun 2014, Allen Yu wrote:
On Sat, 14 Jun 2014, Alan Stern wrote:
dev-power.is_suspended is set after core suspends device during system
suspend.
This flag mostly means device is not operational (all I/O been
quiesced, no more data read or write acceptible, etc.), hence
On Sat, 14 Jun 2014, Allen Yu wrote:
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -608,7 +608,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
repeat:
if (dev-power.runtime_error)
retval = -EINVAL;
- else if
On Monday, June 16, 2014 01:40:05 PM Alan Stern wrote:
On Sat, 14 Jun 2014, Allen Yu wrote:
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -608,7 +608,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
repeat:
if (dev-power.runtime_error)
On Sat, 14 Jun 2014, Alan Stern wrote:
> > dev->power.is_suspended is set after core suspends device during system
> suspend.
> > This flag mostly means device is not operational (all I/O been
> > quiesced, no more data read or write acceptible, etc.), hence it's
> > dangerous to access hardware
On Sat, 14 Jun 2014, Alan Stern wrote:
dev-power.is_suspended is set after core suspends device during system
suspend.
This flag mostly means device is not operational (all I/O been
quiesced, no more data read or write acceptible, etc.), hence it's
dangerous to access hardware if device
On Sat, 14 Jun 2014, Allen Yu wrote:
> dev->power.is_suspended is set after core suspends device during system
> suspend.
> This flag mostly means device is not operational (all I/O been quiesced, no
> more
> data read or write acceptible, etc.), hence it's dangerous to access hardware
> if
>
On Sat, 14 Jun 2014, Allen Yu wrote:
dev-power.is_suspended is set after core suspends device during system
suspend.
This flag mostly means device is not operational (all I/O been quiesced, no
more
data read or write acceptible, etc.), hence it's dangerous to access hardware
if
device
66 matches
Mail list logo
