On Wed, Jun 29, 2011 at 12:19 PM, zhangfei gao 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 the part where
On Wed, Jun 29, 2011 at 4:57 PM, Ohad Ben-Cohen wrote:
> On Wed, Jun 29, 2011 at 11:43 AM, zhangfei gao 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 -ENOS
On Wed, Jun 29, 2011 at 11:43 AM, zhangfei gao 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 wl12xx.
We're not us
On 28 June 2011 10:13, zhangfei gao wrote:
> Hi, Ohad
>
> One question :(
>
> Under pm_runtime mechanism, how to dynamically open/close wlan.
>
> If the wlan chip really power off, the firmware should be reloaded,
> since the firmware is download to ram and disappear after power off.
> So wlan pro
>> So wlan probe function should be called for re-downloading, is it be
>> achieved by calling pm_runtime_get_sync and mmc_power_restore_host?
>
> Not really;
>
> I assume you refer to libertas_sdio, which AFAICT, is built to power
> on the device (and configure it) on ->probe(), and then power it
Hi Zhangfei,
On Tue, Jun 28, 2011 at 12:13 PM, zhangfei gao 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 open/close wlan.
Actually it
Hi, Ohad
One question :(
Under pm_runtime mechanism, how to dynamically open/close wlan.
If the wlan chip really power off, the firmware should be reloaded,
since the firmware is download to ram and disappear after power off.
So wlan probe function should be called for re-downloading, is it be
a
On Sat, Jun 25, 2011 at 9:23 PM, Daniel Drake 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, i'll post it
Hi,
On Sat, Jun 25 2011, Daniel Drake wrote:
> mmc_sdio_power_restore() skips some steps that are performed in other
> power-related codepaths which are necessary to fully reset the card.
> Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.
>
> Signed-off-by: Daniel Drake
Thanks
On Sat, Jun 25, 2011 at 9:20 PM, Daniel Drake wrote:
> mmc_sdio_power_restore() skips some steps that are performed in other
> power-related codepaths which are necessary to fully reset the card.
> Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.
>
> Signed-off-by: Daniel Drake
mmc_sdio_power_restore() skips some steps that are performed in other
power-related codepaths which are necessary to fully reset the card.
Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.
Signed-off-by: Daniel Drake
---
drivers/mmc/core/sdio.c | 39 ++
Hi Ohad,
On 19 June 2011 12:00, Ohad Ben-Cohen wrote:
> But I still think it's generally better, given the alternatives.
>
> And since this should not have any bad effect for anyone else, I'm
> also OK with not wrapping the sdio_reset and the CMD5 arg=0 you're
> adding with a quirk.
>
> After tha
Hi Daniel,
On Sun, Jun 19, 2011 at 1:33 PM, Daniel Drake wrote:
> So, as I found here: http://article.gmane.org/gmane.linux.kernel.mmc/8605
> This is an OLPC-specific issue due to lack of power clamping on the
> motherboard's power supply, which might not be shared by other sd8686
> users, and a
Hi Ohad,
On 17 June 2011 15:31, Ohad Ben-Cohen wrote:
>> Yes, a regulator could work. But, aren't regulators linked to the
>> platform rather than to the card? I would imagine that this quirk
>> needs to be applied to all users of the card, therefore a card quirk
>> could be more appropriate? Als
On 17 June 2011 15:31, Ohad Ben-Cohen wrote:
> On Fri, Jun 17, 2011 at 4:58 PM, Daniel Drake 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 pro
On Fri, Jun 17, 2011 at 4:58 PM, Daniel Drake 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 probing a driver, an
On 16 June 2011 22:22, Ohad Ben-Cohen wrote:
> On Thu, Jun 16, 2011 at 8:27 PM, Daniel Drake 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.
It's not related to suspend/resume
On Thu, Jun 16, 2011 at 8:27 PM, Daniel Drake 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 card on suspend
Seeing something similar but the details are a little different. My kernel is
somewhat old but ...
Seeing this with sd card and android.
card is removed/inserted/removed/inserted etc very quickly during power
operations. After 20-30 times
a problem occurs. this can be anything from file syste
On 13 June 2011 20:52, Ohad Ben-Cohen wrote:
> We need to debug the suspend/resume path. Now that we have the other
> runtime pm paths working, we can pretty much tell there's no hw issue
> at hand.
Found it. It's a timing issue. In our other tests we had not yet hit
the case when power is remove
On Fri, Jun 10, 2011 at 7:15 PM, Daniel Drake wrote:
> Done. Without bringing suspend/resume into the picture, this is
> working fine. Power is removed when the interface goes down, and is
> restored when the interface is brought up. ios values look fine at
> every stage. Wireless card works fine
On 10 June 2011 00:27, Ohad Ben-Cohen wrote:
> The next step to have working now is really the ifconfig up/down/up
> scenario. That should come before suspend/resume. And this
> step-by-step approach is even more relevant to libertas_sdio, because
> I suspect there's some if_sdio.c refactoring nee
On Thu, Jun 9, 2011 at 10:55 PM, Daniel Drake wrote:
> On 9 June 2011 19:25, Ohad Ben-Cohen wrote:
>> let's update that patch. I'd send you an updated one, but I have to go
>> for awhile, so here's the quick change you need to do.
>
> Unfortunately it doesn't help.
That's ok. Let's go back to sm
On 9 June 2011 19:25, Ohad Ben-Cohen wrote:
> let's update that patch. I'd send you an updated one, but I have to go
> for awhile, so here's the quick change you need to do.
Unfortunately it doesn't help.
New patch:
http://dev.laptop.org/~dsd/20110609/sd-pwr-debug6.patch
During resume, this hap
On Thu, Jun 9, 2011 at 8:56 PM, Daniel Drake wrote:
> Done, the rmmod issue remains fixed - the card gets powered down during rmmod.
great !
> Next up is the problem where on this setup, if I suspend after loading
> the module, and the module asks the card to shut down during suspend,
> it fails
On 9 June 2011 18:27, Ohad Ben-Cohen wrote:
> Let's focus now on just this one sequence:
>
> - boot
> - cat /sys/.../ios (power should be off)
> - insmod
> - cat /sys/.../ios (power should be on)
> - rmmod
> - cat /sys/.../ios (power should be off again)
>
> You will see the problem now.
As I thi
On Thu, Jun 9, 2011 at 7:44 PM, Daniel Drake 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 very well be o
On 9 June 2011 17:30, Ohad Ben-Cohen wrote:
> Looks good.
>
> At this point everything works ?
> (can you bring up the interface and scan/connect)
Yes.
> Can you now do a series of insmod-rmmod-insmod.. and see if things
> always work (with no runtime pm errors) after you insmod ?
>
> If yes, we
On Thu, Jun 9, 2011 at 7:21 PM, Daniel Drake 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 (invalid)
> bu
On 9 June 2011 16:59, Ohad Ben-Cohen wrote:
> Now can you please repeat this, but this time add your original patch
> (which only added the CMD5 arg=0 cmd, no sdio reset yet) ?
With this version of the patch:
http://dev.laptop.org/~dsd/20110609/sd-pwr-debug2.patch
bash-4.1# mount -t debugfs none
On Thu, Jun 9, 2011 at 6:51 PM, Daniel Drake wrote:
> bash-4.1# mount -t debugfs none /sys/kernel/debug
> bash-4.1# 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
On 8 June 2011 21:05, Ohad Ben-Cohen wrote:
> Please reboot, and immediately after booting (without insmoding the
> driver) tell me what's the output of :
>
> mount -t debugfs none /sys/kernel/debug
> cat /sys/kernel/debug/mmc1/ios
>
> Then insmod the driver, and tell me again what's the output of
On Wed, Jun 8, 2011 at 11:58 PM, Daniel Drake wrote:
>> Please reboot, and immediately after booting (without insmoding the
>> driver) tell me what's the output of :
>>
>> mount -t debugfs none /sys/kernel/debug
>> cat /sys/kernel/debug/mmc1/ios
>
> Which base kernel setup should I run these tests
On 8 June 2011 21:05, Ohad Ben-Cohen wrote:
> We have 3 power-on paths here: on boot, on insmod, and and resume.
>
> I understand the first one succeeds (naturally), and the last one
> failed, but now I'm confused what was the outcome of the 2nd (without
> sending a reset cmd) ?
Not really sure w
On Wed, Jun 8, 2011 at 5:21 PM, Daniel Drake wrote:
>> 1. How come power off+on works for you in the first time, but doesn't
>> work in the second time ?
>
> I assume it is because a different codepath was taken in order to
> power up the device the first time, before it then got powered down,
> c
On 8 June 2011 15:02, Ohad Ben-Cohen wrote:
> On Wed, Jun 8, 2011 at 4:36 PM, Daniel Drake wrote:
>> If I add the reset (shown commented-out in the patch), it matches the
>> behaviour of other known-good codepaths and also solves the problem.
>
> Yeah, but we don't know why. And we may very well
On Wed, Jun 8, 2011 at 4:36 PM, Daniel Drake wrote:
> If I add the reset (shown commented-out in the patch), it matches the
> behaviour of other known-good codepaths and also solves the problem.
Yeah, but we don't know why. And we may very well be covering a
different bug if we just take it as-is
On 8 June 2011 10:33, Ohad Ben-Cohen wrote:
> Sounds like you didn't power the card off then in the driver after probe ?
>
> Can you show the diff with which you did this experiment ?
Attached. This is on top of your fix for correct driver deinit during suspend.
Test case is:
1. boot, load liber
On Wed, Jun 8, 2011 at 12:20 PM, Daniel Drake wrote:
> In the first patch I sent I had only tested basic power-up after
> probe, and found it to be working. Then I tested the other scenarios
> listed in my last mail - basically powering it off and on *again* -
> and found them to be broken, but fi
On 7 June 2011 21:52, Ohad Ben-Cohen wrote:
> Uhm, strange. Maybe this has something to do with the sd8686's reset
> line which you are not toggling ?
The GPIO reset line doesn't seem to make any difference here.
> Btw, the previous patch which you sent didn't have this reset command,
> and the
On Tue, Jun 7, 2011 at 7:41 PM, Daniel Drake wrote:
> On 5 June 2011 14:48, Ohad Ben-Cohen wrote:
>> Sending a reset is necessary only if we are re-initing a powered on
>> card, but in this case, we know that we just powered the card up, so
>> this is not needed.
>
> Don't ask me for an explanati
On Tue, Jun 7, 2011 at 7:41 PM, Daniel Drake wrote:
> Also, the most frustrating thing when working on this issue is that
> the codepaths for powering up a SD card between the following 3
> situations are significantly different:
> 1. Power up and probe during boot
> 2. Resume from suspend
> 3.
On 5 June 2011 14:48, Ohad Ben-Cohen wrote:
>> +
>> + /*
>> + * Reset the card by performing the same steps that are taken by
>> + * mmc_rescan_try_freq() and mmc_attach_sdio() during a "normal"
>> probe
>> + */
>> + sdio_reset(host);
>
> Sending a reset is necess
Hi Daniel,
On Sun, Jun 5, 2011 at 3:38 PM, Daniel Drake wrote:
> @@ -706,10 +706,25 @@ static int mmc_sdio_power_restore(struct mmc_host *host)
> BUG_ON(!host->card);
>
> mmc_claim_host(host);
> +
> + /*
> + * Reset the card by performing the same steps that are taken b
mmc_sdio_power_restore() skips some steps that are performed in other
power-related codepaths which are necessary to fully reset the card.
Without this, the card can't be powered up and probe fails.
All these steps are needed, to satisfy the cases of both normal
runtime PM and also suspend/resume
45 matches
Mail list logo
