devices which has enabled
autosuspend, we therfore append the flag sent to rpm_suspend with
RPM_AUTO.
Do note that driver's still needs to update the device last busy mark,
to control the delay for this circumstance.
Updated runtime PM documentation accordingly.
Cc: Alan Stern st
devices which has enabled
autosuspend, we therfore append the flag sent to rpm_suspend with
RPM_AUTO.
Do note that drivers still needs to update the device last busy mark,
to control the delay for this circumstance.
Updated runtime PM documentation accordingly.
Cc: Alan Stern st
or if it returns 0, run rpm_suspend with RPM_AUTO flag to
s/does'nt/doesn't/
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
: Pavel Machek pa...@ucw.cz
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Kevin Hilman khil...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Mika Westerberg mika.westerb...@linux.intel.com
Cc: linux...@vger.kernel.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc
then the last_busy flag isn't
used for anything, so updating it won't hurt.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the pointers and the routines. The contents of the
routines can be removed, leaving nothing but a return 0; line.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
be a bug in the logic of sg_complete() or usb_sg_wait().
_That_ logic bug is what needs to be fixed.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
can confirm that it works for me for now.
I'm happy to try any alternate fixes you would like to suggest (but I cannot
promise how quickly I will get the testing done).
With a little restructuring, this might be a good application for
pm_runtime_no_callbacks().
Alan Stern
--
To unsubscribe
management.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Tejun Heo t...@kernel.org
CC: sta...@kernel.org
---
I'm not sure who to send this patch to, since it is relevant to both
the block and PM subsystems. Jens, is it okay if Rafael takes it?
block/genhd.c | 10
On Thu, 16 Feb 2012, Tejun Heo wrote:
Hello, (cc'ing Rafael and Jens)
On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote:
My question to all of you: Should system_nrt_wq be made freezable, or
should I create a new workqueue that is both freezable and
non-reentrant? And if I
to the new workqueue.
Alan Stern
block/genhd.c | 10 +-
include/linux/workqueue.h |4
kernel/workqueue.c|7 ++-
3 files changed, 15 insertions(+), 6 deletions(-)
Index: usb-3.3/block/genhd.c
On Thu, 16 Feb 2012, Tejun Heo wrote:
Hello,
On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote:
Um. I don't think I can audit all the calls in the kernel that submit
block requests and determine which ones need to be allowed while a
system sleep is in progress.
??? we need
is the right thing to do, even without deferred
probe support.
The answer is 1, but do the move at the appropriate time within the
probe routine.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info
moved not have any children.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
it needs
to be guarded against.
Do these devices ever require deferred probes?
On Fri, Oct 14, 2011 at 9:39 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 13 Oct 2011, Grant Likely wrote:
I saw those. �I also notice that they are only used by device_move()
when reparenting a device
in.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that will be available to other drivers (such as child
devices).
I think the window for this race can be considered to be
of the same magnitude as the moved to early race described above. I
need to think about this more...
Alan Stern
--
To unsubscribe from this list: send
is functional, then B
must come before A in dpm_list.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 13 Oct 2011, Ming Lei wrote:
Hi,
On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern st...@rowland.harvard.edu
Maybe we should understand the correct model of the ordering constraints
for the multiple device dependancies first, could you give a description or
some examples about
(). They are intended specifically to provide
drivers with a way of making sure that dpm_list is in the right order
-- people have been aware of these issues for some time.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
.
The bus notifier might, however. Perhaps the barrier should be moved
down, after the notifier call. How does this patch look?
Alan Stern
drivers/base/dd.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index: usb-2.6/drivers/base/dd.c
put/get pair. Do you know if any other subsystems rely on
the usage_count being 0 during unbinding?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
to
know when that point is reached? The remove routine isn't called until
later.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
I think the current code is better than any of the alternatives considered
so far.
Then you think Guennadi should leave his patch as it is, including the
reversed put/get?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord
, the subsystem may not be able to power-down the device!
Rafael, how do you think we should handle this? Get rid of the
pm_runtime_get_no_resume() and pm_runtime_put_sync() calls in
dd.c:__device_release_driver()?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc
,
that is implementing the idle method wrongly?
Put it this way: When do you want the interface to be powered up and
powered down? That is, what events should cause the power level to
change? The code that handles those events is responsible for calling
the appropriate PM runtime routines.
Alan Stern
, and the resume routine does the reverse.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
do it, but they use PCI PME# instead of interrupts.
I'm not sure if I'm doing it the good way.
We have the exact same issue for our not yet upstreamable usb-otg driver.
Not sure if this cannot be implemented generically in core.
Alan Stern
--
To unsubscribe from this list: send the line
sdhci_pci_runtime_idle(struct device *dev)
+{
+ pm_runtime_autosuspend(dev);
+ return -EAGAIN;
+}
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
.= FILE: $realfile:$realline: if ($realcnt != 0);
+ $here .= $realfile:$realline: if ($realcnt != 0);
my $hereline = $here\n$rawline\n;
my $herecurr = $here\n$rawline\n;
Surely this doesn't belong in the patch.
Alan Stern
--
To unsubscribe from
On Tue, 1 Mar 2011, Pierre Tardy wrote:
On Tue, Mar 1, 2011 at 8:33 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 1 Mar 2011, Pierre Tardy wrote:
Please find sdhci runtime_pm implementation.
It uses clock gating fw as a tip to know when our chip is idle.
It implements wake
request that can't
be turned off by an interrupt handler.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 29 Dec 2010, Ohad Ben-Cohen wrote:
On Tue, Dec 28, 2010 at 11:46 PM, Alan Stern st...@rowland.harvard.edu
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
On Tue, 28 Dec 2010, Ohad Ben-Cohen wrote:
On Sun, Dec 26, 2010 at 7:00 PM, Alan Stern st...@rowland.harvard.edu 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
On Sun, 26 Dec 2010, Ohad Ben-Cohen wrote:
On Sun, Dec 26, 2010 at 4:48 AM, Alan Stern st...@rowland.harvard.edu 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
.
It's not pretty, but this is the only way we can make this work
(unless, of course, our use case will be supported within the
runtime-PM framework itself).
It doesn't sound any less pretty than the situation in USB, so you
shouldn't be too concerned about the aesthetics. :-)
Alan Stern
On Sat, 25 Dec 2010, Ohad Ben-Cohen wrote:
On Sat, Dec 25, 2010 at 6:21 PM, Alan Stern st...@rowland.harvard.edu 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
what every other driver does.
By definition, system sleep transitions require bypassing runtime PM.
There's nothing odd or unusual about it.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo
and hence B gets suspended
before A. Therefore during the prepare phase we can runtime-resume A
and leave it powered up; when B needs to suspend, it won't matter that
the runtime-PM calls are ineffective. Then when A's dpm_suspend
occurs, it can safely go to a low-power state and stay there.
Alan
about coordinating async suspends (the device must be suspended after
its children and before its parent)?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
do you think?
I'm not sure. In this situation, should we worry more that we usually
do about the possibility of a runtime resume occurring after the device
has gone through device_suspend()? Or just depend on the driver to do
everything correctly?
Alan Stern
--
To unsubscribe from this list
, but they
should matter to subsystems and drivers. The PM core cares just enough
to know that it has to invoke different callbacks for the different
operations.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
runtime PM API
during suspend/resume transitions, the driver will not have to care.
Rafael what do you think ? Is that totally unacceptable ?
Have you forgotten about the echo on .../power/control scenario?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc
. That can be fixed only by changing the driver.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
added there won't be any need to use delayed
autosuspend for interfaces. I don't know if any other subsystems would
want to use the no_callbacks flag, but it's possible.
---
Does that look like what you're talking about?
Alan Stern
46 matches
Mail list logo
