On Sunday, May 11, 2014 12:46:10 PM Alan Stern wrote:
> On Sat, 10 May 2014, Rafael J. Wysocki wrote:
>
> > On Thursday, May 08, 2014 09:52:18 PM Alan Stern wrote:
> > > On Thu, 8 May 2014, Rafael J. Wysocki wrote:
> > >
> > > > Well, no.
> > > >
> > > > The reason why that doesn't work is becau
"Rafael J. Wysocki" writes:
> On Friday, May 09, 2014 03:48:21 PM Kevin Hilman wrote:
>> "Rafael J. Wysocki" writes:
>>
>> > 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, m
On Sat, 10 May 2014, Rafael J. Wysocki wrote:
> On Thursday, May 08, 2014 09:52:18 PM Alan Stern wrote:
> > On Thu, 8 May 2014, Rafael J. Wysocki wrote:
> >
> > > Well, no.
> > >
> > > The reason why that doesn't work is because ->prepare() callbacks are
> > > executed in the reverse order, so t
On Friday, May 09, 2014 03:48:21 PM Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> > 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 ne
"Rafael J. Wysocki" writes:
> 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 sl
On Thursday, May 08, 2014 09:52:18 PM Alan Stern wrote:
> On Thu, 8 May 2014, Rafael J. Wysocki wrote:
>
> > Well, no.
> >
> > The reason why that doesn't work is because ->prepare() callbacks are
> > executed in the reverse order, so the perent's ones will be run before
> > the ->prepare() of th
On Friday, May 09, 2014 09:23:50 AM Ulf Hansson wrote:
> Hi Rafael,
>
> > @@ -1485,3 +1486,10 @@ out:
> > return ret;
> > }
> > EXPORT_SYMBOL_GPL(pm_runtime_force_resume);
> > +
> > +void pm_set_direct_resume(struct device *dev, bool val)
> > +{
> > + spin_lock_irq(&dev->power.lock
Hi Rafael,
> @@ -1485,3 +1486,10 @@ out:
> return ret;
> }
> EXPORT_SYMBOL_GPL(pm_runtime_force_resume);
> +
> +void pm_set_direct_resume(struct device *dev, bool val)
> +{
> + spin_lock_irq(&dev->power.lock);
> + __set_direct_resume(dev, val);
> + spin_unlock_irq(&dev-
On Thu, 8 May 2014, Rafael J. Wysocki wrote:
> Well, no.
>
> The reason why that doesn't work is because ->prepare() callbacks are
> executed in the reverse order, so the perent's ones will be run before
> the ->prepare() of the children. Thus if ->prepare() sets the flag
> with the expectation
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 devices
On Thursday, May 08, 2014 11:42:01 PM Rafael J. Wysocki wrote:
> On Thursday, May 08, 2014 05:20:43 PM Alan Stern wrote:
> > On Thu, 8 May 2014, Rafael J. Wysocki wrote:
> >
> > > > > Wait a minute. Following ->runtime_suspend(), you are going to call
> > > > > ->suspend() and then ->runtime_res
On Thursday, May 08, 2014 05:20:43 PM Alan Stern wrote:
> On Thu, 8 May 2014, Rafael J. Wysocki wrote:
>
> > > > Wait a minute. Following ->runtime_suspend(), you are going to call
> > > > ->suspend() and then ->runtime_resume()? That doesn't seem like what
> > > > you really want; a ->suspend
On Thu, 8 May 2014, Rafael J. Wysocki wrote:
> > > Wait a minute. Following ->runtime_suspend(), you are going to call
> > > ->suspend() and then ->runtime_resume()? That doesn't seem like what
> > > you really want; a ->suspend() call should always have a matching
> > > ->resume().
> >
> >
On Thu, 8 May 2014, Rafael J. Wysocki wrote:
> > Wait a minute. Following ->runtime_suspend(), you are going to call
> > ->suspend() and then ->runtime_resume()? That doesn't seem like what
> > you really want; a ->suspend() call should always have a matching
> > ->resume().
>
> Yes, it shou
On Thursday, May 08, 2014 10:17:50 PM Rafael J. Wysocki wrote:
> On Thursday, May 08, 2014 10:57:36 AM Alan Stern wrote:
> > On Thu, 8 May 2014, Rafael J. Wysocki wrote:
> >
> > > From: Rafael J. Wysocki
> > >
> > > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
> > > resum
On Thursday, May 08, 2014 10:57:36 AM Alan Stern wrote:
> On Thu, 8 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 tho
On Thursday, May 08, 2014 02:25:06 PM Ulf Hansson wrote:
> On 8 May 2014 13:44, Rafael J. Wysocki wrote:
> > On Thursday, May 08, 2014 12:59:20 PM Ulf Hansson wrote:
> >> On 8 May 2014 12:53, Rafael J. Wysocki wrote:
> >> > On Thursday, May 08, 2014 09:49:36 AM Ulf Hansson wrote:
> >> >> On 8 May
On Thu, 8 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 setti
On Thu, 8 May 2014, Ulf Hansson wrote:
> >> Should we not depend on PM_RUNTIME only? Thus we don't need the new
> >> Kconfig,
> >
> > Well, OK. I guess we can tolerate one useless statement in rpm_resume()
> > in case CONFIG_PM_SLEEP is unset.
It isn't a big deal. However, Ulf, you need to unde
On 8 May 2014 13:44, Rafael J. Wysocki wrote:
> On Thursday, May 08, 2014 12:59:20 PM Ulf Hansson wrote:
>> On 8 May 2014 12:53, Rafael J. Wysocki wrote:
>> > On Thursday, May 08, 2014 09:49:36 AM Ulf Hansson wrote:
>> >> On 8 May 2014 01:29, Rafael J. Wysocki wrote:
>> >> > From: Rafael J. Wyso
On Thursday, May 08, 2014 12:59:20 PM Ulf Hansson wrote:
> On 8 May 2014 12:53, Rafael J. Wysocki wrote:
> > On Thursday, May 08, 2014 09:49:36 AM Ulf Hansson wrote:
> >> On 8 May 2014 01:29, Rafael J. Wysocki wrote:
> >> > From: Rafael J. Wysocki
> >> >
> >> > Currently, some subsystems (e.g. P
On 8 May 2014 12:53, Rafael J. Wysocki wrote:
> On Thursday, May 08, 2014 09:49:36 AM Ulf Hansson wrote:
>> On 8 May 2014 01:29, 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
On Thursday, May 08, 2014 09:49:36 AM Ulf Hansson wrote:
> On 8 May 2014 01:29, 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 thos
On 8 May 2014 01:29, 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 setti
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 devices
25 matches
Mail list logo
