Re: mmc: sdio: runtime PM and 8686 problems
-Original Message- From: Steve Sakoman To: Ohad Ben-Cohen Cc: Chris Ball , Joe Woodward , linux-mmc@vger.kernel.org, Neil Brown , Bing Zhao , Daniel Drake Date: Thu, 26 Apr 2012 16:51:10 -0700 Subject: Re: mmc: sdio: runtime PM and 8686 problems > On Mon, Dec 19, 2011 at 1:10 AM, Ohad Ben-Cohen > wrote: > > > We're slowly progressing towards understanding the issues we have > with > > the 8686 (it seems there are a few different hw revisions of it, some > > of which do require toggling the reset pin before sending another > init > > sequence), but it might take some more time until a solution fully > > materializes. > > > > Since 3.2 is just around the corner, I suggest we should now proceed > > with the revert (see patch below), and later revisit this once we > have > > a complete solution in hand. > > Has any progress been made on this issue? > > I too have been trying to power down/up the wifi module on the Overo. > I'm seeing the same issue described in this thread. > > Some additional data: > > I rebuilt my kernel (3.2) with a CD GPIO enabled for the mmc port the > module > is connected to and in turn connected that GPIO to another one that I > can toggle from user space. > > Toggling the CD GPIO after powering back up the module does indeed > work properly -- the module is detected, the driver loaded, and proper > function > restored. > > So basically the procedure I've used is: > > - decide wifi can be powered down > - unload the libertas modules > - put the wifi hw in reset with gpio16 > - wait till wifi is needed again > - take the chip out of reset > - toggle the CD gpio > - libertas modules are autoloaded, as is the firmware > - wifi is up and functioning > > So the next step is to get rid of the silly two GPIO external hardware > hack. Is it possible to trigger a card insertion/removal event via > some standard API? > > Or does the above information provide a clue as to why normal code > paths don't work? > > Any other ideas? > > Steve > Since the patch has been reverted (i.e. no runtime PM) I haven't seen a problem. I've not put any more work in to getting it to work with runtime PM i'm afriad. On a side note, I'm doing something very similar to you with my Overo, except with one difference. Where you have routed a GPIO externally which you can toggle from userspace, I've hacked the MMC driver (omap_hsmmc.c) to add a sysfs entry to force a re-scan. This also allows me to safely remove/insert SD cards (as the Overo SDCard slot doesn't have a card-detect pin) when the device is running (I run from a ramfs). I've thought for a while that a userspace hook to kick the MMC driver where this is no physical GPIO would be useful in mainline, but haven't done any more about it. Also, I've appled the first pass of patches to enable Libertas async firmware loading (as required by newer UDEVs). I have two scripts pasted below to turn on/off the WiFi (the delays just work for me, I know they are not optimal). Hope this helps. Cheers, Joe > cat #wifi-down.sh #!/bin/sh echo "Turning off WiFi..." echo "...stopping wlan0 interface" ifdown wlan0 echo "...unloading WiFi kernel module" modprobe -r libertas_sdio echo "...disabling power to WiFi chip" if [ -e /sys/class/gpio/gpio16/value ] ; then echo "...already exported GPIO reset control" else echo "...exporting GPIO reset control" echo 16 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio16/direction fi echo 0 > /sys/class/gpio/gpio16/value echo "...removing wpa configuration file" rm /tmp/wpa_supplicant.conf echo "..rescanning the MMC/SDIO as we have powered down the WiFi chip" echo 1 > /sys/bus/platform/drivers/omap_hsmmc/omap_hsmmc.1/mmc_host/mmc1/rescan sleep 2 echo "...done" #> cat wifi-up.sh #!/bin/sh # Get the network parameters. SSID=$1 PSK=$2 echo "Turning on WiFi..." echo "...enabling power to WiFi chip" if [ -e /sys/class/gpio/gpio16/value ] ; then echo "...already exported GPIO reset control" else echo "...exporting GPIO reset control" echo 16 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio16/direction fi echo 0 > /sys/class/gpio/gpio16/value usleep 10 echo 1 > /sys/class/gpio/gpio16/value usleep 10 echo "..rescanning the MMC/SDIO as we have powered up the WiFi chip" echo 1 > /sys/bus/platform/drivers/omap_hsmmc/omap_hsmmc.1/mmc_host/mmc1/rescan ### Wait for the device to be found. sleep 2 ### Set up the AP and password. echo "...adding wpa configuration file" rm /tmp/wpa_supplicant.conf echo "ctrl_interface=/var/r
Re: mmc: sdio: runtime PM and 8686 problems
Right, a bit more information. First I tried just adding delays as suggested: # Delays in core.c:mmc_power_up() increased to 1000. # Delay in core.c:mmc_power_off() increased to 1000. # sdio.c:mmc_sdio_power_restore() modified to add delays. ... msleep(500); sdio_reset(host); msleep(500); mmc_go_idle(host); msleep(500); mmc_send_if_cond(host, host->ocr_avail); msleep(500); ret = mmc_send_io_op_cond(host, 0, &ocr); ... And there was no improvement (it slowed down the probe a lot!), so I tried again with much longer delays (3 seconds rather than 500ms) and still no change. So I added control of the nRESET line in sdio.c:mmc_sdio_power_restore(). ... gpio_set_value(16, 0); /* GPIO16 is the nRESET line */ msleep(10); gpio_set_value(16, 1); msleep(100); msleep(3000); sdio_reset(host); msleep(3000); mmc_go_idle(host); msleep(3000); mmc_send_if_cond(host, host->ocr_avail); msleep(3000); ... and things sprung in to life, well sometimes! Sadly this only worked intermittently, and only with longer delays. I guess this may not be a suprise, as I'm force resetting the card but not doing a full "probe". I'm afraid I can't probe the nRESET line as the SD8686 is hidden under a shielding can, and I don't have the schematics for the GUMSTIX Overo to be able to look for the signal anywhere else. With the SD8686 only working every now and again with the nRESET control it's difficult to make progress as I'm stabbing around in the dark - I never really know if I'm improving things or not when adding/removing timeouts etc... Previous kernel's never had runtime PM enabled, so I'm not sure what you mean to compare there? Whatever procedure is first applied to the SD8686 with runtime PM disabled works 100% of the time. Does anyone know if OLPC keep any out-of-tree patches to make runtime PM work for them on the SD8686 (maybe fudging GPIOs or similar)? Cheers, Joe -Original Message- From: Daniel Drake To: Joe Woodward Cc: Ohad Ben-Cohen , linux-mmc@vger.kernel.org, Chris Ball Date: Sat, 3 Dec 2011 10:44:18 -0600 Subject: Re: mmc: sdio: runtime PM and 8686 problems > On Thu, Dec 1, 2011 at 5:28 AM, Joe Woodward wrote: > > I've had a play with the nRESET line (as far as I can tell it is the > only pin I have access to), and no joy. > > > > Also tried playing about a bit with the CMD sequence, again no joy. > > > > I'm not entirely sure of the CMD sequence. It seems we get: > > - CMD52 (x2) > > - CMD0 > > - CMD8 (fails) > > - CMD5 (fails) > > > > In the "SDIO Simplified Specification Version 2.00" > (https://www.sdcard.org/developers/overview/sdio/sdio_spec/Simplified_S > DIO_Card_Spec.pdf) page 6 it > > seems only a CMD52 should be required to "Re-init IO". Previous > thread posts state CMD5 (x2) are required by the 8686, but why > CMD0/CMD8? > > > > Incidentally errors only occur after the CMD0, but before the first > error we get (i.e. a change of cs from 1 to 0): > > "mmc1: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0 > timing 0". > > Can you see how this compares with older working kernels? > > Some more things to try: > there are some delays in mmc_power_off - try increasing them to 1000. > > > mmc_sdio_power_restore does: > sdio_reset (cmd52) > mmc_go_idle (cmd0) > mmc_send_if_cond (cmd8) > mmc_send_io_op_cond (cmd52) > > These are the commands you have been looking at from the angle of the > logs. > > Try sprinkling in a load of msleep(500) delays before and inbetween > those commands. And if you suspect some of them are not necessary > trying removing them, etc. > > Non-scientific but this is how we have got things working so far :) > > Thanks, > Daniel > -- > 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 -- 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
Re: mmc: sdio: runtime PM and 8686 problems
I've had a play with the nRESET line (as far as I can tell it is the only pin I have access to), and no joy. Also tried playing about a bit with the CMD sequence, again no joy. I'm not entirely sure of the CMD sequence. It seems we get: - CMD52 (x2) - CMD0 - CMD8 (fails) - CMD5 (fails) In the "SDIO Simplified Specification Version 2.00" (https://www.sdcard.org/developers/overview/sdio/sdio_spec/Simplified_SDIO_Card_Spec.pdf) page 6 it seems only a CMD52 should be required to "Re-init IO". Previous thread posts state CMD5 (x2) are required by the 8686, but why CMD0/CMD8? Incidentally errors only occur after the CMD0, but before the first error we get (i.e. a change of cs from 1 to 0): "mmc1: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0 timing 0". Any thoughts? I think we've probably hit the end of the line here, unless someone else pops up who knows more about the Gumstix (i.e. has access to a schematic) or the W2CBW003 and it's SD8686 internals. Thanks for the help anyway chaps! Cheers, Joe -----Original Message- From: Ohad Ben-Cohen To: Joe Woodward Cc: Daniel Drake , linux-mmc@vger.kernel.org, Chris Ball Date: Thu, 1 Dec 2011 10:07:24 +0200 Subject: Re: mmc: sdio: runtime PM and 8686 problems > On Wed, Nov 30, 2011 at 5:00 PM, Joe Woodward > 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 see before > the init sequence) should be enough to reset the device (we confirmed > this with the Marvell folks on this list awhile ago). > > > I'm afraid I may not be of much more use as Gumstix (annoyingly) > don't release schematics of their COMs, so actually probing any signals > isn't really possible. > > Yes, it makes it difficult to debug. > > You can try to verify (in the code) that all the text book > prerequisites are there (e.g. all SDIO lines are pulled up and muxed > correctly. though since stuff work for you without SDIO runtime PM, I > assume these are ok), and maybe even play a bit with stuff like > delays, sdio resets and power cycles and see if things change. If you > have access to the other inputs of the 8686 (it has several of them > which are related to power and resets. Neither me nor Daniel have > intimate knowledge about what any of those really do, but you could > dig some info from emails send by Marvell folks on this list), then > you can also try to play with them and see if things change. With > luck, you could learn more about the problem and can hopefully get > closer to finding a solution. > > It could be great if a solution will be found, but if not, we'll > probably have to proceed with the revert... > > Good luck! > Ohad. > -- > 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 -- 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
Re: mmc: sdio: runtime PM and 8686 problems
I've had a play with the nRESET line (as far as I can tell it is the only pin I have access to), and no joy. Also tried playing about a bit with the CMD sequence, again no joy. I'm not entirely sure of the CMD sequence. It seems we get: - CMD52 (x2) - CMD0 - CMD8 (fails) - CMD5 (fails) In the "SDIO Simplified Specification Version 2.00" (https://www.sdcard.org/developers/overview/sdio/sdio_spec/Simplified_SDIO_Card_Spec.pdf) page 6 it seems only a CMD52 should be required to "Re-init IO". Previous thread posts state CMD5 (x2) are required by the 8686, but why CMD0/CMD8? Incidentally errors only occur after the CMD0, but before the first error we get (i.e. a change of cs from 1 to 0): "mmc1: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0 timing 0". Any thoughts? I think we've probably hit the end of the line here, unless someone else pops up who knows more about the Gumstix (i.e. has access to a schematic) or the W2CBW003 and it's SD8686 internals. Thanks for the help anyway chaps! Cheers, Joe -----Original Message- From: Ohad Ben-Cohen To: Joe Woodward Cc: Daniel Drake , linux-mmc@vger.kernel.org, Chris Ball Date: Thu, 1 Dec 2011 10:07:24 +0200 Subject: Re: mmc: sdio: runtime PM and 8686 problems > On Wed, Nov 30, 2011 at 5:00 PM, Joe Woodward > 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 see before > the init sequence) should be enough to reset the device (we confirmed > this with the Marvell folks on this list awhile ago). > > > I'm afraid I may not be of much more use as Gumstix (annoyingly) > don't release schematics of their COMs, so actually probing any signals > isn't really possible. > > Yes, it makes it difficult to debug. > > You can try to verify (in the code) that all the text book > prerequisites are there (e.g. all SDIO lines are pulled up and muxed > correctly. though since stuff work for you without SDIO runtime PM, I > assume these are ok), and maybe even play a bit with stuff like > delays, sdio resets and power cycles and see if things change. If you > have access to the other inputs of the 8686 (it has several of them > which are related to power and resets. Neither me nor Daniel have > intimate knowledge about what any of those really do, but you could > dig some info from emails send by Marvell folks on this list), then > you can also try to play with them and see if things change. With > luck, you could learn more about the problem and can hopefully get > closer to finding a solution. > > It could be great if a solution will be found, but if not, we'll > probably have to proceed with the revert... > > Good luck! > Ohad. > -- > 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 -- 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
Re: mmc: sdio: runtime PM and 8686 problems
I've had a play with the nRESET line (as far as I can tell it is the only pin I have access to), and no joy. Also tried playing about a bit with the CMD sequence, again no joy. I'm not entirely sure of the CMD sequence. It seems we get: - CMD52 (x2) - CMD0 - CMD8 (fails) - CMD5 (fails) In the "SDIO Simplified Specification Version 2.00" (https://www.sdcard.org/developers/overview/sdio/sdio_spec/Simplified_SDIO_Card_Spec.pdf) page 6 it seems only a CMD52 should be required to "Re-init IO". Previous thread posts state CMD5 (x2) are required by the 8686, but why CMD0/CMD8? Incidentally errors only occur after the CMD0, but before the first error we get (i.e. a change of cs from 1 to 0): "mmc1: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0 timing 0". Any thoughts? I think we've probably hit the end of the line here, unless someone else pops up who knows more about the Gumstix (i.e. has access to a schematic) or the W2CBW003 and it's SD8686 internals. Thanks for the help anyway chaps! Cheers, Joe -----Original Message- From: Ohad Ben-Cohen To: Joe Woodward Cc: Daniel Drake , linux-mmc@vger.kernel.org, Chris Ball Date: Thu, 1 Dec 2011 10:07:24 +0200 Subject: Re: mmc: sdio: runtime PM and 8686 problems > On Wed, Nov 30, 2011 at 5:00 PM, Joe Woodward > 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 see before > the init sequence) should be enough to reset the device (we confirmed > this with the Marvell folks on this list awhile ago). > > > I'm afraid I may not be of much more use as Gumstix (annoyingly) > don't release schematics of their COMs, so actually probing any signals > isn't really possible. > > Yes, it makes it difficult to debug. > > You can try to verify (in the code) that all the text book > prerequisites are there (e.g. all SDIO lines are pulled up and muxed > correctly. though since stuff work for you without SDIO runtime PM, I > assume these are ok), and maybe even play a bit with stuff like > delays, sdio resets and power cycles and see if things change. If you > have access to the other inputs of the 8686 (it has several of them > which are related to power and resets. Neither me nor Daniel have > intimate knowledge about what any of those really do, but you could > dig some info from emails send by Marvell folks on this list), then > you can also try to play with them and see if things change. With > luck, you could learn more about the problem and can hopefully get > closer to finding a solution. > > It could be great if a solution will be found, but if not, we'll > probably have to proceed with the revert... > > Good luck! > Ohad. > -- > 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 -- 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
Re: mmc: sdio: runtime PM and 8686 problems
(For reference I have a Gumstix Fire (OMAP3530) revision R3118 plugged in to a PALO43 expansion board. The Gumstix Fire contains a W2CBW003, which in turn contains a Marvell 8686 SDIO WiFi). Running linux-3.2-rc2 built with the omap2plus_defconfig (with a few features minor tweaks). With the "stock" kernel I get: # modprobe libertas_sdio [ 25.813598] lib80211: common routines for IEEE802.11 drivers [ 26.141082] cfg80211: Calling CRDA to update world regulatory domain [ 26.373718] libertas_sdio: Libertas SDIO driver [ 26.378479] libertas_sdio: Copyright Pierre Ossman [ 26.433105] libertas_sdio: probe of mmc1:0001:1 failed with error -16 So, I've enabled MMC_DEBUG (in Kconfig) and the DEBUG defines in libertas/defs.h, and now get: [4.036682] mmc1: new SDIO card at address 0001 [4.042510] - [4.052459] mmc1: mmc_power_save_host: powering down [ 31.223724] libertas_sdio: Libertas SDIO driver [ 31.228485] libertas_sdio: Copyright Pierre Ossman [ 31.233703] mmc1: mmc_power_restore_host: powering up [ 31.239074] mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 20 width 0 timing 0 [ 31.239349] omap_hsmmc omap_hsmmc.1: context was not lost [ 31.239379] omap_hsmmc omap_hsmmc.1: enabled [ 31.239410] omap_hsmmc omap_hsmmc.1: Set clock to 0Hz [ 31.243438] omap_hsmmc omap_hsmmc.1: disabled [ 31.262451] mmc1: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0 timing 0 [ 31.262725] omap_hsmmc omap_hsmmc.1: context was not lost [ 31.262725] omap_hsmmc omap_hsmmc.1: enabled [ 31.262786] omap_hsmmc omap_hsmmc.1: Set clock to 40Hz [ 31.263092] omap_hsmmc omap_hsmmc.1: disabled [ 31.286163] omap_hsmmc omap_hsmmc.1: context was not lost [ 31.286193] omap_hsmmc omap_hsmmc.1: enabled [ 31.286224] mmc1: starting CMD52 arg 0c00 flags 0195 [ 31.286254] omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x0c00 [ 31.286590] omap_hsmmc omap_hsmmc.1: IRQ Status is 1 [ 31.286621] mmc1: req done (CMD52): 0: 1000 [ 31.286682] mmc1: starting CMD52 arg 8c08 flags 0195 [ 31.286682] omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x8c08 [ 31.287017] omap_hsmmc omap_hsmmc.1: IRQ Status is 1 [ 31.287048] mmc1: req done (CMD52): 0: 1008 [ 31.287109] mmc1: clock 40Hz busmode 2 powermode 2 cs 1 Vdd 20 width 0 timing 0 [ 31.287109] omap_hsmmc omap_hsmmc.1: Set clock to 40Hz [ 31.288146] mmc1: starting CMD0 arg flags 00c0 [ 31.288177] omap_hsmmc omap_hsmmc.1: mmc1: CMD0, argument 0x [ 31.288330] omap_hsmmc omap_hsmmc.1: IRQ Status is 1 [ 31.288360] mmc1: req done (CMD0): 0: [ 31.289398] mmc1: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0 timing 0 [ 31.289428] omap_hsmmc omap_hsmmc.1: Set clock to 40Hz [ 31.290466] mmc1: starting CMD8 arg 01aa flags 02f5 [ 31.290466] omap_hsmmc omap_hsmmc.1: mmc1: CMD8, argument 0x01aa [ 31.290832] omap_hsmmc omap_hsmmc.1: IRQ Status is 18000 [ 31.290863] omap_hsmmc omap_hsmmc.1: MMC IRQ 0x18000 : ERRI CTO [ 31.290893] mmc1: req done (CMD8): -110: [ 31.290924] mmc1: starting CMD5 arg flags 02e1 [ 31.290954] omap_hsmmc omap_hsmmc.1: mmc1: CMD5, argument 0x [ 31.291290] omap_hsmmc omap_hsmmc.1: IRQ Status is 18000 [ 31.291320] omap_hsmmc omap_hsmmc.1: MMC IRQ 0x18000 : ERRI CTO [ 31.291381] mmc1: req failed (CMD5): -110, retrying... [ 31.291412] omap_hsmmc omap_hsmmc.1: mmc1: CMD5, argument 0x [ 31.291748] omap_hsmmc omap_hsmmc.1: IRQ Status is 18000 [ 31.291778] omap_hsmmc omap_hsmmc.1: MMC IRQ 0x18000 : ERRI CTO [ 31.291839] mmc1: req failed (CMD5): -110, retrying... [ 31.291870] omap_hsmmc omap_hsmmc.1: mmc1: CMD5, argument 0x [ 31.292205] omap_hsmmc omap_hsmmc.1: IRQ Status is 18000 [ 31.292236] omap_hsmmc omap_hsmmc.1: MMC IRQ 0x18000 : ERRI CTO [ 31.292266] mmc1: req failed (CMD5): -110, retrying... [ 31.292297] omap_hsmmc omap_hsmmc.1: mmc1: CMD5, argument 0x [ 31.292633] omap_hsmmc omap_hsmmc.1: IRQ Status is 18000 [ 31.292663] omap_hsmmc omap_hsmmc.1: MMC IRQ 0x18000 : ERRI CTO [ 31.292694] mmc1: req done (CMD5): -110: [ 31.292877] libertas_sdio: probe of mmc1:0001:1 failed with error -16 [ 31.387481] omap_hsmmc omap_hsmmc.1: disabled Is this useful? It seems CMD5 fails (which seems to be what the workarounds were aiming to fix). I'm afraid I may not be of much more use as Gumstix (annoyingly) don't release schematics of their COMs, so actually probing any signals isn't really possible. Cheers, Joe -Original Message- From: Ohad Ben-Cohen To: Daniel Drake Cc: Joe Woodward , linux-mmc@vger.kernel.org, Chris Ball Date: Wed, 30 Nov 2011 16:29:21 +0200 Subject: Re: mmc: sdio: runtime PM and 8686 problems > On Wed, Nov 30, 201
Re: mmc: sdio: runtime PM and 8686 problems
Any more feedback on this? I don't mind having to maintain my own patch to revert the change to core/host.c to disable runtime PM, but I'm a bit concerned by the commit comment: "... Enable this trivially for a release or two. If no problems are reported, we will follow up with a more extensive patch to remove this flag altogether. If problems are reported, we can look at whitelist/blacklist possibilities as before." Certainly for my use case I'd appreciate keeping this flag around! Cheers, Joe -Original Message- From: Ohad Ben-Cohen To: Joe Woodward Cc: Daniel Drake , linux-mmc@vger.kernel.org Date: Fri, 18 Nov 2011 14:15:03 +0200 Subject: Re: mmc: sdio: runtime PM and 8686 problems > On Fri, Nov 18, 2011 at 12:00 PM, Joe Woodward > 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 wait for Daniel to take a look, as he got libertas and sd8686 > working with SDIO runtime PM. > -- > 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 -- 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
Re: mmc: sdio: runtime PM and 8686 problems
Ohad, I'm assuming these changes have already made it to the mainline, and therefore are in the 3.2rc2 build I was testing... If not do you have links to the patches? Is there anything I can do to debug further the problems I'm seeing? Cheers, Joe -Original Message- From: Ohad Ben-Cohen To: Joe Woodward , Daniel Drake Cc: linux-mmc@vger.kernel.org Date: Fri, 18 Nov 2011 11:06:44 +0200 Subject: Re: mmc: sdio: runtime PM and 8686 problems > Hi Joe, > > On Fri, Nov 18, 2011 at 10:53 AM, Joe Woodward > 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 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 -- 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
mmc: sdio: runtime PM and 8686 problems
(resending as my mailer seems to have decided that the first try was a reply to "RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device,"... apologies!) I have a GUMSTIX Overo (OMAP35xx) with a Marvel 8686 WiFi attached via SDIO (ok, I think it's actually a Wi2Wi W2CBW003 module containing an 8686). Up to the 3.1 mainline kernel WiFi worked just fine! I could boot the kernel and load the libertas module successfully: (during boot) [3.193176] mmc1: new SDIO card at address 0001 (when loading module) # modprobe libertas_sdio [ 30.817749] lib80211: common routines for IEEE802.11 drivers [ 31.143951] cfg80211: Calling CRDA to update world regulatory domain [ 31.375823] libertas_sdio: Libertas SDIO driver [ 31.380737] libertas_sdio: Copyright Pierre Ossman [ 32.035186] libertas_sdio mmc1:0001:1: (unregistered net_device): 00:19:88:3e:4f:f9, fw 9.70.3p36, cap 0x0303 [ 32.129943] libertas_sdio mmc1:0001:1: wlan0: Marvell WLAN 802.11 adapter However it seems that runtime PM has now been turned on by default (by setting MMC_CAP_POWER_OFF_CARD in drivers/mmc/core/host.c), and the WiFi has stopped working! So, if I run the 3.2-rc2 (or rc1 for that matter) I get the following: (during boot) [3.486541] mmc1: new SDIO card at address 0001 (when loading module) # modprobe libertas_sdio [ 34.015350] lib80211: common routines for IEEE802.11 drivers [ 34.345092] cfg80211: Calling CRDA to update world regulatory domain [ 34.574096] libertas_sdio: Libertas SDIO driver [ 34.578979] libertas_sdio: Copyright Pierre Ossman [ 34.637481] libertas_sdio: probe of mmc1:0001:1 failed with error -16 Looking at arch/arm/mach-omap2/overo.c you can see that GPIO16 (OVERO_GPIO_W2W_NRESET) is the nRESET line for the 8686. This is held low for 10usecs during boot (see overo.c line 530 to 533). I'm not 100% sure how power is connected to the SD8686 as GUMSTIX don't release schematics for their modules. If I disable runtime PM (by commenting out the setting of MMC_CAP_POWER_OFF_CARD) everything works as before. I can see plenty of threads relating to getting the SD8686 working for OLPC, and that some workarounds have made it in to the mainline kernel. From what I understand the problem is that runtime PM removes power from the 8686 after boot and before the loading of the libertas module. Are these workarounds expected to be enough for runtime PM to just "work"? Is there anything special I should be doing with the nRESET line other than that which is done by default in the board file (holding nRESET low for 10usecs)? Cheers, Joe -- 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
mmc: sdio: runtime PM and 8686 problems
I have a GUMSTIX Overo (OMAP35xx) with a Marvel 8686 WiFi attached via SDIO (ok, I think it's actually a Wi2Wi W2CBW003 module containing an 8686). Up to the 3.1 mainline kernel WiFi worked just fine! I could boot the kernel and load the libertas module successfully: (during boot) [3.193176] mmc1: new SDIO card at address 0001 (when loading module) # modprobe libertas_sdio [ 30.817749] lib80211: common routines for IEEE802.11 drivers [ 31.143951] cfg80211: Calling CRDA to update world regulatory domain [ 31.375823] libertas_sdio: Libertas SDIO driver [ 31.380737] libertas_sdio: Copyright Pierre Ossman [ 32.035186] libertas_sdio mmc1:0001:1: (unregistered net_device): 00:19:88:3e:4f:f9, fw 9.70.3p36, cap 0x0303 [ 32.129943] libertas_sdio mmc1:0001:1: wlan0: Marvell WLAN 802.11 adapter However it seems that runtime PM has now been turned on by default (by setting MMC_CAP_POWER_OFF_CARD in drivers/mmc/core/host.c), and the WiFi has stopped working! So, if I run the 3.2-rc2 (or rc1 for that matter) I get the following: (during boot) [3.486541] mmc1: new SDIO card at address 0001 (when loading module) # modprobe libertas_sdio [ 34.015350] lib80211: common routines for IEEE802.11 drivers [ 34.345092] cfg80211: Calling CRDA to update world regulatory domain [ 34.574096] libertas_sdio: Libertas SDIO driver [ 34.578979] libertas_sdio: Copyright Pierre Ossman [ 34.637481] libertas_sdio: probe of mmc1:0001:1 failed with error -16 Looking at arch/arm/mach-omap2/overo.c you can see that GPIO16 (OVERO_GPIO_W2W_NRESET) is the nRESET line for the 8686. This is held low for 10usecs during boot (see overo.c line 530 to 533). I'm not 100% sure how power is connected to the SD8686 as GUMSTIX don't release schematics for their modules. If I disable runtime PM (by commenting out the setting of MMC_CAP_POWER_OFF_CARD) everything works as before. I can see plenty of threads relating to getting the SD8686 working for OLPC, and that some workarounds have made it in to the mainline kernel. From what I understand the problem is that runtime PM removes power from the 8686 after boot and before the loading of the libertas module. Are these workarounds expected to be enough for runtime PM to just "work"? Is there anything special I should be doing with the nRESET line other than that which is done by default in the board file (holding nRESET low for 10usecs)? Cheers, Joe -- 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
