[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00d901ccfd0a$3c268740$b47395c0$@lge.com>
Date: Thu, 8 Mar 2012 18:02:48 +0900
From: "Kim, Jong-Sung" <neidhard.kim@....com>
To: "'Chanho Min'" <chanho0207@...il.com>,
"'Russell King'" <linux@....linux.org.uk>,
"'Alan Cox'" <alan@...ux.intel.com>,
"'Greg Kroah-Hartman'" <gregkh@...uxfoundation.org>,
"'Linus Walleij'" <linus.walleij@...aro.org>,
"'Shreshtha Kumar Sahu'" <shreshthakumar.sahu@...ricsson.com>
Cc: <linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>
Subject: RE: [PATCH] Clear previous interrupts after fifo is disabled
> -----Original Message-----
> From: Chanho Min [mailto:chanho0207@...il.com]
> Sent: Monday, February 27, 2012 6:30 PM
> To: Russell King; Alan Cox; Greg Kroah-Hartman; Linus Walleij; Shreshtha
> Kumar Sahu; Kim, Jong-Sung
> Cc: linux-kernel@...r.kernel.org; linux-serial@...r.kernel.org
> Subject: [PATCH] Clear previous interrupts after fifo is disabled
>
> This is another workaroud of 'https://lkml.org/lkml/2012/1/17/104'
> with additional analysis.Bootloader can transfer control to kernel and
there
> are some pending interrupts. In this case, RXFE of the flag register is
set
> by clearing FEN(LCRH) even if rx data remains in the fifo. It seems that
the
> fifo's status is initiailized. Interrupt handler can not get any data from
> data register because of the below break condtion.
>
> pl011_fifo_to_tty
> while (max_count--) {
> if (status & UART01x_FR_RXFE)
> break;
>
> Then, Rx interrupt is never cleared. cpu is looping in ISR. System is
hang.
> If we don't guarantee that no interrupt is pended until fifo is disabled
by
> calling 'writew(0, uap->port.membase + uap->lcrh_rx)', this misbehave of
the
> interrupt handelr can be occurred. So, All pending interrupts should be
> cleared just after fifo is disabled under the protection from interrupt.
> Also,'clear error interrupts' routine can be removed becuase all
interrupts
> are cleared before.
>
> Signed-off-by: Chanho Min <chanho.min@....com>
May I suggest another approach at this point? The problematic condition you
reported could be considered as an exceptional Rx interrupt status. So, we
can handle it in the Rx ISR. Simply:
diff --git a/drivers/tty/serial/amba-pl011.c
b/drivers/tty/serial/amba-pl011.c
index 6800f5f..5b5358705 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -224,6 +224,10 @@ static int pl011_fifo_to_tty(struct uart_amba_port
*uap)
uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
}
+ /* RXIS but RXFE? Just clear the interrupt */
+ if(unlikely(fifotaken == 0))
+ writew(UART011_RXIS, uap->port.membase + UART01x_ICR);
+
return fifotaken;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists