All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@google.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Brian Norris <briannorris@chromium.org>,
	Shawn Lin <shawn.lin@rock-chips.com>
Subject: Re: [PATCH 2/3] mmc: dw_mmc: Convert to use MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs
Date: Tue, 18 Apr 2017 14:25:52 -0700	[thread overview]
Message-ID: <CAD=FV=UDirBw=mDhw1Px60mUN68zhFYqV08mr5Gs2ZMsLC8j6w@mail.gmail.com> (raw)
In-Reply-To: <1492518724-30511-3-git-send-email-ulf.hansson@linaro.org>

Hi,

On Tue, Apr 18, 2017 at 5:32 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Convert to use the more lightweight method for processing SDIO IRQs, which
> involves the following changes:
>
> - Enable MMC_CAP2_SDIO_IRQ_NOTHREAD when SDIO IRQ is supported.
> - Mask SDIO IRQ when signaling it for processing.
> - Re-enable (unmask) the SDIO IRQ from the ->ack_sdio_irq() callback.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>  drivers/mmc/host/dw_mmc.c | 29 ++++++++++++++++++++++++++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 249ded6..f086791 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1635,9 +1635,8 @@ static void dw_mci_init_card(struct mmc_host *mmc, struct mmc_card *card)
>         }
>  }
>
> -static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
> +static void __dw_mci_enable_sdio_irq(struct dw_mci_slot *slot, int enb)
>  {
> -       struct dw_mci_slot *slot = mmc_priv(mmc);
>         struct dw_mci *host = slot->host;
>         unsigned long irqflags;
>         u32 int_mask;
> @@ -1655,6 +1654,20 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
>         spin_unlock_irqrestore(&host->irq_lock, irqflags);
>  }
>
> +static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
> +{
> +       struct dw_mci_slot *slot = mmc_priv(mmc);
> +
> +       __dw_mci_enable_sdio_irq(slot, enb);
> +}
> +
> +static void dw_mci_ack_sdio_irq(struct mmc_host *mmc)
> +{
> +       struct dw_mci_slot *slot = mmc_priv(mmc);
> +
> +       __dw_mci_enable_sdio_irq(slot, 1);

I have some slight paranoia that some code out there might decide to
call enable_sdio_irq(0) while an interrupt is being processed.  In
that case we'll be turning interrupts back on here.  It seems like it
would be "better safe than sorry" to keep track of the "enabled /
disabled" state somewhere.  ...and when we "unmask" we treat it as a
no-op if the interrupt is currently disabled.

> +}
> +
>  static int dw_mci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>  {
>         struct dw_mci_slot *slot = mmc_priv(mmc);
> @@ -1756,6 +1769,7 @@ static const struct mmc_host_ops dw_mci_ops = {
>         .get_cd                 = dw_mci_get_cd,
>         .hw_reset               = dw_mci_hw_reset,
>         .enable_sdio_irq        = dw_mci_enable_sdio_irq,
> +       .ack_sdio_irq           = dw_mci_ack_sdio_irq,
>         .execute_tuning         = dw_mci_execute_tuning,
>         .card_busy              = dw_mci_card_busy,
>         .start_signal_voltage_switch = dw_mci_switch_voltage,
> @@ -2645,9 +2659,14 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
>                                 continue;
>
>                         if (pending & SDMMC_INT_SDIO(slot->sdio_id)) {
> +                               u32 int_mask;
> +
>                                 mci_writel(host, RINTSTS,
>                                            SDMMC_INT_SDIO(slot->sdio_id));
> -                               mmc_signal_sdio_irq(slot->mmc);
> +                               int_mask = mci_readl(host, INTMASK);
> +                               int_mask &= ~SDMMC_INT_SDIO(slot->sdio_id);
> +                               mci_writel(host, INTMASK, int_mask);

Seems like you should be calling "__dw_mci_enable_sdio_irq(slot, 0)"
here.  Specifically the interrupt handler won't have the spinlock so
you're doing an unsafe read/modify/write here.  Yeah, the spinlock is
kinda silly in dw_mmc.  Really the whole interrupt handling needs to
be re-done to use a threaded IRQ instead of the current solution...

> +                               sdio_signal_irq(slot->mmc);
>                         }
>                 }
>
> @@ -2748,6 +2767,10 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
>         if (ret)
>                 goto err_host_allocated;
>
> +       /* Process SDIO IRQs through the sdio_irq_work. */
> +       if (mmc->caps & MMC_CAP_SDIO_IRQ)
> +               mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;
> +
>         /* Useful defaults if platform data is unset. */
>         if (host->use_dma == TRANS_MODE_IDMAC) {
>                 mmc->max_segs = host->ring_size;
> --
> 2.7.4
>

  reply	other threads:[~2017-04-18 21:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 12:32 [PATCH 0/3] mmc: Improve/fix support for SDIO IRQs Ulf Hansson
2017-04-18 12:32 ` [PATCH 1/3] mmc: sdio: Add API to manage SDIO IRQs from a workqueue Ulf Hansson
2017-04-18 21:43   ` Doug Anderson
2017-04-19 10:48     ` Ulf Hansson
2017-04-19 19:29       ` Doug Anderson
2017-04-20 12:14         ` Ulf Hansson
2017-04-28 20:31           ` Doug Anderson
2017-04-18 12:32 ` [PATCH 2/3] mmc: dw_mmc: Convert to use MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs Ulf Hansson
2017-04-18 21:25   ` Doug Anderson [this message]
2017-04-19 12:10     ` Ulf Hansson
2017-04-19 18:39       ` Doug Anderson
2017-04-18 12:32 ` [PATCH 3/3] mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs are enabled 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='CAD=FV=UDirBw=mDhw1Px60mUN68zhFYqV08mr5Gs2ZMsLC8j6w@mail.gmail.com' \
    --to=dianders@google.com \
    --cc=adrian.hunter@intel.com \
    --cc=briannorris@chromium.org \
    --cc=jh80.chung@samsung.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=shawn.lin@rock-chips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.