On Mon, Dec 19, 2011 at 1:10 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> 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 >> When SDIO runtime PM was originally introduced, we immediately faced >> two regressions with two different chipsets, and in response decided >> not to enable it by default. >> >> With your work on the 8686 we hoped we found all the gotchas, so >> 08da834 did make sense (at least experimentally). >> >> Unfortunately we now see that some setups out there still refuse to >> work when SDIO runtime PM is enabled by default, and obviously we >> can't live with these kind of regressions. >> >> commit fd9fec7a00f58a16803e37a99a014ef82543ef6f >> Author: Ohad Ben-Cohen <ohad@xxxxxxxxxx> >> 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 >> not to enable it by default. >> >> With the recent work on the 8686 we hoped we found all the gotchas, >> so 08da834 did make sense (at least experimentally). >> >> Unfortunately we now see that some setups out there still refuse to work >> when SDIO runtime PM is enabled by default (see >> http://www.spinics.net/lists/linux-mmc/msg11161.html), and obviously we >> can't live with these kind of regressions. >> >> This reverts commit 08da834a24312157f512224691ad1fddd11c1073. >> >> Signed-off-by: Ohad Ben-Cohen <ohad@xxxxxxxxxx> >> Cc: Daniel Drake <dsd@xxxxxxxxxx> >> >> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c >> index e8a5eb3..d31c78b 100644 >> --- a/drivers/mmc/core/host.c >> +++ b/drivers/mmc/core/host.c >> @@ -302,17 +302,6 @@ struct mmc_host *mmc_alloc_host(int extra, struct >> device *dev) >> host->max_blk_size = 512; >> host->max_blk_count = PAGE_CACHE_SIZE / 512; >> >> - /* >> - * Enable runtime power management by default. This flag was added due >> - * to runtime power management causing disruption for some users, but >> - * the power on/off code has been improved since then. >> - * >> - * We'll enable this flag by default as an experiment, and if no >> - * problems are reported, we will follow up later and remove the flag >> - * altogether. >> - */ >> - host->caps = MMC_CAP_POWER_OFF_CARD; >> - >> return host; >> >> free: > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
