All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Elbs <alex@segv.de>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Nicolas Pitre <nico@fluxnic.net>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	bonbons@linux-vserver.org, Jason Cooper <jason@lakedaemon.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Gregory CLEMENT <gregory.clement@free-electrons.com>
Subject: Re: mvsdio: unhandled interrupt, mmc writes queuing up
Date: Wed, 26 Mar 2014 21:06:21 +0100	[thread overview]
Message-ID: <20140326200621.GL29769@segv.de> (raw)
In-Reply-To: <53320055.9080307@gmail.com>

On Tue, Mar 25, 2014 at 11:16:53PM +0100, Sebastian Hesselbarth wrote:
> > $ git bisect view --oneline
> > 2326f04 (refs/bisect/bad) ARM: kirkwood: convert to DT irqchip and clocksource
> 
> Can you please try the patches contained in [1]?
> 
> They have been Acked-by Jason Cooper, but I guess we simply lost
> track of them.
> 
> Sebastian
> 
> [1] https://lkml.org/lkml/2013/11/15/276
> 

Hello Sebastian,

I tested the patch series from [1] on top of 3.14-rc8. Works fine: no more
unhandled interrupt messages.

Tested-by: Alexander Elbs <alex@segv.de>

Regards,
Alexander

diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index 8e41be6..a6ab87c 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -42,7 +42,7 @@ __exception_irq_entry orion_handle_irq(struct pt_regs *regs)
                u32 stat = readl_relaxed(gc->reg_base + ORION_IRQ_CAUSE) &
                        gc->mask_cache;
                while (stat) {
-                       u32 hwirq = ffs(stat) - 1;
+                       u32 hwirq = __fls(stat);
                        u32 irq = irq_find_mapping(orion_irq_domain,
                                                   gc->irq_base + hwirq);
                        handle_IRQ(irq, regs);
@@ -117,7 +117,7 @@ static void orion_bridge_irq_handler(unsigned int irq,
struct irq_desc *desc)
                   gc->mask_cache;
 
        while (stat) {
-               u32 hwirq = ffs(stat) - 1;
+               u32 hwirq = __fls(stat);
 
                generic_handle_irq(irq_find_mapping(d, gc->irq_base + hwirq));
                stat &= ~(1 << hwirq);
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 45aa220..5eceec4 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -354,6 +354,21 @@ static irqreturn_t mvsd_irq(int irq, void *dev)
                intr_status, mvsd_read(MVSD_NOR_INTR_EN),
                mvsd_read(MVSD_HW_STATE));
 
+       /*
+        * It looks like, SDIO IP can issue one late, spurious irq
+        * although all irqs should be disabled. To work around this,
+        * bail out early, if we didn't expect any irqs to occur.
+        */
+       if (!mvsd_read(MVSD_NOR_INTR_EN) && !mvsd_read(MVSD_ERR_INTR_EN)) {
+               dev_dbg(host->dev,
+                       "spurious irq detected intr 0x%04x intr_en 0x%04x erri
0x%04x erri_en 0x%04x\n",
+                       mvsd_read(MVSD_NOR_INTR_STATUS),
+                       mvsd_read(MVSD_NOR_INTR_EN),
+                       mvsd_read(MVSD_ERR_INTR_STATUS),
+                       mvsd_read(MVSD_ERR_INTR_EN));
+               return IRQ_HANDLED;
+       }
+
        spin_lock(&host->lock);
 
        /* PIO handling, if needed. Messy business... */
@@ -801,10 +816,9 @@ static int mvsd_probe(struct platform_device *pdev)
                goto out;
 
        if (!(mmc->caps & MMC_CAP_NEEDS_POLL))
-               dev_notice(&pdev->dev, "using GPIO for card detection\n");
+               dev_dbg(&pdev->dev, "using GPIO for card detection\n");
        else
-               dev_notice(&pdev->dev,
-                          "lacking card detect (fall back to polling)\n");
+               dev_dbg(&pdev->dev, "lacking card detect, fall back to
polling\n");
        return 0;
 
 out:


      parent reply	other threads:[~2014-03-26 20:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 15:28 mvsdio: unhandled interrupt, mmc writes queuing up Bruno Prémont
2014-03-19 16:37 ` Nicolas Pitre
2014-03-25 19:27   ` Alexander Elbs
2014-03-25 22:16     ` Sebastian Hesselbarth
2014-03-26  0:07       ` Jason Cooper
2014-03-26  6:50         ` Bruno Prémont
2014-03-26 20:46         ` Bruno Prémont
2014-03-26 20:06       ` Alexander Elbs [this message]

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=20140326200621.GL29769@segv.de \
    --to=alex@segv.de \
    --cc=andrew@lunn.ch \
    --cc=bonbons@linux-vserver.org \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=nico@fluxnic.net \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=thomas.petazzoni@free-electrons.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 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.