On Mon, 05 Mar 2007 10:19:55 -0500 Mark Lord <[EMAIL PROTECTED]> wrote:
> The interrupt is shared with another device, which resumes
> earlier than the sdhci controller, and generates an interrupt.
>
> The sdhci interrupt handler runs, sees 0xffffffff in its own
> device's interrupt status, and tries to handle it..
> The reason for the 0xffffffff is that the device is still
> suspended, and *all* regs are reading back 0xffffffff.
>
> So.. the suspend routine should de-register the irq handler,
> and the resume routine should re-register it again.
>
> Or perhaps a simpler kludge like this one, which fixes it for me:
>
> Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
> ---
> --- linux/drivers/mmc/sdhci.c.orig 2007-03-02 15:06:31.000000000 -0500
> +++ linux/drivers/mmc/sdhci.c 2007-03-05 10:13:51.000000000 -0500
> @@ -994,7 +994,7 @@
>
> intmask = readl(host->ioaddr + SDHCI_INT_STATUS);
>
> - if (!intmask) {
> + if (!intmask || intmask == 0xffffffff) {
> result = IRQ_NONE;
> goto out;
> }
This is actually pretty standard handling for a lot of drivers: any
device which can appear on a cardbus or other hot-unpluggable bus and which
shares interupts needs such treatment.
I don't know whether anything which this driver drives could ever appear on
such a bus, but I'm inclined to just apply it into 2.6.21.
(I'm also inclined to drop the darned mmc tree - am getting rather tired of
people moving their files all over the tree all the time).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
