mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: linux-mmc@vger.kernel.org, Ulf Hansson <ulf.hansson@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Douglas Anderson <dianders@chromium.org>,
	Matthias Kaehlcke <mka@chromium.org>
Cc: Shawn Lin <shawn.lin@rock-chips.com>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Yong Mao <yong.mao@mediatek.com>,
	Chaotian Jing <chaotian.jing@mediatek.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 05/11] mmc: core: Clarify sdio_irq_pending flag for MMC_CAP2_SDIO_IRQ_NOTHREAD
Date: Sun,  8 Sep 2019 12:12:30 +0200	[thread overview]
Message-ID: <20190908101236.2802-6-ulf.hansson@linaro.org> (raw)
In-Reply-To: <20190908101236.2802-1-ulf.hansson@linaro.org>

The sdio_irq_pending flag is used to let host drivers indicate that it has
signaled an IRQ. If that is the case and we only have a single SDIO func
that have claimed an SDIO IRQ, our assumption is that we can avoid reading
the SDIO_CCCR_INTx register and just call the SDIO func irq handler
immediately. This makes sense, but the flag is set/cleared in a somewhat
messy order, let's fix that up according to below.

First, the flag is currently set in sdio_run_irqs(), which is executed as a
work that was scheduled from sdio_signal_irq(). To make it more implicit
that the host have signaled an IRQ, let's instead immediately set the flag
in sdio_signal_irq(). This also makes the behavior consistent with host
drivers that uses the legacy, mmc_signal_sdio_irq() API. This have no
functional impact, because we don't expect host drivers to call
sdio_signal_irq() until after the work (sdio_run_irqs()) have been executed
anyways.

Second, currently we never clears the flag when using the sdio_run_irqs()
work, but only when using the sdio_irq_thread(). Let make the behavior
consistent, by moving the flag to be cleared inside the common
process_sdio_pending_irqs() function. Additionally, tweak the behavior of
the flag slightly, by avoiding to clear it unless we processed the SDIO
IRQ. The purpose with this at this point, is to keep the information about
whether there have been an SDIO IRQ signaled by the host, so at system
resume we can decide to process it without reading the SDIO_CCCR_INTx
register.

Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---

Changes in v2:
	- Re-wrote changelog.

---
 drivers/mmc/core/sdio_irq.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index f75043266984..0962a4357d54 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -59,6 +59,7 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
 {
 	struct mmc_card *card = host->card;
 	int i, ret, count;
+	bool sdio_irq_pending = host->sdio_irq_pending;
 	unsigned char pending;
 	struct sdio_func *func;
 
@@ -66,13 +67,16 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
 	if (mmc_card_suspended(card))
 		return 0;
 
+	/* Clear the flag to indicate that we have processed the IRQ. */
+	host->sdio_irq_pending = false;
+
 	/*
 	 * Optimization, if there is only 1 function interrupt registered
 	 * and we know an IRQ was signaled then call irq handler directly.
 	 * Otherwise do the full probe.
 	 */
 	func = card->sdio_single_irq;
-	if (func && host->sdio_irq_pending) {
+	if (func && sdio_irq_pending) {
 		func->irq_handler(func);
 		return 1;
 	}
@@ -110,7 +114,6 @@ static void sdio_run_irqs(struct mmc_host *host)
 {
 	mmc_claim_host(host);
 	if (host->sdio_irqs) {
-		host->sdio_irq_pending = true;
 		process_sdio_pending_irqs(host);
 		if (host->ops->ack_sdio_irq)
 			host->ops->ack_sdio_irq(host);
@@ -128,6 +131,7 @@ void sdio_irq_work(struct work_struct *work)
 
 void sdio_signal_irq(struct mmc_host *host)
 {
+	host->sdio_irq_pending = true;
 	queue_delayed_work(system_wq, &host->sdio_irq_work, 0);
 }
 EXPORT_SYMBOL_GPL(sdio_signal_irq);
@@ -173,7 +177,6 @@ static int sdio_irq_thread(void *_host)
 		if (ret)
 			break;
 		ret = process_sdio_pending_irqs(host);
-		host->sdio_irq_pending = false;
 		mmc_release_host(host);
 
 		/*
-- 
2.17.1


  parent reply	other threads:[~2019-09-08 10:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-08 10:12 [PATCH v2 00/11] mmc: core: PM fixes/improvements for SDIO IRQs Ulf Hansson
2019-09-08 10:12 ` [PATCH v2 01/11] mmc: core: Add helper function to indicate if SDIO IRQs is enabled Ulf Hansson
2019-09-09 22:32   ` Doug Anderson
2019-09-08 10:12 ` [PATCH v2 02/11] mmc: dw_mmc: Re-store SDIO IRQs mask at system resume Ulf Hansson
2019-09-09 22:32   ` Doug Anderson
2019-09-08 10:12 ` [PATCH v2 03/11] mmc: mtk-sd: " Ulf Hansson
2019-09-09 22:29   ` Doug Anderson
2019-09-11 12:06     ` Ulf Hansson
2019-09-08 10:12 ` [PATCH v2 04/11] mmc: core: Move code to get pending SDIO IRQs to a function Ulf Hansson
2019-09-09 22:32   ` Doug Anderson
2019-09-08 10:12 ` Ulf Hansson [this message]
2019-09-09 22:33   ` [PATCH v2 05/11] mmc: core: Clarify sdio_irq_pending flag for MMC_CAP2_SDIO_IRQ_NOTHREAD Doug Anderson
2019-09-08 10:12 ` [PATCH v2 06/11] mmc: core: Clarify that the ->ack_sdio_irq() callback is mandatory Ulf Hansson
2019-09-09 22:34   ` Doug Anderson
2019-09-08 10:12 ` [PATCH v2 07/11] mmc: core: WARN if SDIO IRQs are enabled for non-powered card in suspend Ulf Hansson
2019-09-08 10:12 ` [PATCH v2 08/11] mmc: core: Fixup processing of SDIO IRQs during system suspend/resume Ulf Hansson
2019-09-09 22:34   ` Doug Anderson
2019-09-08 10:12 ` [PATCH v2 09/11] mmc: sdhci: Drop redundant check in sdhci_ack_sdio_irq() Ulf Hansson
2019-09-09 11:19   ` Adrian Hunter
2019-09-08 10:12 ` [PATCH v2 10/11] mmc: sdhci: Drop redundant code for SDIO IRQs Ulf Hansson
2019-09-08 10:12 ` [PATCH v2 11/11] mmc: sdhci: Convert to use sdio_irq_claimed() Ulf Hansson
2019-09-11 14:21 ` [PATCH v2 00/11] mmc: core: PM fixes/improvements for SDIO IRQs Ulf Hansson

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=20190908101236.2802-6-ulf.hansson@linaro.org \
    --to=ulf.hansson@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=chaotian.jing@mediatek.com \
    --cc=dianders@chromium.org \
    --cc=jh80.chung@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=yong.mao@mediatek.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

all inboxes | Powered by JetHome®