From: Adrian Hunter <adrian.hunter@intel.com>
To: Ludovic Desroches <ludovic.desroches@atmel.com>, ulf.hansson@linaro.org
Cc: linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-pm@vger.kernel.org, nicolas.ferre@atmel.com
Subject: Re: [PATCH] sdhci: wakeup from runtime PM
Date: Tue, 5 Apr 2016 15:40:33 +0300 [thread overview]
Message-ID: <5703B241.6030007@intel.com> (raw)
In-Reply-To: <1458921903-11133-1-git-send-email-ludovic.desroches@atmel.com>
On 25/03/16 18:05, Ludovic Desroches wrote:
> Hi,
>
> When not using the SDHCI controller, it is logical to save power by suspending
> it. The issue is that SDHCI assumes that the controller is completely disabled.
> It means the only way to wake up on a card event is to have a gpio for the card
> detection (so two pins for the same signal). A possible workaround is to use
> polling but the controller will be resumed/suspended between each attempts.
>
> We have already discussed a long time about this and it seems we don't agree.
> In my opinion, even if I can't disable all clocks, I should use runtime PM
> to save some power.
>
> I propose two patches, one which is a draft to try to solve it at sdhci level
> and one at sdhci-of-at91 level.
>
> Concerning the first one, I don't understand why we need to reject irqs if
> runtime_suspended is true.
The interrupt handler might be called because the interrupt is shared i.e.
the interrupt is for a different device. In that case the host controller
might be off and the registers inaccessible. In that case we cannot even
look at the interrupt register to determine if we were expecting the interrupt.
> Only SDHCI_INT_CARD_INT irq is enabled so why we
> should have other IRQs than this one?
In the case of SDIO Card interrupt, it is delivered via the host controller,
so we have to assume the registers are accessible if we are
runtime-suspended with the SDIO IRQ enabled.
>
> Since you were not in favour of allowing to wakeup on SDHCI_INT_CARD_INSERT or
> SDHCI_INT_CARD_REMOVE, I assume you won't take it so I
> solved my issue only by modifying my driver.
I don't mind allowing card detect interrupts while runtime suspended, but we
need a flag so that:
- runtime suspend leaves the insert/remove interrupts enabled
- irq handler knows it can access registers
- irq thread handler knows to runtime resume before doing anything else
But it seems like you need to persuade Ulf first.
next prev parent reply other threads:[~2016-04-05 12:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 16:05 [PATCH] sdhci: wakeup from runtime PM Ludovic Desroches
2016-03-25 16:05 ` [PATCH] DRAFT: shdci: allows custom wakeup irqs for " Ludovic Desroches
2016-03-25 16:46 ` kbuild test robot
2016-03-25 16:50 ` kbuild test robot
2016-03-25 17:12 ` kbuild test robot
2016-03-25 17:27 ` kbuild test robot
2016-03-25 16:05 ` [PATCH] mmc: sdhci-of-at91: allow the use of controller card detect as wake up Ludovic Desroches
2016-03-25 17:11 ` [PATCH] mmc: sdhci-of-at91: fix semicolon.cocci warnings kbuild test robot
2016-03-25 17:11 ` [PATCH] mmc: sdhci-of-at91: allow the use of controller card detect as wake up kbuild test robot
2016-04-05 12:40 ` Adrian Hunter [this message]
2016-04-07 9:11 ` [PATCH] sdhci: wakeup from runtime PM Ulf Hansson
2016-04-07 15:12 ` Ludovic Desroches
2016-04-08 8:35 ` Ulf Hansson
2016-04-08 15:19 ` Alan Stern
2016-04-08 20:51 ` Ulf Hansson
2016-04-11 12:09 ` 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=5703B241.6030007@intel.com \
--to=adrian.hunter@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=ludovic.desroches@atmel.com \
--cc=nicolas.ferre@atmel.com \
--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;
as well as URLs for NNTP newsgroup(s).