All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chanho Min <chanho0207@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Alan Cox <alan@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>,
	"Kim, Jong-Sung" <neidhard.kim@lge.com>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH] Clear previous interrupts after fifo is disabled
Date: Wed, 29 Feb 2012 11:47:02 +0900	[thread overview]
Message-ID: <CAOAMb1CvjxGHSekURXAhw5DL2W2-3Smw3ZTWuAi2E-1UBxHEFg@mail.gmail.com> (raw)
In-Reply-To: <20120228102337.GF18045@n2100.arm.linux.org.uk>

> Which is why my patch explicitly clears the receive interrupt status
> before requesting the interrupt.  Have you read my patch?
This is the hang-up scenario with your patch.

pl011_startup(struct uart_port *port)
 	uap->port.uartclk = clk_get_rate(uap->clk);

	/* Clear pending error and receive interrupts */
	writew(UART011_OEIS | UART011_BEIS | UART011_PEIS | UART011_FEIS |
	       UART011_RTIS | UART011_RXIS, uap->port.membase + UART011_ICR);
...
1. RX Interrupt is occurred after interrupt is cleared. Even if
interrupt is masked/disabled before(or probe time), RIS's Rx interrupt
is set to 1. Of course, masked status is zero.
...
2. RXFE of flag register is zero and fifo is not empty before LCRH is cleared.
	writew(0, uap->port.membase + uap->lcrh_rx);
3. RXFE of flag register is changed to '1'  after LCRH is cleared. but
the fifo is not actually empty.
...
4. Finally, We enable interrupts.
	spin_lock_irq(&uap->port.lock);
	uap->im = UART011_RTIM;
	if (!pl011_dma_rx_running(uap))
		uap->im |= UART011_RXIM;
	writew(uap->im, uap->port.membase + UART011_IMSC);
	spin_unlock_irq(&uap->port.lock);
5. The RIS's field which is enabled by IMSC is reflected to MIS as
soon as the interrupt enable. (We checked this on our ARM platform )
6. IRQ context is started. pl011_fifo_to_tty is called by pl011_int.
static int pl011_fifo_to_tty(struct uart_amba_port *uap)
...
	while (max_count--) {
		status = readw(uap->port.membase + UART01x_FR);
		if (status & UART01x_FR_RXFE)
			break;
...
7. pl011_fifo_to_tty can't read any data from DR because of the break
condition for RXFE. Rx interrupt can't be cleared. cpu is looping in
irq context.

This is why we need to be cleared just after LCRH is cleared not
before irq_request. Let's get back to my patch. Even if data is
received before or after interrupt is cleared, flag register will show
actual fifo status. Interrupt handler runs normally after the uart
operation is started up by enabling interrupt.

+       spin_lock_irq(&uap->port.lock);
        writew(0, uap->port.membase + uap->lcrh_rx);
+       /* Clear pending error and receive interrupts */
+       writew(UART011_OEIS | UART011_BEIS | UART011_PEIS | UART011_FEIS |
+               UART011_RTIS | UART011_RXIS, uap->port.membase + UART011_ICR);
+       spin_unlock_irq(&uap->port.lock);

Thanks,
Chanho Min

WARNING: multiple messages have this Message-ID (diff)
From: Chanho Min <chanho0207@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Alan Cox <alan@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>,
	"Kim, Jong-Sung" <neidhard.kim@lge.com>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH] Clear previous interrupts after fifo is disabled
Date: Wed, 29 Feb 2012 11:47:02 +0900	[thread overview]
Message-ID: <CAOAMb1CvjxGHSekURXAhw5DL2W2-3Smw3ZTWuAi2E-1UBxHEFg@mail.gmail.com> (raw)
In-Reply-To: <20120228102337.GF18045@n2100.arm.linux.org.uk>

> Which is why my patch explicitly clears the receive interrupt status
> before requesting the interrupt.  Have you read my patch?
This is the hang-up scenario with your patch.

pl011_startup(struct uart_port *port)
 	uap->port.uartclk = clk_get_rate(uap->clk);

	/* Clear pending error and receive interrupts */
	writew(UART011_OEIS | UART011_BEIS | UART011_PEIS | UART011_FEIS |
	       UART011_RTIS | UART011_RXIS, uap->port.membase + UART011_ICR);
