On Thu 2013-12-05 17:21:50, Alan Stern wrote:
> On Thu, 5 Dec 2013, Len Brown wrote:
>
> > This thread raises the question...
> >
> > Do we still need to have PM_RUNTIME apart from PM_SLEEP?
> >
> > What is the benefit of being able to build-in one one without the other?
> > If that benefit is
On Thu, 5 Dec 2013, Len Brown wrote:
> This thread raises the question...
>
> Do we still need to have PM_RUNTIME apart from PM_SLEEP?
>
> What is the benefit of being able to build-in one one without the other?
> If that benefit is not significant, perhaps the time has come to
> replace them
This thread raises the question...
Do we still need to have PM_RUNTIME apart from PM_SLEEP?
What is the benefit of being able to build-in one one without the other?
If that benefit is not significant, perhaps the time has come to
replace them both with CONFIG_PM...
cheers,
-Len Brown, Intel
This thread raises the question...
Do we still need to have PM_RUNTIME apart from PM_SLEEP?
What is the benefit of being able to build-in one one without the other?
If that benefit is not significant, perhaps the time has come to
replace them both with CONFIG_PM...
cheers,
-Len Brown, Intel
On Thu, 5 Dec 2013, Len Brown wrote:
This thread raises the question...
Do we still need to have PM_RUNTIME apart from PM_SLEEP?
What is the benefit of being able to build-in one one without the other?
If that benefit is not significant, perhaps the time has come to
replace them both
On Thu 2013-12-05 17:21:50, Alan Stern wrote:
On Thu, 5 Dec 2013, Len Brown wrote:
This thread raises the question...
Do we still need to have PM_RUNTIME apart from PM_SLEEP?
What is the benefit of being able to build-in one one without the other?
If that benefit is not
>
> That would be kind of OK, if the driver's .suspend_late() only invoked its own
> .runtime_suspend(), what you did below.
>
> But, in the Ulf's approach the driver calls .runtime_suspend() from
> its *subsystem* in the hope that it will all work out properly (or
> perhaps based on the knowledge
>
> Well, to be honest, I'd never put a call to pm_runtime_get_sync() into
> a driver's system suspend callback.
Nevertheless, the PM core allows it to happen and there are not only
subsystem-level code but also drivers that use it, for whatever
reasons.
>
> Subsystem callbacks are a different
Well, to be honest, I'd never put a call to pm_runtime_get_sync() into
a driver's system suspend callback.
Nevertheless, the PM core allows it to happen and there are not only
subsystem-level code but also drivers that use it, for whatever
reasons.
Subsystem callbacks are a different matter
That would be kind of OK, if the driver's .suspend_late() only invoked its own
.runtime_suspend(), what you did below.
But, in the Ulf's approach the driver calls .runtime_suspend() from
its *subsystem* in the hope that it will all work out properly (or
perhaps based on the knowledge about
On Friday, November 29, 2013 10:30:57 AM Alan Stern wrote:
> On Fri, 29 Nov 2013, Rafael J. Wysocki wrote:
>
> > That should have been
> >
> > driver->runtime_suspend(dev)
> > do_X(dev)
> >
> > because do_Y(dev) is for runtime suspend. Sorry.
> >
> > And of course, the subsystem-level
On Fri, 29 Nov 2013, Rafael J. Wysocki wrote:
> That should have been
>
> driver->runtime_suspend(dev)
> do_X(dev)
>
> because do_Y(dev) is for runtime suspend. Sorry.
>
> And of course, the subsystem-level code you're developing the driver for may
> not
> do the do_X(dev) thing
On Friday, November 29, 2013 02:52:20 PM Rafael J. Wysocki wrote:
> On Friday, November 29, 2013 10:32:06 AM Ulf Hansson wrote:
[...]
> > For the same reasons, I believe we should trust drivers/subsystems, to
> > understand when it makes sense for them to re-use all of the runtime
> > PM
On Friday, November 29, 2013 10:32:06 AM Ulf Hansson wrote:
> >
> > The lack of specificity here doesn't make the discussion any easier.
> >
> > It usually is better to talk about specific problems to address than
> > using general terms which may mean slightly different things for different
> >
On 29 November 2013 10:32, Ulf Hansson wrote:
>>
>> The lack of specificity here doesn't make the discussion any easier.
>>
>> It usually is better to talk about specific problems to address than
>> using general terms which may mean slightly different things for different
>> people.
>
> During
>
> The lack of specificity here doesn't make the discussion any easier.
>
> It usually is better to talk about specific problems to address than
> using general terms which may mean slightly different things for different
> people.
During these discussions, I have tried to point at existing code
The lack of specificity here doesn't make the discussion any easier.
It usually is better to talk about specific problems to address than
using general terms which may mean slightly different things for different
people.
During these discussions, I have tried to point at existing code for
On 29 November 2013 10:32, Ulf Hansson ulf.hans...@linaro.org wrote:
The lack of specificity here doesn't make the discussion any easier.
It usually is better to talk about specific problems to address than
using general terms which may mean slightly different things for different
people.
On Friday, November 29, 2013 10:32:06 AM Ulf Hansson wrote:
The lack of specificity here doesn't make the discussion any easier.
It usually is better to talk about specific problems to address than
using general terms which may mean slightly different things for different
people.
On Friday, November 29, 2013 02:52:20 PM Rafael J. Wysocki wrote:
On Friday, November 29, 2013 10:32:06 AM Ulf Hansson wrote:
[...]
For the same reasons, I believe we should trust drivers/subsystems, to
understand when it makes sense for them to re-use all of the runtime
PM callbacks
On Fri, 29 Nov 2013, Rafael J. Wysocki wrote:
That should have been
driver-runtime_suspend(dev)
do_X(dev)
because do_Y(dev) is for runtime suspend. Sorry.
And of course, the subsystem-level code you're developing the driver for may
not
do the do_X(dev) thing at all, in
On Friday, November 29, 2013 10:30:57 AM Alan Stern wrote:
On Fri, 29 Nov 2013, Rafael J. Wysocki wrote:
That should have been
driver-runtime_suspend(dev)
do_X(dev)
because do_Y(dev) is for runtime suspend. Sorry.
And of course, the subsystem-level code you're
On Thursday, November 28, 2013 10:58:48 AM Ulf Hansson wrote:
> On 27 November 2013 21:42, Rafael J. Wysocki wrote:
> > On Wednesday, November 27, 2013 04:34:55 PM Ulf Hansson wrote:
> >> To put devices into low power state during system suspend, it may be
> >> convenient
> >> for runtime PM
On 27 November 2013 21:42, Rafael J. Wysocki wrote:
> On Wednesday, November 27, 2013 04:34:55 PM Ulf Hansson wrote:
>> To put devices into low power state during system suspend, it may be
>> convenient
>> for runtime PM supported subsystems, power domains and drivers to have the
>> option of
On 27 November 2013 21:42, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, November 27, 2013 04:34:55 PM Ulf Hansson wrote:
To put devices into low power state during system suspend, it may be
convenient
for runtime PM supported subsystems, power domains and drivers to have the
On Thursday, November 28, 2013 10:58:48 AM Ulf Hansson wrote:
On 27 November 2013 21:42, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, November 27, 2013 04:34:55 PM Ulf Hansson wrote:
To put devices into low power state during system suspend, it may be
convenient
for runtime
On Wednesday, November 27, 2013 04:34:55 PM Ulf Hansson wrote:
> To put devices into low power state during system suspend, it may be
> convenient
> for runtime PM supported subsystems, power domains and drivers to have the
> option of re-using the runtime PM callbacks.
>
> At the moment, quite
To put devices into low power state during system suspend, it may be convenient
for runtime PM supported subsystems, power domains and drivers to have the
option of re-using the runtime PM callbacks.
At the moment, quite complex solutions exist for power domains that tries to
handle the above,
To put devices into low power state during system suspend, it may be convenient
for runtime PM supported subsystems, power domains and drivers to have the
option of re-using the runtime PM callbacks.
At the moment, quite complex solutions exist for power domains that tries to
handle the above,
On Wednesday, November 27, 2013 04:34:55 PM Ulf Hansson wrote:
To put devices into low power state during system suspend, it may be
convenient
for runtime PM supported subsystems, power domains and drivers to have the
option of re-using the runtime PM callbacks.
At the moment, quite
30 matches
Mail list logo
