Hi Chris, On Wed, Nov 30, 2011 at 4:29 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Wed, Nov 30, 2011 at 4:12 PM, Daniel Drake <dsd@xxxxxxxxxx> wrote: >> My patch simply sets a flag to enable a whole load of code written by >> you - code which I understand little about. I am now available to >> help, but given that my understanding of mmc is limited, I didn't >> write the code in question, and I also lack expert insight into 8686 >> powerup, I'm not sure how useful I can be. > > Let's revert 08da834 then. 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. Thanks, Ohad. > > 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
