linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Daniel Drake <dsd@laptop.org>,
	linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
Subject: Re: MMC runtime PM patches break libertas probe
Date: Tue, 16 Nov 2010 18:17:09 +0100	[thread overview]
Message-ID: <4CE2BC95.5030605@nets.rwth-aachen.de> (raw)
In-Reply-To: <AANLkTinzvte389GNHtD2N0wO9mYsysCG9+Z1AFVZRn0E@mail.gmail.com>

Am 16.11.2010 14:22, schrieb Ohad Ben-Cohen:
> On Mon, Nov 1, 2010 at 10:27 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>   
>> On Sun, Oct 31, 2010 at 9:06 PM, Ohad Ben-Cohen <ohad@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 trivially fix the problem - can you
>> please check it out ?
>>
>> It's very simple: it just requires hosts to explicitly indicate they
>> support runtime powering off/on their cards (by means of
>> MMC_CAP_RUNTIME_PM).
>>
>> There is no way around this I'm afraid: it is legitimate for a
>> board/host/card configuration not to support powering off the card
>> after boot, and we must allow it.
>>
>> In addition having an explicit MMC_CAP_RUNTIME_PM will also allow us
>> smoother transition to runtime PM behavior. Developers will have to
>> explicitly turn it on, and will not be surprised if things won't
>> immediately work.
>>
>> Please note that this cap is not interchangeable, and can't be replace
>> with CONFIG_PM_RUNTIME.
>>
>> Having said that, I still think we need to understand why CMD3 timed
>> out on the XO-1.5.
>>     
> 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 by an out-of-tree kernel patch:
>
> http://dev.laptop.org/git/olpc-2.6/commit/?h=olpc-2.6.35&id=e9bee721fb0cc303286d1fe5df4930ce79b0b1e0
>
> ... which makes me wonder whether we really want to take that
> MMC_CAP_RUNTIME_PM road. I'm not sure anymore.
>
> We need a demonstrated hardware limitation before we take that
> approach (or a setup which worked using vanilla kernels and now
> doesn't), because frankly this MMC_CAP_RUNTIME_PM approach is
> cumbersome and involving. I would not like to introduce it just to fix
> out-of-tree software issues, and it seems that at least the XO-1.5
> case can be cleanly solved by software (e.g. by letting the regulator
> handle that sd8686 quirk).
>
> I'm looping in Arnd, who reported similar problems with b43-sdio on
> AP4EVB (arm) with tmio_mmc.
>
> Arnd,
>
> We're trying to exactly understand the reasons behind the reported
> SDIO runtime pm failures (we had two, yours, and OLPC). So far it
> seems that the OLPC had a software issue, and I'm wondering about
> yours.
>
> Can you please supply additional information about your board ? where
> does your wifi card gets its power from ? is there an external gpio
> involved ? Were you able to work with vanilla kernels (prior to
> 2.6.37) or do you carry some out-of-tree patches ?
>   
Its an AP4 (SH7372) evaluation board from renesas. It has an SD-Slot,
where you plug the SDIO card into it. No special wiring or something
like this. So I doubt some external GPIOs are involved.
I have no idea how the wifi card gets its power, but I hope its over
some well defined pins within the SD slot...
I was able to work with 2.6.35 and .36 plus some out-of-tree patches
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 <ohad@wizery.com>
>> Date: Mon, 1 Nov 2010 09:41:44 +0200
>> Subject: [PATCH] mmc: add MMC_CAP_RUNTIME_PM
>>
>> Some board/card/host configurations are not capable of powering off/on
>> on the card during runtime.
>>
>> To support such configurations, and to allow smoother transition to
>> runtime PM behavior, MMC_CAP_RUNTIME_PM is added, so hosts need to
>> explicitly indicate that it's OK to power off their cards after boot.
>>
>> This will prevent sdio_bus_probe() from failing to power on the card
>> when the driver is loaded on such setups.
>>
>> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
>> ---
>>  drivers/mmc/core/sdio.c     |   37 +++++++++++++++++++++++--------------
>>  drivers/mmc/core/sdio_bus.c |   33 ++++++++++++++++++++++-----------
>>  include/linux/mmc/host.h    |    1 +
>>  3 files changed, 46 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>> index 6a9ad40..373d56d 100644
>> --- a/drivers/mmc/core/sdio.c
>> +++ b/drivers/mmc/core/sdio.c
>> @@ -547,9 +547,11 @@ static void mmc_sdio_detect(struct mmc_host *host)
>>        BUG_ON(!host->card);
>>
>>        /* Make sure card is powered before detecting it */
>> -       err = pm_runtime_get_sync(&host->card->dev);
>> -       if (err < 0)
>> -               goto out;
>> +       if (host->caps & MMC_CAP_RUNTIME_PM) {
>> +               err = pm_runtime_get_sync(&host->card->dev);
>> +               if (err < 0)
>> +                       goto out;
>> +       }
>>
>>        mmc_claim_host(host);
>>
>> @@ -570,7 +572,8 @@ out:
>>        }
>>
>>        /* Tell PM core that we're done */
>> -       pm_runtime_put(&host->card->dev);
>> +       if (host->caps & MMC_CAP_RUNTIME_PM)
>> +               pm_runtime_put(&host->card->dev);
>>  }
>>
>>  /*
>> @@ -720,16 +723,21 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
>>        card = host->card;
>>
>>        /*
>> -        * Let runtime PM core know our card is active
>> +        * Enable runtime PM only if supported by host+card+board
>>         */
>> -       err = pm_runtime_set_active(&card->dev);
>> -       if (err)
>> -               goto remove;
>> +       if (host->caps & MMC_CAP_RUNTIME_PM) {
>> +               /*
>> +                * Let runtime PM core know our card is active
>> +                */
>> +               err = pm_runtime_set_active(&card->dev);
>> +               if (err)
>> +                       goto remove;
>>
>> -       /*
>> -        * Enable runtime PM for this card
>> -        */
>> -       pm_runtime_enable(&card->dev);
>> +               /*
>> +                * Enable runtime PM for this card
>> +                */
>> +               pm_runtime_enable(&card->dev);
>> +       }
>>
>>        /*
>>         * The number of functions on the card is encoded inside
>> @@ -747,9 +755,10 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
>>                        goto remove;
>>
>>                /*
>> -                * Enable Runtime PM for this func
>> +                * Enable Runtime PM for this func (if supported)
>>                 */
>> -               pm_runtime_enable(&card->sdio_func[i]->dev);
>> +               if (host->caps & MMC_CAP_RUNTIME_PM)
>> +                       pm_runtime_enable(&card->sdio_func[i]->dev);
>>        }
>>
>>        mmc_release_host(host);
>> diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
>> index 2716c7a..f3ce21b 100644
>> --- a/drivers/mmc/core/sdio_bus.c
>> +++ b/drivers/mmc/core/sdio_bus.c
>> @@ -17,6 +17,7 @@
>>  #include <linux/pm_runtime.h>
>>
>>  #include <linux/mmc/card.h>
>> +#include <linux/mmc/host.h>
>>  #include <linux/mmc/sdio_func.h>
>>
>>  #include "sdio_cis.h"
>> @@ -132,9 +133,11 @@ static int sdio_bus_probe(struct device *dev)
>>         * it should call pm_runtime_put_noidle() in its probe routine and
>>         * pm_runtime_get_noresume() in its remove routine.
>>         */
>> -       ret = pm_runtime_get_sync(dev);
>> -       if (ret < 0)
>> -               goto out;
>> +       if (func->card->host->caps & MMC_CAP_RUNTIME_PM) {
>> +               ret = pm_runtime_get_sync(dev);
>> +               if (ret < 0)
>> +                       goto out;
>> +       }
>>
>>        /* Set the default block size so the driver is sure it's something
>>         * sensible. */
>> @@ -151,7 +154,8 @@ static int sdio_bus_probe(struct device *dev)
>>        return 0;
>>
>>  disable_runtimepm:
>> -       pm_runtime_put_noidle(dev);
>> +       if (func->card->host->caps & MMC_CAP_RUNTIME_PM)
>> +               pm_runtime_put_noidle(dev);
>>  out:
>>        return ret;
>>  }
>> @@ -160,12 +164,14 @@ static int sdio_bus_remove(struct device *dev)
>>  {
>>        struct sdio_driver *drv = to_sdio_driver(dev->driver);
>>        struct sdio_func *func = dev_to_sdio_func(dev);
>> -       int ret;
>> +       int ret = 0;
>>
>>        /* Make sure card is powered before invoking ->remove() */
>> -       ret = pm_runtime_get_sync(dev);
>> -       if (ret < 0)
>> -               goto out;
>> +       if (func->card->host->caps & MMC_CAP_RUNTIME_PM) {
>> +               ret = pm_runtime_get_sync(dev);
>> +               if (ret < 0)
>> +                       goto out;
>> +       }
>>
>>        drv->remove(func);
>>
>> @@ -178,10 +184,12 @@ static int sdio_bus_remove(struct device *dev)
>>        }
>>
>>        /* First, undo the increment made directly above */
>> -       pm_runtime_put_noidle(dev);
>> +       if (func->card->host->caps & MMC_CAP_RUNTIME_PM)
>> +               pm_runtime_put_noidle(dev);
>>
>>        /* Then undo the runtime PM settings in sdio_bus_probe() */
>> -       pm_runtime_put_noidle(dev);
>> +       if (func->card->host->caps & MMC_CAP_RUNTIME_PM)
>> +               pm_runtime_put_noidle(dev);
>>
>>  out:
>>        return ret;
>> @@ -191,6 +199,8 @@ out:
>>
>>  static int sdio_bus_pm_prepare(struct device *dev)
>>  {
>> +       struct sdio_func *func = dev_to_sdio_func(dev);
>> +
>>        /*
>>         * Resume an SDIO device which was suspended at run time at this
>>         * point, in order to allow standard SDIO suspend/resume paths
>> @@ -212,7 +222,8 @@ static int sdio_bus_pm_prepare(struct device *dev)
>>         * since there is little point in failing system suspend if a
>>         * device can't be resumed.
>>         */
>> -       pm_runtime_resume(dev);
>> +       if (func->card->host->caps & MMC_CAP_RUNTIME_PM)
>> +               pm_runtime_resume(dev);
>>
>>        return 0;
>>  }
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index c3ffad8..e5eee0e 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -167,6 +167,7 @@ struct mmc_host {
>>                                                /* DDR mode at 1.8V */
>>  #define MMC_CAP_1_2V_DDR       (1 << 12)       /* can support */
>>                                                /* DDR mode at 1.2V */
>> +#define MMC_CAP_RUNTIME_PM     (1 << 13)       /* Can power off/on in runtime */
>>
>>        mmc_pm_flag_t           pm_caps;        /* supported pm features */
>>
>> --
>> 1.7.0.4
>>
>>     


  parent reply	other threads:[~2010-11-16 17:17 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-31 14:29 MMC runtime PM patches break libertas probe Daniel Drake
2010-10-31 14:42 ` Ohad Ben-Cohen
2010-10-31 14:55   ` Daniel Drake
2010-10-31 15:08     ` Ohad Ben-Cohen
2010-10-31 15:10       ` Daniel Drake
2010-10-31 15:16         ` Ohad Ben-Cohen
2010-10-31 15:21           ` Daniel Drake
2010-10-31 15:21           ` Daniel Drake
2010-10-31 15:27             ` Ohad Ben-Cohen
2010-10-31 15:57               ` Daniel Drake
2010-10-31 16:16                 ` Ohad Ben-Cohen
2010-10-31 16:24                   ` Daniel Drake
2010-10-31 19:06                     ` Ohad Ben-Cohen
2010-11-01  8:27                       ` Ohad Ben-Cohen
2010-11-06 21:19                         ` Daniel Drake
2010-11-07  1:48                           ` Nicolas Pitre
2010-11-07 10:19                             ` Daniel Drake
2010-11-07 15:12                               ` Nicolas Pitre
2010-11-07 10:42                           ` Ohad Ben-Cohen
2010-11-07 10:51                             ` Daniel Drake
2010-11-07 13:17                               ` Ohad Ben-Cohen
2010-11-16 13:22                         ` Ohad Ben-Cohen
2010-11-16 14:29                           ` Daniel Drake
2010-11-16 14:49                             ` Ohad Ben-Cohen
2010-11-17  6:46                               ` Mike Rapoport
2010-11-17  7:29                                 ` Ohad Ben-Cohen
2010-11-17 14:54                                   ` Nicolas Pitre
2010-11-16 17:17                           ` Arnd Hannemann [this message]
2010-11-16 20:58                             ` Ohad Ben-Cohen
2010-11-16 21:16                               ` Arnd Hannemann
2010-11-16 22:26                                 ` Ohad Ben-Cohen
2011-05-29 16:21                       ` Daniel Drake
2011-05-30  6:52                         ` Ohad Ben-Cohen
2011-05-30  7:01                           ` Daniel Drake
2011-05-30  7:32                             ` Ohad Ben-Cohen
2011-05-30 11:04                               ` zhangfei gao
2011-05-30 11:16                                 ` Ohad Ben-Cohen
2011-06-02  8:39                                   ` Bing Zhao
2011-06-02 18:25                                     ` Ohad Ben-Cohen
2011-06-03 22:28                                       ` Bing Zhao
2011-06-03 22:52                                         ` Ohad Ben-Cohen
2011-06-07 14:34                                           ` Arnd Hannemann
2011-06-07 14:45                                             ` Ohad Ben-Cohen
2011-06-08 14:34                                           ` Ohad Ben-Cohen
2011-06-10  2:02                                             ` zhangfei gao
2011-06-10  4:28                                               ` Ohad Ben-Cohen
2011-06-11  2:33                                                 ` zhangfei gao
2011-06-11  9:03                                                   ` Ohad Ben-Cohen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CE2BC95.5030605@nets.rwth-aachen.de \
    --to=hannemann@nets.rwth-aachen.de \
    --cc=cjb@laptop.org \
    --cc=dsd@laptop.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ohad@wizery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).