Linux MultiMedia Card development
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc <linux-mmc@vger.kernel.org>
Subject: Re: [PATCH 7/8] mmc: sdhci: Remove redundant runtime PM calls
Date: Tue, 5 Apr 2016 14:40:04 +0300	[thread overview]
Message-ID: <5703A414.8070005@intel.com> (raw)
In-Reply-To: <CAPDyKFpOdS2C9_NjqMxtWRK4-qGc1gjL6TtKVAyBqVEot=u3gg@mail.gmail.com>

On 01/04/16 12:46, Ulf Hansson wrote:
> On 1 April 2016 at 09:46, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 29/03/16 10:31, Ulf Hansson wrote:
>>> Commit 9250aea76bfc ("mmc: core: Enable runtime PM management of host
>>> devices"), made some calls to the runtime PM API from the driver
>>> redundant. Especially those which deals with runtime PM reference
>>> counting, so let's remove them.
>>>
>>> Moreover as SDHCI have its own wrapper functions for runtime PM these
>>> becomes superfluous, so let's remove them as well.
>>>
>>> Cc: Adrian Hunter <adrian.hunter@intel.com>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Looks good, but I have one comment below.
>>
> 
> [...]
> 
>>>
>>>  static void sdhci_enable_sdio_irq_nolock(struct sdhci_host *host, int enable)
>>> @@ -1668,7 +1646,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
>>>       struct sdhci_host *host = mmc_priv(mmc);
>>>       unsigned long flags;
>>>
>>> -     sdhci_runtime_pm_get(host);
>>> +     pm_runtime_get_sync(mmc_dev(mmc));
>>
>> Why can't this be moved into the core as well?  At the least, there should
>> be a comment here and explanation in the commit message.
> 
> That's indeed a very good question! :-)
> 
> SDHCI is a special case for how a host driver deals with SDIO IRQs as
> it's the only user of MMC_CAP2_SDIO_IRQ_NOTHREAD.
> 
> It means it has its own SDIO IRQ thread (threaded IRQ) which will
> invoke sdio_run_irqs() to consume a received SDIO IRQ. Other host
> drivers are using the mmc_signal_sdio_irq() API to deal with this,
> which behaves a bit different.
> 
> The sdio_run_irqs() API claims the host (mmc_claim|release_host())
> before it starts to consume the SDIO IRQ. This triggers the host to be
> runtime resumed before the host ops ->enable_sdio_irq() gets called.
> So, actually it means it *should* be safe to remove
> pm_runtime_get|put() in it's current form from within
> sdhci_enable_sdio_irq()...

Sorry for slow reply.

Yes it looks safe.  Please remove it.

> 
> Although, I wonder how SDHCI can allow to have SDIO IRQs enabled
> without *keeping* the host runtime resumed, because I fail to see that
> any wakeups are being configured when the host becomes runtime
> suspended. I may be missing something, but what do you think?

As you probably know, it was done by Russell King, for the sdhci_esdhc-imx
driver by the look of it.  The clocks are left on during runtime suspend iff
the SDIO IRQ is enabled, and IIRC it says the registers are accessible.  I
would not expect any wakeups would need to be configured because the system
is not asleep.  I don't know exactly what Russell was aiming for, but one
advantage is that the host controller will go to a lower power state (clocks
off) when the SDIO IRQ is not enabled.


  reply	other threads:[~2016-04-05 11:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29  7:31 [PATCH 1/8] mmc: atmel-mci: Remove redundant runtime PM calls Ulf Hansson
2016-03-29  7:31 ` [PATCH 2/8] mmc: mmci: " Ulf Hansson
2016-03-29  7:31 ` [PATCH 3/8] mmc: mediatek: " Ulf Hansson
2016-03-29  7:31 ` [PATCH 4/8] mmc: omap_hsmmc: " Ulf Hansson
2016-03-29  7:31 ` [PATCH 5/8] mmc: sdhci-acpi: " Ulf Hansson
2016-03-29  7:31 ` [PATCH 6/8] mmc: sdhci-pci: " Ulf Hansson
2016-03-29  7:31 ` [PATCH 7/8] mmc: sdhci: " Ulf Hansson
2016-04-01  7:46   ` Adrian Hunter
2016-04-01  9:46     ` Ulf Hansson
2016-04-05 11:40       ` Adrian Hunter [this message]
2016-04-05 14:38         ` Ulf Hansson
2016-03-29  7:31 ` [PATCH 8/8] mmc: tmio: " Ulf Hansson
2016-03-29 15:03 ` [PATCH 1/8] mmc: atmel-mci: " Ludovic Desroches

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=5703A414.8070005@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /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