| Message ID | 1307702572-22066-2-git-send-email-shawn.guo@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jun 10, 2011 at 06:42:49PM +0800, Shawn Guo wrote: > The issue was initially found by Eric Benard as below. > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/108031 > > Not sure about other SDHCI based controller, but on Freescale eSDHC, > the SDHCI_INT_CARD_INSERT bits will be immediately set again when it > gets cleared, if a card is inserted. The driver need to mask the irq > to prevent interrupt storm which will freeze the system. And the > SDHCI_INT_CARD_REMOVE gets the same situation. > > The patch fixes the problem based on the initial idea from > Eric Benard. > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > Cc: Eric Benard <eric@eukrea.com> Hmm, that should get enough testing on non-imx (and even non-ARM) devices. And a comment describing the situation.
On Tue, Jun 14, 2011 at 11:24:10AM +0200, Wolfram Sang wrote: > On Fri, Jun 10, 2011 at 06:42:49PM +0800, Shawn Guo wrote: > > The issue was initially found by Eric Benard as below. > > > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/108031 > > > > Not sure about other SDHCI based controller, but on Freescale eSDHC, > > the SDHCI_INT_CARD_INSERT bits will be immediately set again when it > > gets cleared, if a card is inserted. The driver need to mask the irq > > to prevent interrupt storm which will freeze the system. And the > > SDHCI_INT_CARD_REMOVE gets the same situation. > > > > The patch fixes the problem based on the initial idea from > > Eric Benard. > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > Cc: Eric Benard <eric@eukrea.com> > > Hmm, that should get enough testing on non-imx (and even non-ARM) > devices. And a comment describing the situation. > Agreed. Will add something in commit message to mention the situation. That's why I hope we can get the patch on mmc-next at early stage of the cycle, so everyone can start testing it and report problems, if any.
> > > The issue was initially found by Eric Benard as below. > > > > > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/108031 > > > > > > Not sure about other SDHCI based controller, but on Freescale eSDHC, > > > the SDHCI_INT_CARD_INSERT bits will be immediately set again when it > > > gets cleared, if a card is inserted. The driver need to mask the irq > > > to prevent interrupt storm which will freeze the system. And the > > > SDHCI_INT_CARD_REMOVE gets the same situation. > > > > > > The patch fixes the problem based on the initial idea from > > > Eric Benard. > > > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > > Cc: Eric Benard <eric@eukrea.com> > > > > Hmm, that should get enough testing on non-imx (and even non-ARM) > > devices. And a comment describing the situation. > > > Agreed. Will add something in commit message to mention the > situation. That's why I hope we can get the patch on mmc-next at I actually meant a comment in the code, so it will be obvious for later hackers why the "extra" steps are in there...
On Tue, Jun 14, 2011 at 02:02:58PM +0200, Wolfram Sang wrote: > > > > > The issue was initially found by Eric Benard as below. > > > > > > > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/108031 > > > > > > > > Not sure about other SDHCI based controller, but on Freescale eSDHC, > > > > the SDHCI_INT_CARD_INSERT bits will be immediately set again when it > > > > gets cleared, if a card is inserted. The driver need to mask the irq > > > > to prevent interrupt storm which will freeze the system. And the > > > > SDHCI_INT_CARD_REMOVE gets the same situation. > > > > > > > > The patch fixes the problem based on the initial idea from > > > > Eric Benard. > > > > > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > > > Cc: Eric Benard <eric@eukrea.com> > > > > > > Hmm, that should get enough testing on non-imx (and even non-ARM) > > > devices. And a comment describing the situation. > > > > > Agreed. Will add something in commit message to mention the > > situation. That's why I hope we can get the patch on mmc-next at > > I actually meant a comment in the code, so it will be obvious for later > hackers why the "extra" steps are in there... > OK.
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 91d9892..71a2505 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2154,13 +2154,20 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id) mmc_hostname(host->mmc), intmask); if (intmask & (SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE)) { + u32 present = sdhci_readl(host, SDHCI_PRESENT_STATE) & + SDHCI_CARD_PRESENT; + + sdhci_mask_irqs(host, present ? SDHCI_INT_CARD_INSERT : + SDHCI_INT_CARD_REMOVE); + sdhci_unmask_irqs(host, present ? SDHCI_INT_CARD_REMOVE : + SDHCI_INT_CARD_INSERT); + sdhci_writel(host, intmask & (SDHCI_INT_CARD_INSERT | - SDHCI_INT_CARD_REMOVE), SDHCI_INT_STATUS); + SDHCI_INT_CARD_REMOVE), SDHCI_INT_STATUS); + intmask &= ~(SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE); tasklet_schedule(&host->card_tasklet); } - intmask &= ~(SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE); - if (intmask & SDHCI_INT_CMD_MASK) { sdhci_writel(host, intmask & SDHCI_INT_CMD_MASK, SDHCI_INT_STATUS);
The issue was initially found by Eric Benard as below. http://permalink.gmane.org/gmane.linux.ports.arm.kernel/108031 Not sure about other SDHCI based controller, but on Freescale eSDHC, the SDHCI_INT_CARD_INSERT bits will be immediately set again when it gets cleared, if a card is inserted. The driver need to mask the irq to prevent interrupt storm which will freeze the system. And the SDHCI_INT_CARD_REMOVE gets the same situation. The patch fixes the problem based on the initial idea from Eric Benard. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: Eric Benard <eric@eukrea.com> --- drivers/mmc/host/sdhci.c | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-)