.
Take a look how MMC_CAP_POWER_OFF_CARD is described in the commit log
which added it:
commit ed919b0125b26dcc052e44836f66e7e1f5c49c7e
Author: Ohad Ben-Cohen o...@wizery.com
Date: Fri Nov 19 09:29:09 2010 +0200
mmc: sdio: fix runtime PM anomalies by introducing MMC_CAP_POWER_OFF_CARD
Hi Guennadi,
On Thu, May 24, 2012 at 4:07 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
How do you know, if this is a normal sd-card slot?
Not sure I follow the question.
But if you ask whether we can dynamically set MMC_CAP_POWER_OFF_CARD,
then we can't (with what we know today).
Hi Guennadi,
On Thu, May 24, 2012 at 5:06 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Sorry, I mean - you don't know what card will be plugged in, so, you
cannot know, whether that specific card and its driver can be safely
powered off.
We do know in certain cases, most commonly
Hi Guennadi,
On Thu, May 24, 2012 at 6:42 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Yes, exactly, in certain cases. And when it's not hard-wired?
We don't support this yet.
Daniel suggested using either black or white listing (based on
vendor/device id presumably) so we can
On Thu, May 24, 2012 at 10:08 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Feel free to propose a solution, but please back it up with real
hardware and show that it satisfies the MMC_CAP_POWER_OFF_CARD issues
we had in the past.
The solution should also still support powering off the card even
On Fri, May 25, 2012 at 12:15 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
I think it'd be better to go with driver-assisted PM straight away instead
of implementing black-/white-lists to later find out about cards with the
same IDs and different behaviour.
I'm not sure - we usually
On Thu, Jun 9, 2011 at 7:21 PM, Daniel Drake d...@laptop.org wrote:
With this version of the patch:
http://dev.laptop.org/~dsd/20110609/sd-pwr-debug2.patch
bash-4.1# mount -t debugfs none /sys/kernel/debug
bash-4.1# cat /sys/kernel/debug/mmc1/ios
clock: 0 Hz
vdd: 0
On Thu, Jun 9, 2011 at 7:44 PM, Daniel Drake d...@laptop.org wrote:
Note that during the insmod/rmmod calls, runtime PM did not touch the
power state - the card remained powered ever since the first insmod.
Not sure if this is in-line with your expectations.
It definitely isn't. And that may
Hi Zhangfei,
On Fri, Jun 10, 2011 at 5:02 AM, zhangfei gao zhangfei@gmail.com wrote:
Here is answer got from the sd8686 maintainer.
For 8686, the SDIO state machine can only handle init sequence (CMD5,
5, 3, 7) from host once. If host sends another init sequence, it will
not be able to
On Sat, Jun 11, 2011 at 5:33 AM, zhangfei gao zhangfei@gmail.com wrote:
If you power down and up the device, then IO reset is not needed and
8686 can process host init sequence correctly.
Thanks, that's what I thought.
Daniel, this ultimately means that whenever sending a reset is
required
On Thu, Jun 16, 2011 at 8:27 PM, Daniel Drake d...@laptop.org wrote:
Why is there so much power flipping going on during resume?
There isn't.
You see this with libertas, because it doesn't really suspend/resume cleanly.
Instead, it uses a pretty awkward (in my opinion) mechanism to remove
the
On Fri, Jun 17, 2011 at 4:58 PM, Daniel Drake d...@laptop.org wrote:
Ignore the probe error - just observe the fact that the card was
detected and powered on, powered off, powered on and *then* probed.
This is the normal behavior today when drivers are probed: we power up
the card before
Hi Chris,
On Fri, Jun 10, 2011 at 2:40 AM, Ohad Ben-Cohen o...@wizery.com wrote:
After commit e1866b3 PM / Runtime: Rework runtime PM handling
during driver removal was introduced, the driver core stopped
incrementing the runtime PM usage counter of the device during
the invocation
-by: Daniel Drake d...@laptop.org
Thanks for your work, Daniel.
Acked-by: Ohad Ben-Cohen o...@wizery.com
--
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 Sat, Jun 25, 2011 at 9:23 PM, Daniel Drake d...@laptop.org wrote:
Now we just need you to submit the remaining parts of
http://dev.laptop.org/~dsd/20110609/sd-pwr-debug6.patch - can you take
care of that? I'm not sure if/how it should be split up or how to
write the commit message.
Sure,
Hi Zhangfei,
On Tue, Jun 28, 2011 at 12:13 PM, zhangfei gao zhangfei@gmail.com wrote:
One question :(
Np, feel free to ask !
(but it's usually better to start a new thread, rather then forking an
existing one under the same subject)
Under pm_runtime mechanism, how to dynamically
On Tue, Jun 28, 2011 at 11:59 PM, Daniel Drake d...@laptop.org wrote:
On 28 June 2011 06:55, Ohad Ben-Cohen o...@wizery.com wrote:
Obviously the second hunk is necessary, but I'd like to know whether
the first one really is too or not. Can you please retest this without
that hunk (try
On Wed, Jun 29, 2011 at 12:54 AM, Daniel Drake d...@laptop.org wrote:
Too many patches floating around, just trying to be sure of what I'm doing!
Ok, let's start from fresh :)
Let's take 3.0-rc5, it already includes our work:
297c7f2 mmc: sdio: fix runtime PM path during driver removal
c6e633a
On Wed, Jun 29, 2011 at 11:43 AM, zhangfei gao zhangfei@gmail.com wrote:
However still not fully understand how to call -remove to power off
wlan, using suspend system looks to me is only test method, which
counting on bus_ops-suspend returns -ENOSYS.
Please take a look at mac80211 and
On Wed, Jun 29, 2011 at 12:19 PM, zhangfei gao zhangfei@gmail.com wrote:
Enable wlan: # ifconfig up mlan0 - power up the chip via runtime PM
- wlan_probe download the firmware
Disable wlan: # ifconfig down mlan0 - power down the chip via runtime
PM - wlan_remove ?
Sounds all good, besides
On Fri, Jul 8, 2011 at 6:38 PM, Daniel Drake d...@laptop.org wrote:
I tested vanilla and realised that this bug exists there too
I'm aware of it - it's caused (indirectly) by another PM core change,
which since then was already changed again in 3.1.
Btw sorry for not being responsive - I've
On Wed, Sep 7, 2011 at 10:03 PM, Daniel Drake d...@laptop.org wrote:
Adding random sleeps without understanding what exactly do they solve
generally feels wrong...
Well, if you remove the existing sleeps from mmc_power_up do things
keep working for you?
I wouldn't call them random - they're
On Wed, Sep 7, 2011 at 10:03 PM, Daniel Drake d...@laptop.org wrote:
On Wed, Sep 7, 2011 at 12:44 PM, Ohad Ben-Cohen o...@wizery.com wrote:
No, I wouldn't write a driver for this...
I suggest first to understand exactly what's the bug, and that really
involves using a scope here.
I'll see
On Fri, Sep 16, 2011 at 6:33 PM, Daniel Drake d...@laptop.org wrote:
Do you know the source of that info?
No, not more than what the comments say.
It also seems that the first delay was originally 1ms and at some
point it was increased to 2ms (commit
f9996aee36921e8f1d499de1b2ea380855cf6d97
On Sun, Oct 30, 2011 at 10:06 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
...
All of the patches have been tested in linux-next and currently there
are no merge conflicts, though I expect one to happen
Hi Joe,
On Fri, Nov 18, 2011 at 10:53 AM, Joe Woodward j...@terrafix.co.uk wrote:
Are these workarounds expected to be enough for runtime PM to just work?
It definitely works for 12xx, and with Daniel's recent work merged I
think it also works fine for the sd8686 (Daniel, PCMIIW).
Ohad.
--
To
On Fri, Nov 18, 2011 at 12:00 PM, Joe Woodward j...@terrafix.co.uk wrote:
I'm assuming these changes have already made it to the mainline, and
therefore are in the 3.2rc2 build I was testing...
Most probably, yeah.
Is there anything I can do to debug further the problems I'm seeing?
Let's
On Tue, Nov 29, 2011 at 1:17 PM, Joe Woodward j...@terrafix.co.uk wrote:
Any more feedback on this?
Daniel, can you please take a look ?
Joe, Daniel's patch is long term the right thing to do, so I hope we
could understand and solve the issue you have and still go on with
Daniel's long term
Hi Daniel,
On Tue, Nov 29, 2011 at 11:42 PM, Daniel Drake d...@laptop.org wrote:
Even though I have the pleasure of working with 8686 quite a bit
(Is there a subtle cynicism here ? :)
So first thing to do is to investigate the source of this error, as before:
[ 34.637481] libertas_sdio:
fd9fec7a00f58a16803e37a99a014ef82543ef6f
Author: Ohad Ben-Cohen o...@wizery.com
Date: Wed Nov 30 16:22:13 2011 +0200
Revert mmc: enable runtime PM by default
When SDIO runtime PM was originally introduced, we immediately faced
two regressions with two different chipsets, and in response decided
On Wed, Nov 30, 2011 at 4:57 PM, Daniel Drake d...@laptop.org wrote:
If we go ahead with the revert, can you help me come up with a way to
whitelist it for OLPC?
Sure thing.
Would a DMI-based quirk in sdhci be acceptable for you?
I wasn't following sdhci development so much as I'm not
On Wed, Nov 30, 2011 at 5:00 PM, Joe Woodward j...@terrafix.co.uk wrote:
It seems CMD5 fails (which seems to be what the workarounds were aiming to
fix).
Right; you get a timeout (-110), which means the 8686 didn't send any response.
This is unexpected because the sdio reset (the CMD52 you
Hi Neil,
On Mon, Dec 5, 2011 at 3:54 AM, NeilBrown ne...@suse.de wrote:
I've been chasing down a problem with the SDIO-attached wifi card in the
GTA04 (www.gta04.org).
8686, right ?
The problem seems very similar to that described in
On Mon, Dec 5, 2011 at 9:06 PM, NeilBrown ne...@suse.de wrote:
Challenge accepted.
cool :)
Even if I don't find a better solution, this seems backwards. Sure the
default should be that PM is enabled, but individual board can request no
PM on MMC interfaces where it is a problem.
I somewhat
On Sat, Dec 10, 2011 at 9:15 AM, NeilBrown ne...@suse.de wrote:
When I force it to hold off suspend for a little while I see (starting at the
same place):
[ 656.189697] bus: 'sdio': driver_probe_device: matched device mmc1:0001:1
with driver libertas_sdio
[ 656.212768] bus: 'sdio':
Hi Tony,
On Tue, Jan 10, 2012 at 7:44 AM, Lin Tony-B19295 b19...@freescale.com wrote:
[Tony Lin]does it mean Runtime PM is not fully supported by SD/MMC stack?
SDIO runtime PM is fully supported (there were also some initial MMC
runtime PM patches circulating at some point, but they were not
Hi Elvis,
On Wed, Oct 27, 2010 at 3:24 PM, Elvis Dowson elvis.dow...@mac.com wrote:
r...@beagleboard:/wlan# insmod sdio.ko
...
r...@beagleboard:/wlan# insmod tiwlan_drv.ko
...
r...@beagleboard:/wlan# ifconfig tiwlan0 up
[ 200.916687] TIWLAN: 2227.094325:
Hi Daniel,
On Wed, Oct 27, 2010 at 8:46 PM, Daniel Drake d...@laptop.org wrote:
Hi,
Testing linux-next, I get a crash during resume. Reproduced on an
XO-1.5. mmc1 is the wifi card, for which the driver is not loaded.
For some reason I can't get linux-next to boot on my setup (strangely
VFS
Hi Daniel,
On Wed, Oct 27, 2010 at 10:37 PM, Ohad Ben-Cohen o...@wizery.com wrote:
...
can you please tell me if you can reproduce this with mmc-next ?
Can you please also send full logs (from boot to crash preferably) + .config ?
Please 'echo 8 /proc/sys/kernel/printk' before generating
Hi Chris,
On Thu, Oct 28, 2010 at 4:55 PM, Chris Ball c...@laptop.org wrote:
I'll just give you an XO-1.5 at LPC -- that way you can work on it
either during the conference or afterwards. We should still get a
.config from Daniel, though, and steps to reproduce.
That would be really good,
On Thu, Oct 28, 2010 at 6:40 PM, Kishore Kadiyala
kishorek.kadiy...@gmail.com wrote:
On Thu, Oct 28, 2010 at 9:43 PM, Nicolas Pitre n...@fluxnic.net wrote:
This is not clear that this is something that the core can effectively
help with. Opportunistic power saving at the host controller level
On Fri, Oct 29, 2010 at 12:47 PM, Roger Quadros roger.quad...@nokia.com wrote:
just to be sure, we're talking about controller clock and not card clock.
right?
yes.
driver will gate the clock to the controller .
Just make sure you call pm_suspend_ignore_children(), because you want
to be
On Fri, Oct 29, 2010 at 4:48 PM, Daniel Drake d...@laptop.org wrote:
- Just for general knowledge - as soon as you load your driver
(libertas, right ?) - was your card powered up and correctly
configured (sdio clock/voltage/bus width. again check with
/sys/kernel/debug/mmc2/ios) ?
No driver
On Sun, Oct 31, 2010 at 4:55 PM, Daniel Drake d...@laptop.org wrote:
/*
* For native busses: set card RCA and quit open drain mode.
*/
if (!powered_resume !mmc_host_is_spi(host)) {
err = mmc_send_relative_addr(host, card-rca);
This returns -110
On Sun, Oct 31, 2010 at 5:10 PM, Daniel Drake d...@laptop.org wrote:
On 31 October 2010 15:08, Ohad Ben-Cohen o...@wizery.com wrote:
Quick question - how did you manage the power to the sd8686 ? Was it
possible to power it down after boot or was it always kept high ?
I didn't do anything
On Sun, Oct 31, 2010 at 5:21 PM, Daniel Drake d...@laptop.org wrote:
The power can be controlled by the regular SD power pin. There is no
GPIO to control it.
OK, Good.
Can you please tell me the output of the following line
(after boot, but before you load the driver):
cat
On Sun, Oct 31, 2010 at 5:57 PM, Daniel Drake d...@laptop.org wrote:
cat /sys/kernel/debug/mmc1/ios
clock: 0 Hz
vdd: 0 (invalid)
bus mode: 1 (open drain)
chip select: 0 (don't care)
power mode: 0 (off)
bus width: 0 (1 bits)
timing spec: 0 (legacy)
On Sun, Oct 31, 2010 at 6:24 PM, Daniel Drake d...@laptop.org wrote:
On 31 October 2010 16:16, Ohad Ben-Cohen o...@wizery.com wrote:
Just to make sure - on an older kernel (that doesn't have SDIO runtime
pm), the card is powered on at this stage (this info will help me rule
out some corner
Hi Arnd,
On Sun, Oct 31, 2010 at 7:16 PM, Arnd Hannemann a...@arndnet.de wrote:
b43-sdio: probe of mmc0:0001:1 failed with error -16
It's exactly what Daniel is experiencing with the XO-1.5.
In Daniel's scenario, mmc_sdio_init_card() fails because
mmc_send_relative_addr() returns -110.
Can
On Sun, Oct 31, 2010 at 11:51 PM, Arnd Hannemann a...@arndnet.de wrote:
In Daniel's scenario, mmc_sdio_init_card() fails because
mmc_send_relative_addr() returns -110.
Can you please check out if that's the same thing you have too ?
No, it seems to be the pm_runtime_get_sync in
Hi Daniel,
On Sun, Oct 31, 2010 at 9:06 PM, Ohad Ben-Cohen o...@wizery.com wrote:
...
we need to support boards with controllers/cards
which we can't power off in runtime.
On such boards, the right thing to do would be to disable runtime PM
altogether.
The patch below (/attached) should
that capability).
Can you please see if the problem goes away with it ?
Thanks,
Ohad.
From 6b5691bdd8184cc0876d209c69d38844ea10f678 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Mon, 1 Nov 2010 09:41:44 +0200
Subject: [PATCH] mmc: add MMC_CAP_RUNTIME_PM
Some board/card/host
On Mon, Nov 1, 2010 at 4:22 PM, Arnd Hannemann a...@arndnet.de wrote:
It looks like this:
r...@ap4evb:~# modprobe b43
[ 36.023437] cfg80211: Calling CRDA to update world regulatory domain
[ 36.460937] sdio_bus_probe()
[ 36.468750] sdio_bus_probe() calling pm_runtime_get_sync()
[
On Sun, Oct 31, 2010 at 6:06 PM, Linus Walleij
linus.wall...@stericsson.com wrote:
This patch modifies the MMC core code to optionally call the
set_ios() operation on the driver with the clock frequency set
to 0 (gate) after a grace period of at least 8 MCLK cycles, then
restore it (ungate)
On Fri, Nov 5, 2010 at 4:35 AM, Linus Walleij
linus.wall...@stericsson.com wrote:
Nicolas Pitre wrote:
Maybe the runtime PM stuff is not the right abstraction for this?
Hm, yeah the bad thing is that I can't reuse the delay code
from runtime PM.
Why not ?
But all the hazzle of creating
Hi Phillip,
On Sat, Nov 6, 2010 at 1:38 AM, Philip Rakity prak...@marvell.com wrote:
d) keep sdio clock gating OFF -- need this from our experience.
I'm really interested to hear more about that one - what issues did you see ?
Can you please elaborate ?
Thanks,
Ohad.
--
To unsubscribe from
feature.
b) hardware doing clock gating with SDIO is BAD -- we see the same issues
that s/w clock gating patch see's .. The sdio cards do not work correctly.
c) The quirk is needed to tell the core/ layer that h/w support is available.
On Nov 6, 2010, at 10:24 AM, Ohad Ben-Cohen wrote:
Hi
On Sat, Nov 6, 2010 at 11:19 PM, Daniel Drake d...@laptop.org wrote:
Thanks.
It solves the problem.
Good. Did it also solve the 1st issue you had ?
Anyway I'm still interested to reproduce that crash. No reason to get
a kernel panic whatsoever.
But, what you point out is quite interesting.
On Sun, Nov 7, 2010 at 12:51 PM, Daniel Drake d...@laptop.org wrote:
If you take the interface down, the card is still powered up in some
way.
With SDIO runtime pm support, it shouldn't be.
When I asked the hardware guy he said it was entirely controlled by
the normal SD power pin, but a
On Wed, Nov 10, 2010 at 6:25 PM, Linus Walleij
linus.wall...@stericsson.com wrote:
Not that one, because the only place where ungate is called
is immediately before the request or set_ios(). So the request
or set_ios() will complete
How can you assume that ? Nothing prevents a context switch
Hi Giuseppe,
On Wed, Nov 10, 2010 at 5:28 PM, Giuseppe CAVALLARO
peppe.cavall...@st.com wrote:
HC driver will be able to use the pm_flags to
undestand if the system can be woken-up by the driver.
So the mmc_suspend_host hasn't to reset this field
in the host structure.
Signed-off-by:
powered off in case an error
occurred, and the card is going to be removed.
Reproduced and tested on the XO-1.5.
Reported-by: Daniel Drake d...@laptop.org
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/sdio.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions
On Mon, Nov 1, 2010 at 10:27 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Sun, Oct 31, 2010 at 9:06 PM, Ohad Ben-Cohen o...@wizery.com wrote:
...
we need to support boards with controllers/cards
which we can't power off in runtime.
On such boards, the right thing to do would be to disable
: don't clear unhandled pending interrupts
tmio_mmc: don't clear unhandled pending interrupts
From 6b5691bdd8184cc0876d209c69d38844ea10f678 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Mon, 1 Nov 2010 09:41:44 +0200
Subject: [PATCH] mmc: add MMC_CAP_RUNTIME_PM
Some
for the sh_mobile_sdhi mfd, which are now in mainline:
mmc: Allow 2 byte requests in 4-bit mode for tmio_mmc
tmio_mmc: don't clear unhandled pending interrupts
tmio_mmc: don't clear unhandled pending interrupts
From 6b5691bdd8184cc0876d209c69d38844ea10f678 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Hi Jun,
On Thu, Nov 18, 2010 at 4:20 AM, Jun Nie niej0...@gmail.com wrote:
It is possible that SDIO card send card interrupt to wake up
system just after SDIO func driver and SDIO card firmware commit
suspend state, while system is still in suspending process and
mmc interrupt is not release
() failures with setups that do not
support powering off the card.
Reported-and-tested-by: Daniel Drake d...@laptop.org
Reported-and-tested-by: Arnd Hannemann a...@arndnet.de
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
This is a second fix intended to 2.6.37 (first one is at
https
On Tue, Nov 16, 2010 at 4:29 PM, Daniel Drake d...@laptop.org wrote:
On 16 November 2010 13:22, Ohad Ben-Cohen o...@wizery.com wrote:
Just to update the list, the problem with the XO-1.5 was because the
sd8686 has an external reset gpio line which is currently being
manipulated manually
On Mon, Nov 22, 2010 at 9:42 AM, saeed bishara saeed.bish...@gmail.com wrote:
On Thu, Oct 28, 2010 at 9:23 PM, Mike Rapoport m...@compulab.co.il wrote:
...
+ bool SDHCI support on Marvell's Dove SoC
...
+ If you have a controller with this interface, say Y or M here.
Just a
This patch complements ed919b0 mmc: sdio: fix runtime PM anomalies by
introducing MMC_CAP_POWER_OFF_CARD by declaring MMC_CAP_POWER_OFF_CARD
on the ZOOM's wl1271 mmc slot.
This is required in order not to break runtime PM support for the wl1271
sdio driver.
Signed-off-by: Ohad Ben-Cohen o
going on a plane and will not have Internet access so apologies
for belated replies.
Ohad Ben-Cohen (3):
mmc: skip detection of nonremovable cards on rescan
mmc: sdio: don't reinitialize nonremovable powered-resumed cards
mmc: sdio: don't power up cards on system suspend
drivers/mmc/core/core.c
.
This whole process is redundant with nonremovable cards; in those cases,
we can safely skip calling -detect() and implicitly assume its success.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/core.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git
2010/11/28 Michał Mirosław mir...@gmail.com:
snip
+
+ /* No need to reinitialize powered-resumed nonremovable cards */
+ if (mmc_card_is_removable(host) ||
!mmc_card_is_powered_resumed(host))
+ err = mmc_sdio_init_card(host, host-ocr, host-card,
2010/11/28 Ohad Ben-Cohen o...@wizery.com:
I have not switched all existing code to mmc_card_is_powered_resumed(),
I can do that as a subsequent clean up patch.
(i just prefer not to mix functional changes with cleanups in a single patch)
--
To unsubscribe from this list: send the line
Hi Yunpeng,
On Sat, Nov 27, 2010 at 9:53 PM, Yunpeng Gao yunpeng@intel.com wrote:
static int mmc_runtime_idle(struct device *dev)
{
- return pm_runtime_suspend(dev);
+ return pm_schedule_suspend(dev, 100);
You shouldn't do this here.
You didn't comment about or mentioned
On Sat, Dec 4, 2010 at 6:22 PM, Daniel Drake d...@laptop.org wrote:
In this case we are not changing current or voltage, we are just
asserting a specific signal to the card. So its messy from the start
(I'd have to invent a list of supported voltages or something).
This is exactly what we do
On Mon, Dec 6, 2010 at 10:03 PM, Daniel Drake d...@laptop.org wrote:
power_save is done by the bus, not the host, and the host does get its
opportunity to power down via the set_ios callback that comes in
telling it to turn the card off.
yes.
In fact, the actual work is being handled by
On Mon, Dec 6, 2010 at 6:37 AM, Philip Rakity prak...@marvell.com wrote:
I have seen this solved using rfkill. Is that acceptable?
It doesn't make a lot of sense.. rfkill is a few layers above.. and if
any, then an rfkill implementation will eventually end up triggering
this code and not the
On Tue, Dec 7, 2010 at 4:52 AM, zhangfei gao zhangfei@gmail.com wrote:
In marvell platfrom, we handle gpio related behavior via rfkill,
1. platfrom transfer gpio pin via platfrom data, so different platform
could have different gpio
2. rfkill block/unblock wifi/bt etc, to pull up/down
On Wed, Dec 8, 2010 at 1:13 PM, zhangfei gao zhangfei@gmail.com wrote:
Thanks for suggestion, do you mean
Not use rfkill totally
If you want rfkill functionality, you can still provide it of course,
but don't give it direct access to the hardware.
You should provide rfkill functionality
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
On Fri, Dec 10, 2010 at 7:24 PM, Alan Stern st...@rowland.harvard.edu 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
On Sat, Dec 11, 2010 at 12:01 AM, Rafael J. Wysocki r...@sisk.pl 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
On Sat, Dec 11, 2010 at 12:59 AM, Ohad Ben-Cohen o...@wizery.com 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
Hi Alan,
Sorry for the belated response,
On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern st...@rowland.harvard.edu 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
On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Think of a device which you have no way to reset other than powering
it down and up
On Sun, Dec 19, 2010 at 12:47 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
On Sat, Dec 11, 2010 at 4:50 PM, Alan
On Sat, Dec 18, 2010 at 11:20 PM, Alan Stern st...@rowland.harvard.edu 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
On Sun, Dec 19, 2010 at 12:22 PM, Rafael J. Wysocki r...@sisk.pl 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
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
Now you've lost me. Which of the driver's
On Sat, Dec 25, 2010 at 11:50 PM, Vitaly Wool vitalyw...@gmail.com 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
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().
If you're taking a look, please do so using the
On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki r...@sisk.pl 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
On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki r...@sisk.pl 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
On Tue, Dec 28, 2010 at 1:25 PM, Arnd Hannemann a...@arndnet.de wrote:
On some boards card power is hard wired to the slot
and active regardless of host controller state.
...
This was observed on AP4EVB with tmio_mmc and a b43 based
SDIO card:
http://marc.info/?l=linux-mmcm=128854536521274w=2
Hi Arnd,
On Tue, Dec 28, 2010 at 4:03 PM, Arnd Hannemann a...@arndnet.de wrote:
Do you mean that your card is always powered on regardless of
mmc_power_off() invocations ?
Yes, it seems so.
Ok, thanks for letting us know.
It bothered me that we didn't understand the issue you had, but now
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.
There are several layers of abstractions involved, from the
On Sun, Dec 26, 2010 at 8:35 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Sunday, December 26, 2010, Ohad Ben-Cohen wrote:
On Sun, Dec 26, 2010 at 1:45 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Why does the driver need the device to be reset even though it hasn't
been suspeneded yet
On Sun, Dec 26, 2010 at 8:37 PM, Rafael J. Wysocki r...@sisk.pl 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
On Tue, Dec 28, 2010 at 9:21 PM, Rafael J. Wysocki r...@sisk.pl 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
1 - 100 of 270 matches
Mail list logo
