From: Hector Palacios <hector.palacios@digi.com>
To: Marek Vasut <marex@denx.de>
Cc: "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"b32955@freescale.com" <b32955@freescale.com>,
"fabio.estevam@freescale.com" <fabio.estevam@freescale.com>,
"u.kleine-koenig@pengutronix.de" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH 3/3] serial: mxs-auart: move irq handling to a tasklet
Date: Fri, 29 Nov 2013 19:04:49 +0100 [thread overview]
Message-ID: <5298D741.1080100@digi.com> (raw)
In-Reply-To: <201311291800.12366.marex@denx.de>
On 11/29/2013 06:00 PM, Marek Vasut wrote:
> Dear Hector Palacios,
>
>> The ISR was handling CTS flag and RX/TX processing.
>> Occasionally interrupts were coming in the middle of the ISR and
>> led to blocking transmission (with hw flow) or loss of data.
>> This patch moves this processing to a tasklet that the ISR schedules.
>>
>> Signed-off-by: Hector Palacios <hector.palacios@digi.com>
>> ---
>> drivers/tty/serial/mxs-auart.c | 61
>> +++++++++++++++++++++++++++--------------- 1 file changed, 39
>> insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/tty/serial/mxs-auart.c
>> b/drivers/tty/serial/mxs-auart.c index e5540c89dd48..7021269c70b2 100644
>> --- a/drivers/tty/serial/mxs-auart.c
>> +++ b/drivers/tty/serial/mxs-auart.c
>> @@ -148,6 +148,10 @@ struct mxs_auart_port {
>> struct clk *clk;
>> struct device *dev;
>>
>> + struct tasklet_struct tasklet;
>> + unsigned int irq_status;
>> + unsigned int status;
>> +
>> /* for DMA */
>> struct scatterlist tx_sgl;
>> struct dma_chan *tx_dma_chan;
>> @@ -680,38 +684,48 @@ static void mxs_auart_settermios(struct uart_port *u,
>> }
>> }
>>
>> +/*
>> + * tasklet handling tty stuff outside the interrupt handler.
>> + */
>> +static void mxs_auart_tasklet_func(unsigned long data)
>> +{
>> + struct uart_port *port = (struct uart_port *)data;
>> + struct mxs_auart_port *s = to_auart_port(port);
>> +
>> + /* Handle status irq */
>> + if (s->irq_status & AUART_INTR_CTSMIS) {
>> + uart_handle_cts_change(&s->port, s->status & AUART_STAT_CTS);
>> + writel(AUART_INTR_CTSMIS,
>> + s->port.membase + AUART_INTR_CLR);
>> + }
>> + /* Handle receive irq */
>> + if (s->irq_status & (AUART_INTR_RTIS | AUART_INTR_RXIS)) {
>> + if (!auart_dma_enabled(s))
>> + mxs_auart_rx_chars(s);
>> + }
>> + /* Handle transmit irq */
>> + if (s->irq_status & AUART_INTR_TXIS)
>> + mxs_auart_tx_chars(s);
>> +}
>> +
>> static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
>> {
>> - u32 istat;
>> struct mxs_auart_port *s = context;
>> - u32 stat = readl(s->port.membase + AUART_STAT);
>>
>> - istat = readl(s->port.membase + AUART_INTR);
>> + s->status = readl(s->port.membase + AUART_STAT);
>> + s->irq_status = readl(s->port.membase + AUART_INTR);
>
> Aren't you up for a nice race condition here if you get interrupt while checking
> the s->irq_status bits in the tasklet ?
Sad, but true. :-(
But if I need to wait on the ISR for the tasklet to process then this patch loses its
original meaning. Argh... it works so nicely!
Best regards,
--
Hector Palacios
WARNING: multiple messages have this Message-ID (diff)
From: hector.palacios@digi.com (Hector Palacios)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] serial: mxs-auart: move irq handling to a tasklet
Date: Fri, 29 Nov 2013 19:04:49 +0100 [thread overview]
Message-ID: <5298D741.1080100@digi.com> (raw)
In-Reply-To: <201311291800.12366.marex@denx.de>
On 11/29/2013 06:00 PM, Marek Vasut wrote:
> Dear Hector Palacios,
>
>> The ISR was handling CTS flag and RX/TX processing.
>> Occasionally interrupts were coming in the middle of the ISR and
>> led to blocking transmission (with hw flow) or loss of data.
>> This patch moves this processing to a tasklet that the ISR schedules.
>>
>> Signed-off-by: Hector Palacios <hector.palacios@digi.com>
>> ---
>> drivers/tty/serial/mxs-auart.c | 61
>> +++++++++++++++++++++++++++--------------- 1 file changed, 39
>> insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/tty/serial/mxs-auart.c
>> b/drivers/tty/serial/mxs-auart.c index e5540c89dd48..7021269c70b2 100644
>> --- a/drivers/tty/serial/mxs-auart.c
>> +++ b/drivers/tty/serial/mxs-auart.c
>> @@ -148,6 +148,10 @@ struct mxs_auart_port {
>> struct clk *clk;
>> struct device *dev;
>>
>> + struct tasklet_struct tasklet;
>> + unsigned int irq_status;
>> + unsigned int status;
>> +
>> /* for DMA */
>> struct scatterlist tx_sgl;
>> struct dma_chan *tx_dma_chan;
>> @@ -680,38 +684,48 @@ static void mxs_auart_settermios(struct uart_port *u,
>> }
>> }
>>
>> +/*
>> + * tasklet handling tty stuff outside the interrupt handler.
>> + */
>> +static void mxs_auart_tasklet_func(unsigned long data)
>> +{
>> + struct uart_port *port = (struct uart_port *)data;
>> + struct mxs_auart_port *s = to_auart_port(port);
>> +
>> + /* Handle status irq */
>> + if (s->irq_status & AUART_INTR_CTSMIS) {
>> + uart_handle_cts_change(&s->port, s->status & AUART_STAT_CTS);
>> + writel(AUART_INTR_CTSMIS,
>> + s->port.membase + AUART_INTR_CLR);
>> + }
>> + /* Handle receive irq */
>> + if (s->irq_status & (AUART_INTR_RTIS | AUART_INTR_RXIS)) {
>> + if (!auart_dma_enabled(s))
>> + mxs_auart_rx_chars(s);
>> + }
>> + /* Handle transmit irq */
>> + if (s->irq_status & AUART_INTR_TXIS)
>> + mxs_auart_tx_chars(s);
>> +}
>> +
>> static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
>> {
>> - u32 istat;
>> struct mxs_auart_port *s = context;
>> - u32 stat = readl(s->port.membase + AUART_STAT);
>>
>> - istat = readl(s->port.membase + AUART_INTR);
>> + s->status = readl(s->port.membase + AUART_STAT);
>> + s->irq_status = readl(s->port.membase + AUART_INTR);
>
> Aren't you up for a nice race condition here if you get interrupt while checking
> the s->irq_status bits in the tasklet ?
Sad, but true. :-(
But if I need to wait on the ISR for the tasklet to process then this patch loses its
original meaning. Argh... it works so nicely!
Best regards,
--
Hector Palacios
next prev parent reply other threads:[~2013-11-29 18:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-29 16:35 [PATCH 0/3] serial: mxs-auart: flush_buffer hook and interrupt processing Hector Palacios
2013-11-29 16:35 ` Hector Palacios
2013-11-29 16:35 ` [PATCH 1/3] serial: mxs-auart: implement flush_buffer hook Hector Palacios
2013-11-29 16:35 ` Hector Palacios
2013-11-29 16:50 ` Marek Vasut
2013-11-29 16:50 ` Marek Vasut
2013-11-29 17:49 ` Hector Palacios
2013-11-29 17:49 ` Hector Palacios
2013-11-29 18:02 ` Marek Vasut
2013-11-29 18:02 ` Marek Vasut
2013-11-29 18:02 ` Lucas Stach
2013-11-29 18:02 ` Lucas Stach
2013-11-29 16:35 ` [PATCH 2/3] serial: mxs-auart: check BUSY flag on tx_empty hook Hector Palacios
2013-11-29 16:35 ` Hector Palacios
2013-11-29 16:35 ` [PATCH 3/3] serial: mxs-auart: move irq handling to a tasklet Hector Palacios
2013-11-29 16:35 ` Hector Palacios
2013-11-29 17:00 ` Marek Vasut
2013-11-29 17:00 ` Marek Vasut
2013-11-29 18:04 ` Hector Palacios [this message]
2013-11-29 18:04 ` Hector Palacios
2013-11-29 16:44 ` [PATCH 0/3] serial: mxs-auart: flush_buffer hook and interrupt processing Marek Vasut
2013-11-29 16:44 ` Marek Vasut
2013-11-29 16:46 ` Hector Palacios
2013-11-29 16:46 ` Hector Palacios
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=5298D741.1080100@digi.com \
--to=hector.palacios@digi.com \
--cc=b32955@freescale.com \
--cc=fabio.estevam@freescale.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=marex@denx.de \
--cc=u.kleine-koenig@pengutronix.de \
/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.