"Rafael J. Wysocki" writes:
[...]
>>
>> So, to summarize, as long as folks are OK with drivers directly calling
>> the subsystem runtime PM callbacks, I'll go this route.
>
> This is perfectly fine as long as you ensure that they won't be called
> concurrently through the runtime PM framework.
On Thursday, January 27, 2011, Kevin Hilman wrote:
> Alan Stern writes:
>
> > On Thu, 27 Jan 2011, Kevin Hilman wrote:
> >
> >> > Calling the runtime_suspend method directly is the way to do it.
> >> >
> >>
> >> Do you mean the driver's runtime_suspend method, or the subsystem's
> >> runtime_sus
On Thursday, January 27, 2011, Alan Stern wrote:
> On Wed, 26 Jan 2011, Kevin Hilman wrote:
>
> > >> Consider this instead: Since A is required to be functional before B
> > >> can be used, A must be registered before B and hence B gets suspended
> > >> before A. Therefore during the prepare pha
On Thu, Jan 27, 2011 at 9:15 PM, Kevin Hilman wrote:
>
>> If it is, then you can call omap_pm_runtime_suspend() directly instead
>> of calling dev->bus->pm->runtime_suspend().
>
> Personally, I prefer going through dev->bus as we try to avoid SoC
> specific calls in the driver.
>
> This same HW bl
Alan Stern writes:
> On Thu, 27 Jan 2011, Kevin Hilman wrote:
>
>> > Calling the runtime_suspend method directly is the way to do it.
>> >
>>
>> Do you mean the driver's runtime_suspend method, or the subsystem's
>> runtime_suspend method?
>
> The subsystem's. If the driver has a runtime_suspen
On Thu, 27 Jan 2011, Kevin Hilman wrote:
> > Calling the runtime_suspend method directly is the way to do it.
> >
>
> Do you mean the driver's runtime_suspend method, or the subsystem's
> runtime_suspend method?
The subsystem's. If the driver has a runtime_suspend method then the
subsystem's m
Alan Stern writes:
> On Wed, 26 Jan 2011, Kevin Hilman wrote:
>
>> >> Consider this instead: Since A is required to be functional before B
>> >> can be used, A must be registered before B and hence B gets suspended
>> >> before A. Therefore during the prepare phase we can runtime-resume A
>> >>
Vitaly Wool writes:
> Hi Kevin,
>
>> Therefore, what is ideally needed is the ability for A's suspend to
>> simply call pm_runtime_suspend() so the subsystem can do the work.
>> However, since runtime transitions are locked out by this time, that
>> doesn't work. IOW, what is needed is a way for
Hi Kevin,
> Therefore, what is ideally needed is the ability for A's suspend to
> simply call pm_runtime_suspend() so the subsystem can do the work.
> However, since runtime transitions are locked out by this time, that
> doesn't work. IOW, what is needed is a way for a system suspend to say
> "p
On Wed, 26 Jan 2011, Kevin Hilman wrote:
> >> Consider this instead: Since A is required to be functional before B
> >> can be used, A must be registered before B and hence B gets suspended
> >> before A. Therefore during the prepare phase we can runtime-resume A
> >> and leave it powered up; wh
"Rafael J. Wysocki" writes:
> On Wednesday, December 22, 2010, Alan Stern wrote:
>> On Tue, 21 Dec 2010, Rafael J. Wysocki wrote:
>>
>> > It basically goes like this. There's device A that is only resumed when
>> > it's
>> > needed to carry out an operation and is suspended immediately after t
On Wed, 29 Dec 2010, Ohad Ben-Cohen wrote:
> On Tue, Dec 28, 2010 at 11:46 PM, Alan Stern
> wrote:
> > Similarly, during system suspend mmc_suspend_host() should be
> > responsible for doing all the necessary power-down operations. Runtime
> > PM is completely out of the picture at this time.
On Wed, 29 Dec 2010, Ohad Ben-Cohen wrote:
> On Tue, Dec 28, 2010 at 11:46 PM, Alan Stern
> wrote:
> > What's the relation between mmc_power_off() and mmc_power_save_host()?
>
> Essentially they are the same - mmc_power_off() is the one that
> actually powers off the card.
>
> mmc_power_save_h
On Tue, Dec 28, 2010 at 11:46 PM, Alan Stern wrote:
> Similarly, during system suspend mmc_suspend_host() should be
> responsible for doing all the necessary power-down operations. Runtime
> PM is completely out of the picture at this time. And this should be
> independent of mac80211 -- in fact
On Tue, Dec 28, 2010 at 11:46 PM, Alan Stern wrote:
> What's the relation between mmc_power_off() and mmc_power_save_host()?
Essentially they are the same - mmc_power_off() is the one that
actually powers off the card.
mmc_power_save_host() just invokes first a bus-specific ->power_save()
handle
On Tue, 28 Dec 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 7:00 PM, Alan Stern wrote:
> > Hmm. It's a little difficult to untangle the web of dev_pm_ops
> > pointers and other stuff.
>
> Yeah, SDIO suspend/resume is very different from other subsystems.
>
> There are several layers o
On Tue, Dec 28, 2010 at 10:04 PM, Rafael J. Wysocki wrote:
> On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
>> On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote:
>> > So, it only happens during asynchronous suspend? In other words, if
>> > suspend
>> > is synchronous, everything sh
On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
> On Tue, Dec 28, 2010 at 9:21 PM, Rafael J. Wysocki wrote:
> > It looks like you could simply do a power down-power up cycle before trying
> > to
> > load new firmware, just in case. I guess that's suboptimal for some reason?
>
> It would wo
On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote:
> > So, it only happens during asynchronous suspend? In other words, if suspend
> > is synchronous, everything should be fine, right?
>
> Not necessarily.
So it's not a race after al
On Tue, Dec 28, 2010 at 9:21 PM, Rafael J. Wysocki wrote:
> It looks like you could simply do a power down-power up cycle before trying to
> load new firmware, just in case. I guess that's suboptimal for some reason?
It would work, but we will not be able to unconditionally disable the
radios (e
On Tuesday, December 28, 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 8:35 PM, Rafael J. Wysocki wrote:
> > On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
> >> On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
> >> > Why does the driver need the device to be reset even thoug
On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki wrote:
> So, it only happens during asynchronous suspend? In other words, if suspend
> is synchronous, everything should be fine, right?
Not necessarily.
Consider this simple scenario, where a device was added after the mmc
host controller, but
On Sun, Dec 26, 2010 at 8:35 PM, Rafael J. Wysocki wrote:
> On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
>> On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
>> > Why does the driver need the device to be reset even though it hasn't
>> > been suspeneded yet?
>>
>> Because it is ask
On Sun, Dec 26, 2010 at 7:00 PM, Alan Stern wrote:
> Hmm. It's a little difficult to untangle the web of dev_pm_ops
> pointers and other stuff.
Yeah, SDIO suspend/resume is very different from other subsystems.
There are several layers of abstractions involved, from the host
controller driver,
On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
> > (It still is not a race, though.)
>
> Thread 1
> ===
>
> suspend_handler_of_a_random_device()
> {
> return failure;
> }
>
> Thread 2
> ===
>
> suspend_handler_of_our_
On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
> > Why does the driver need the device to be reset even though it hasn't
> > been suspeneded yet?
>
> Because it is asked to stop the hardware by mac80211.
So I guess the mac80211 lay
On Sun, 26 Dec 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 4:48 AM, Alan Stern wrote:
> > Is there a separate handler responsible for powering the device back
> > on? What are the names of these handlers?
>
> wl1271_sdio_power_on() and wl1271_sdio_power_off().
>
> If you're taking a
On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
> (It still is not a race, though.)
Thread 1
===
suspend_handler_of_a_random_device()
{
return failure;
}
Thread 2
===
suspend_handler_of_our_mmc_host_controller()
{
invoke our sdio suspend handler and power down the car
On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki wrote:
> Why does the driver need the device to be reset even though it hasn't
> been suspeneded yet?
Because it is asked to stop the hardware by mac80211.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a m
On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 26, 2010 at 4:48 AM, Alan Stern wrote:
> > Is there a separate handler responsible for powering the device back
> > on? What are the names of these handlers?
>
> wl1271_sdio_power_on() and wl1271_sdio_power_off().
>
> If you're t
On Sun, Dec 26, 2010 at 4:48 AM, Alan Stern wrote:
> Is there a separate handler responsible for powering the device back
> on? What are the names of these handlers?
wl1271_sdio_power_on() and wl1271_sdio_power_off().
If you're taking a look, please do so using the latest code as seen on mmc-ne
On Sat, Dec 25, 2010 at 11:50 PM, Vitaly Wool wrote:
> you're talking about _complete_ shutdown as a suspended state for both
> runtime PM and static PM, is that correct?
Exactly.
This is the power of the card as seen by the MMC/SDIO subsystem.
--
To unsubscribe from this list: send the line "un
On Sat, 25 Dec 2010, Ohad Ben-Cohen wrote:
> On Sat, Dec 25, 2010 at 6:21 PM, Alan Stern wrote:
> > Right. You may or may not realize it, but this requirement means that
> > the driver _must_ bypass runtime PM sometimes.
>
> http://www.spinics.net/lists/linux-pm/msg22864.html
>
> > Now you've
Hi Ohad,
On Sat, Dec 25, 2010 at 9:58 PM, Ohad Ben-Cohen wrote:
> On Sat, Dec 25, 2010 at 6:21 PM, Alan Stern wrote:
>> Right. You may or may not realize it, but this requirement means that
>> the driver _must_ bypass runtime PM sometimes.
>
> http://www.spinics.net/lists/linux-pm/msg22864.html
Hi Ohad,
On Sat, Dec 25, 2010 at 9:58 PM, Ohad Ben-Cohen wrote:
> On Sat, Dec 25, 2010 at 6:21 PM, Alan Stern wrote:
>> Right. You may or may not realize it, but this requirement means that
>> the driver _must_ bypass runtime PM sometimes.
>
> http://www.spinics.net/lists/linux-pm/msg22864.html
On Sat, Dec 25, 2010 at 6:21 PM, Alan Stern wrote:
> Right. You may or may not realize it, but this requirement means that
> the driver _must_ bypass runtime PM sometimes.
http://www.spinics.net/lists/linux-pm/msg22864.html
> Now you've lost me. Which of the driver's handlers are you talking
>
On Sat, 25 Dec 2010, Ohad Ben-Cohen wrote:
> I'll try to explain, and if something is still not clear, please let me know.
>
> Our wlan device is an ARM microcontroller running some flavor of RTOS
> (i.e. the firmware); as I mentioned before, its power and reset
> functionalities are tied togethe
On Thu, Dec 23, 2010 at 6:03 PM, Alan Stern wrote:
> I'm still not aware of the details of your situation. Nevertheless, it
> shouldn't be hard to set up a suspend() routine that would do whatever
> was needed to power down the device, whether this means calling the
> runtime_suspend() routine di
On Thu, 23 Dec 2010, Ohad Ben-Cohen wrote:
> On Sun, Dec 19, 2010 at 12:22 PM, Rafael J. Wysocki wrote:
> > That said, I think we may do something different that perhaps will make your
> > life somewhat easier.
> ...
> > So, I think we can add a "runtime only" flag working as described above.
>
On Sun, Dec 19, 2010 at 12:22 PM, Rafael J. Wysocki wrote:
> That said, I think we may do something different that perhaps will make your
> life somewhat easier.
...
> So, I think we can add a "runtime only" flag working as described above.
That will definitely solve the suspend/resume issue we'r
On Wednesday, December 22, 2010, Alan Stern wrote:
> On Tue, 21 Dec 2010, Rafael J. Wysocki wrote:
>
> > It basically goes like this. There's device A that is only resumed when
> > it's
> > needed to carry out an operation and is suspended immediately after that.
> > There's another device B tha
On Tue, 21 Dec 2010, Kevin Hilman wrote:
> That being said, another thing we discussed briefly at LPC was wondering
> about reason(s) behind the DPM core locking out runtime PM transitions
> in the first place.
The reason is to prevent confusion from unwanted runtime-PM state
changes during a sy
On Tue, 21 Dec 2010, Rafael J. Wysocki wrote:
> It basically goes like this. There's device A that is only resumed when it's
> needed to carry out an operation and is suspended immediately after that.
> There's another device B that needs A to do something during its suspend.
> So, when the suspe
"Rafael J. Wysocki" writes:
> On Saturday, December 18, 2010, Rafael J. Wysocki wrote:
>> On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
>> > On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki wrote:
>> > > On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
>> > >> On Sat, Dec 11, 2010
On Tuesday, December 21, 2010, Alan Stern wrote:
> On Mon, 20 Dec 2010, Rafael J. Wysocki wrote:
>
> > > > In that case, if a device if flagged as "runtime only", we can avoid
> > > > calling pm_runtime_get_noirq() for it in dpm_prepare() and, analogously,
> > > > calling pm_runtime_put_sync() for
On Mon, 20 Dec 2010, Rafael J. Wysocki wrote:
> > > In that case, if a device if flagged as "runtime only", we can avoid
> > > calling pm_runtime_get_noirq() for it in dpm_prepare() and, analogously,
> > > calling pm_runtime_put_sync() for it in dpm_complete(). However, we will
> > > have
> > >
On Monday, December 20, 2010, Alan Stern wrote:
> On Sun, 19 Dec 2010, Rafael J. Wysocki wrote:
>
> > That said, I think we may do something different that perhaps will make your
> > life somewhat easier.
> >
> > Namely, if your driver doesn't implement any system suspend callbacks
> > (i.e. ->su
On Sun, 19 Dec 2010, Rafael J. Wysocki wrote:
> That said, I think we may do something different that perhaps will make your
> life somewhat easier.
>
> Namely, if your driver doesn't implement any system suspend callbacks
> (i.e. ->suspend(), ->resume(), ->freeze(), ->thaw() etc.) and it doesn't
On Saturday, December 18, 2010, Rafael J. Wysocki wrote:
> On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> > On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki wrote:
> > > On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> > >> On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern
> > >> wro
On Sat, Dec 18, 2010 at 11:20 PM, Alan Stern wrote:
>> They would also gain deterministic and controllable behavior that we
>> can't guarantee when we rely on a context switch, because obviously
>> the latter yields different results for different platforms and
>> workloads (for the exact same sub
On Sun, Dec 19, 2010 at 12:47 AM, Rafael J. Wysocki wrote:
> On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
>> On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki wrote:
>> > On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
>> >> On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern
>> >> wrot
On Saturday, December 18, 2010, Alan Stern wrote:
> On Sat, 18 Dec 2010, Ohad Ben-Cohen wrote:
>
> > > Not so. Even if a driver uses runtime PM correctly, there will still
> > > be times when someone else has increased the usage_count. This happens
> > > during probing and during system resume,
On Saturday, December 18, 2010, Alan Stern wrote:
> On Sat, 18 Dec 2010, Ohad Ben-Cohen wrote:
>
> > > Sounds to me like the difference isn't really in the driver, but the
> > > core PM subsystem. Why does it care when powering off a device whether
> > > it's during suspend, or during runtime?
> >
On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> On Sat, Dec 18, 2010 at 6:40 PM, Johannes Berg
> wrote:
> > On Sat, 2010-12-18 at 18:00 +0200, Ohad Ben-Cohen wrote:
> >
> >> > That's where the problem is. If there's a difference, from the driver's
> >> > point of view, between suspend and
On Saturday, December 18, 2010, Johannes Berg wrote:
> On Sat, 2010-12-18 at 18:00 +0200, Ohad Ben-Cohen wrote:
>
> > > That's where the problem is. If there's a difference, from the driver's
> > > point of view, between suspend and some other operation, there should be a
> > > way to tell the dr
On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki wrote:
> > On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> >> On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern
> >> wrote:
> >> >> Think of a device which you have no way to reset other
On Sat, 18 Dec 2010, Ohad Ben-Cohen wrote:
> > Sounds to me like the difference isn't really in the driver, but the
> > core PM subsystem. Why does it care when powering off a device whether
> > it's during suspend, or during runtime?
>
> Agree.
>
> If we can add a dev_pm_info bit, that would al
On Sat, 18 Dec 2010, Johannes Berg wrote:
> Sounds to me like the difference isn't really in the driver, but the
> core PM subsystem. Why does it care when powering off a device whether
> it's during suspend, or during runtime?
The two operations are quite different. One involves preparing the
d
On Sat, 18 Dec 2010, Ohad Ben-Cohen wrote:
> > Not so. Even if a driver uses runtime PM correctly, there will still
> > be times when someone else has increased the usage_count. This happens
> > during probing and during system resume, for example.
>
> I'm aware of these two examples; normally
On Sat, Dec 18, 2010 at 6:40 PM, Johannes Berg
wrote:
> On Sat, 2010-12-18 at 18:00 +0200, Ohad Ben-Cohen wrote:
>
>> > That's where the problem is. If there's a difference, from the driver's
>> > point of view, between suspend and some other operation, there should be a
>> > way to tell the driv
On Sat, 2010-12-18 at 18:00 +0200, Ohad Ben-Cohen wrote:
> > That's where the problem is. If there's a difference, from the driver's
> > point of view, between suspend and some other operation, there should be a
> > way to tell the driver what case it actually is dealing with.
>
> Yes, the probl
On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki wrote:
> On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
>> On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern
>> wrote:
>> >> Think of a device which you have no way to reset other than powering
>> >> it down and up again.
>> >>
>> >> If that de
On Sat, Dec 18, 2010 at 4:16 PM, David Vrabel wrote:
...
> It may be useful if you
> describe the wi-fi chip's operational or power states and the valid
> transitions between them.
Sure.
When powered up initially, the device is a standard SDIO device that
responds to bus transactions.
Soon afte
On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> Hi Alan,
>
> Sorry for the belated response,
>
> On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern wrote:
> >> Think of a device which you have no way to reset other than powering
> >> it down and up again.
> >>
> >> If that device is managed by
On 18/12/2010 13:29, Ohad Ben-Cohen wrote:
>
> During system suspend, our driver is asked (by mac80211's suspend
> handler) to power off its device. When this happens, the driver has no
> idea that the system is suspending - regular driver code (responsible
> to remove the wlan interface and stop
Hi Alan,
Sorry for the belated response,
On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern wrote:
>> Think of a device which you have no way to reset other than powering
>> it down and up again.
>>
>> If that device is managed by runtime PM, the only way to do that is by
>> using put_sync() followed b
On Sat, Dec 11, 2010 at 12:59 AM, Ohad Ben-Cohen wrote:
>>> > A different, bolder solution, will always call pm_runtime_idle instead
>>> > of pm_request_idle (see below): when a device is runtime suspended, it
>>> > can't be too bad to immediately send idle notification to its parent,
>>> > too. I
On Sat, Dec 11, 2010 at 12:01 AM, Rafael J. Wysocki wrote:
> I prefer the first patch, so Ohad, if you want it merged, please resend with
> a sign-off etc.
Sure.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kerne
On Fri, Dec 10, 2010 at 7:24 PM, Alan Stern wrote:
>> On Friday, December 10, 2010, Ohad Ben-Cohen wrote:
>> > When pm_runtime_put_sync() returns, the _put operation is completed,
>> > and if needed (zero usage_count, children are ignored or their count
>> > is zero, ->runtime_idle() called pm_run
On Friday, December 10, 2010, Alan Stern wrote:
> On Fri, 10 Dec 2010, Rafael J. Wysocki wrote:
>
> > On Friday, December 10, 2010, Ohad Ben-Cohen wrote:
> > > When pm_runtime_put_sync() returns, the _put operation is completed,
> > > and if needed (zero usage_count, children are ignored or their
On Fri, 10 Dec 2010, Rafael J. Wysocki wrote:
> On Friday, December 10, 2010, Ohad Ben-Cohen wrote:
> > When pm_runtime_put_sync() returns, the _put operation is completed,
> > and if needed (zero usage_count, children are ignored or their count
> > is zero, ->runtime_idle() called pm_runtime_susp
On Friday, December 10, 2010, Ohad Ben-Cohen wrote:
> When pm_runtime_put_sync() returns, the _put operation is completed,
> and if needed (zero usage_count, children are ignored or their count
> is zero, ->runtime_idle() called pm_runtime_suspend(), no
> runtime_error, no disable_depth, etc...) th
When pm_runtime_put_sync() returns, the _put operation is completed,
and if needed (zero usage_count, children are ignored or their count
is zero, ->runtime_idle() called pm_runtime_suspend(), no
runtime_error, no disable_depth, etc...) the device is powered down.
This behavior is sometimes desira
73 matches
Mail list logo