...
1. RX Interrupt is occurred after interrupt is cleared. Even if
interrupt is masked/disabled before(or probe time), RIS's Rx interrupt
is set to 1. Of course, masked status is zero.
...
2. RXFE of flag register is zero and fifo is not empty before LCRH is cleared.
	writew(0, uap->port.membase + uap->lcrh_rx);
3. RXFE of flag register is changed to '1'  after LCRH is cleared. but
the fifo is not actually empty.
...
4. Finally, We enable interrupts.
	spin_lock_irq(&uap->port.lock);
	uap->im = UART011_RTIM;
	if (!pl011_dma_rx_running(uap))
		uap->im |= UART011_RXIM;
	writew(uap->im, uap->port.membase + UART011_IMSC);
	spin_unlock_irq(&uap->port.lock);
5. The RIS's field which is enabled by IMSC is reflected to MIS as
soon as the interrupt enable. (We checked this on our ARM platform )
6. IRQ context is started. pl011_fifo_to_tty is called by pl011_int.
static int pl011_fifo_to_tty(struct uart_amba_port *uap)
...
	while (max_count--) {
		status = readw(uap->port.membase + UART01x_FR);
		if (status & UART01x_FR_RXFE)
			break;
...
7. pl011_fifo_to_tty can't read any data from DR because of the break
condition for RXFE. Rx interrupt can't be cleared. cpu is looping in
irq context.

This is why we need to be cleared just after LCRH is cleared not
before irq_request. Let's get back to my patch. Even if data is
received before or after interrupt is cleared, flag register will show
actual fifo status. Interrupt handler runs normally after the uart
operation is started up by enabling interrupt.

+       spin_lock_irq(&uap->port.lock);
        writew(0, uap->port.membase + uap->lcrh_rx);
+       /* Clear pending error and receive interrupts */
+       writew(UART011_OEIS | UART011_BEIS | UART011_PEIS | UART011_FEIS |
+               UART011_RTIS | UART011_RXIS, uap->port.membase + UART011_ICR);
+       spin_unlock_irq(&uap->port.lock);

Thanks,
Chanho Min
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-02-29  2:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27  9:30 [PATCH] Clear previous interrupts after fifo is disabled Chanho Min
2012-02-27 10:45 ` Linus Walleij
2012-02-27 10:45   ` Linus Walleij
2012-02-27 10:48 ` Russell King - ARM Linux
2012-02-27 11:02   ` Russell King - ARM Linux
2012-02-27 13:54     ` Linus Walleij
2012-02-28  1:35     ` Chanho Min
2012-02-28  8:35       ` Russell King - ARM Linux
2012-02-28  8:35         ` Russell King - ARM Linux
2012-02-28  9:16         ` Chanho Min
2012-02-28  9:16           ` Chanho Min
2012-02-28  9:21           ` Russell King - ARM Linux
2012-02-28  9:46             ` Chanho Min
2012-02-28 10:23               ` Russell King - ARM Linux
2012-02-29  2:47                 ` Chanho Min [this message]
2012-02-29  2:47                   ` Chanho Min
2012-03-08  9:02 ` Kim, Jong-Sung
2012-03-08  9:02   ` Kim, Jong-Sung
2012-03-08 18:49 ` Greg Kroah-Hartman
2012-03-09 16:34   ` Linus Walleij
2012-03-09 16:34     ` Linus Walleij
2012-03-09 16:37     ` Greg Kroah-Hartman
2012-03-09 16:37       ` Greg Kroah-Hartman
2012-03-10  2:14       ` Chanho Min
2012-03-12  1:24         ` Kim, Jong-Sung
2012-03-12  1:24           ` Kim, Jong-Sung
2012-03-12  8:29   ` Linus Walleij

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=CAOAMb1CvjxGHSekURXAhw5DL2W2-3Smw3ZTWuAi2E-1UBxHEFg@mail.gmail.com \
    --to=chanho0207@gmail.com \
    --cc=alan@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=neidhard.kim@lge.com \
    --cc=shreshthakumar.sahu@stericsson.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.