[PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
This is my complete queue fo the omap serial driver based on the 8250 core code. I played with it on beagle bone, am335x-evm and dra7xx including DMA. The runtime-pm pieces look now bug-compatible with the omap-serial driver. Besides the runtime-om improvement I also fixed a few corner cases for the TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the problem has been in 8250-dma via patch #13. The whole queue is available at git://git.breakpoint.cc/bigeasy/linux.git uart_v8 Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
Hi, On Fri, Sep 05, 2014 at 09:02:35PM +0200, Sebastian Andrzej Siewior wrote: > This is my complete queue fo the omap serial driver based on the 8250 core > code. I played with it on beagle bone, am335x-evm and dra7xx including DMA. > The runtime-pm pieces look now bug-compatible with the omap-serial driver. > Besides the runtime-om improvement I also fixed a few corner cases for the > TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the > problem has been in 8250-dma via patch #13. Thanks for the respin. I've just tested the series a bit. Here's some things I ran into. - Basic console use is better than the previous series. It behaves pretty much like the omap-serial implementation. - ncurses based applications (vi, less) don't play nice for me on the console with this series. less doesn't show me anything. vi doesn't return to console properly. - I seem seem to get stuck in a "serial8250: too much work for irq%d" loop somewhat reliably. We have a rather demanding application with typically somewhere between 600 and 1000 byte packets being sent at 240Hz (roughly somewhere between 1.5 and 2 Mb/s). We run at baudrate 3500k. I get into this "too much work" thing already when running at 300 bytes per packet. I hope this is of some use to you. I'll do more testing later. Thanks, Frans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
* Frans Klaver | 2014-09-08 16:46:18 [+0200]:
>- ncurses based applications (vi, less) don't play nice for me on the
> console with this series. less doesn't show me anything. vi doesn't
> return to console properly.
Can you give a test case
>- I seem seem to get stuck in a "serial8250: too much work for irq%d"
> loop somewhat reliably. We have a rather demanding application with
> typically somewhere between 600 and 1000 byte packets being sent at
> 240Hz (roughly somewhere between 1.5 and 2 Mb/s). We run at baudrate
> 3500k. I get into this "too much work" thing already when running at
> 300 bytes per packet.
Do you get this message also at lower baud rates, say 115200?
What I am trying to understand is why you are spinning in the handler.
_With_ DMA you should hardly get into the serial handler under normal
conditions. Running at 3.5MB/sec should give one byte every 2.8us and
48 Bytes every ~137us. This looks like plenty of time to get out of
the handler. My *guess* is that serial8250_handle_irq() has IIR often
set to timeout and you end up fetching byte after byte.
This patch should protocol when and why you got into the handler.
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 7111b22de000..59852069e4a0 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1583,6 +1583,7 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
status = serial_port_in(port, UART_LSR);
DEBUG_INTR("status = %x...", status);
+ trace_printk("l%d IIR %x LSR %x\n", port->line, iir, status);
if (status & (UART_LSR_DR | UART_LSR_BI)) {
if (up->dma)
@@ -1707,6 +1708,7 @@ static irqreturn_t serial8250_interrupt(int irq, void
*dev_id)
spin_unlock(&i->lock);
+ trace_printk("%d e\n", irq);
DEBUG_INTR("end.\n");
return IRQ_RETVAL(handled);
>I hope this is of some use to you. I'll do more testing later.
Which SoC do you use and do you have DMA enabled?
>Thanks,
>Frans
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
* Sebastian Andrzej Siewior | 2014-09-08 17:15:01 [+0200]: >* Frans Klaver | 2014-09-08 16:46:18 [+0200]: > >>- ncurses based applications (vi, less) don't play nice for me on the >> console with this series. less doesn't show me anything. vi doesn't >> return to console properly. > >Can you give a test case Okay. less. My am335x-evm freezes after a while for no obvious reason. The data that hits the RX fifo is still received but the TX won't do anything. The DMA request is pending, the FIFO level is @64 bytes and the UART doesn't make any progress. On beagle-board I see what you described: less on a file and nothing happens. Disabling DMA seems to help fix the problem omap3. Nothing changes for am335x. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
* Sebastian Andrzej Siewior [140905 12:03]: > This is my complete queue fo the omap serial driver based on the 8250 core > code. I played with it on beagle bone, am335x-evm and dra7xx including DMA. > The runtime-pm pieces look now bug-compatible with the omap-serial driver. > Besides the runtime-om improvement I also fixed a few corner cases for the > TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the > problem has been in 8250-dma via patch #13. > > The whole queue is available at > git://git.breakpoint.cc/bigeasy/linux.git uart_v8 Gave the above branch a quick try, but it again does not idle for my omap3 test cases. It seems that now the cm_idlest1_core sdma bit is blocking deeper idle states. Is that the correct branch to use? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
* Tony Lindgren [140908 10:41]: > * Sebastian Andrzej Siewior [140905 12:03]: > > This is my complete queue fo the omap serial driver based on the 8250 core > > code. I played with it on beagle bone, am335x-evm and dra7xx including DMA. > > The runtime-pm pieces look now bug-compatible with the omap-serial driver. > > Besides the runtime-om improvement I also fixed a few corner cases for the > > TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the > > problem has been in 8250-dma via patch #13. > > > > The whole queue is available at > > git://git.breakpoint.cc/bigeasy/linux.git uart_v8 > > Gave the above branch a quick try, but it again does not idle for > my omap3 test cases. It seems that now the cm_idlest1_core sdma > bit is blocking deeper idle states. Is that the correct branch > to use? Never mind. User error. I forgot to apply my own patch for force idling the UARTs for the omap hwmod. And the sdma bit clears if I do sleep 5 before attempting to read the sysfs entry.. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On Mon, Sep 08, 2014 at 06:33:13PM +0200, Sebastian Andrzej Siewior wrote: > * Sebastian Andrzej Siewior | 2014-09-08 17:15:01 [+0200]: > > >* Frans Klaver | 2014-09-08 16:46:18 [+0200]: > > > >>- ncurses based applications (vi, less) don't play nice for me on the > >> console with this series. less doesn't show me anything. vi doesn't > >> return to console properly. > > > >Can you give a test case > > Okay. less. My am335x-evm freezes after a while for no obvious reason. > The data that hits the RX fifo is still received but the TX won't do > anything. The DMA request is pending, the FIFO level is @64 bytes and > the UART doesn't make any progress. > On beagle-board I see what you described: less on a file and nothing > happens. Exactly that, yes. Frans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On Mon, Sep 08, 2014 at 05:15:01PM +0200, Sebastian Andrzej Siewior wrote:
> * Frans Klaver | 2014-09-08 16:46:18 [+0200]:
>
> >- I seem seem to get stuck in a "serial8250: too much work for irq%d"
> > loop somewhat reliably. We have a rather demanding application with
> > typically somewhere between 600 and 1000 byte packets being sent at
> > 240Hz (roughly somewhere between 1.5 and 2 Mb/s). We run at baudrate
> > 3500k. I get into this "too much work" thing already when running at
> > 300 bytes per packet.
>
> Do you get this message also at lower baud rates, say 115200?
I don't get this message at lower data rates. Haven't tested lower baud
rates yet.
> What I am trying to understand is why you are spinning in the handler.
> _With_ DMA you should hardly get into the serial handler under normal
> conditions. Running at 3.5MB/sec should give one byte every 2.8us and
> 48 Bytes every ~137us. This looks like plenty of time to get out of
> the handler. My *guess* is that serial8250_handle_irq() has IIR often
> set to timeout and you end up fetching byte after byte.
>
> This patch should protocol when and why you got into the handler.
>
> diff --git a/drivers/tty/serial/8250/8250_core.c
> b/drivers/tty/serial/8250/8250_core.c
> index 7111b22de000..59852069e4a0 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -1583,6 +1583,7 @@ int serial8250_handle_irq(struct uart_port *port,
> unsigned int iir)
> status = serial_port_in(port, UART_LSR);
>
> DEBUG_INTR("status = %x...", status);
> + trace_printk("l%d IIR %x LSR %x\n", port->line, iir, status);
>
> if (status & (UART_LSR_DR | UART_LSR_BI)) {
> if (up->dma)
> @@ -1707,6 +1708,7 @@ static irqreturn_t serial8250_interrupt(int irq, void
> *dev_id)
>
> spin_unlock(&i->lock);
>
> + trace_printk("%d e\n", irq);
> DEBUG_INTR("end.\n");
>
> return IRQ_RETVAL(handled);
>
Thanks. I'll give it a spin on Wednesday.
> >I hope this is of some use to you. I'll do more testing later.
>
> Which SoC do you use and do you have DMA enabled?
am335x, DMA is enabled, unless I need to do something extra in the
device tree. We depend on am335x.dtsi, so I would think that would be
automatic if CONFIG_SERIAL_8250_DMA=y.
Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On 09/08/2014 07:55 PM, Tony Lindgren wrote: > * Tony Lindgren [140908 10:41]: >> * Sebastian Andrzej Siewior [140905 12:03]: >>> This is my complete queue fo the omap serial driver based on the 8250 core >>> code. I played with it on beagle bone, am335x-evm and dra7xx including DMA. >>> The runtime-pm pieces look now bug-compatible with the omap-serial driver. >>> Besides the runtime-om improvement I also fixed a few corner cases for the >>> TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the >>> problem has been in 8250-dma via patch #13. >>> >>> The whole queue is available at >>> git://git.breakpoint.cc/bigeasy/linux.git uart_v8 >> >> Gave the above branch a quick try, but it again does not idle for >> my omap3 test cases. It seems that now the cm_idlest1_core sdma >> bit is blocking deeper idle states. Is that the correct branch >> to use? > > Never mind. User error. I forgot to apply my own patch for force > idling the UARTs for the omap hwmod. And the sdma bit clears if > I do sleep 5 before attempting to read the sysfs entry.. Okay. There is also this "uart_v8_hacks" branch where I splitted out the hacks I had like the pstore one or the force idle for instance. > Regards, > > Tony Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On 09/08/2014 08:33 PM, Frans Klaver wrote: > Thanks. I'll give it a spin on Wednesday. Could you please pull the upcoming v9 first? git://git.breakpoint.cc/bigeasy/linux.git uart_v9_pre1 This solves a few of my am335x related issues. The problem that the uart freezes on beagle board xm is still there. >From what I can say is that the DMA transfer is started but not completed and I can't reproduce it on dra7xx > Thanks, > Frans > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On Tue, Sep 09, 2014 at 09:41:20PM +0200, Sebastian Andrzej Siewior wrote: > On 09/08/2014 08:33 PM, Frans Klaver wrote: > > Thanks. I'll give it a spin on Wednesday. > > Could you please pull the upcoming v9 first? > > git://git.breakpoint.cc/bigeasy/linux.git uart_v9_pre1 > > This solves a few of my am335x related issues. Using v9_pre1, I get a kernel panic in edma_dma_pause() on echan->edesc being NULL. I do get data before this happens. This is at high speed, high rate. No mention of the irq having too much to do, though. The more data I transmit, the more likely this is to occur. I don't currently have the setup to lower the baudrate. I would probably need to reproduce this on a beaglebone, instead of our custom board. I'll see if I can do that. If you need more info, just let me know. Thanks, Frans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On 09/10/2014 04:15 PM, Frans Klaver wrote: > On Tue, Sep 09, 2014 at 09:41:20PM +0200, Sebastian Andrzej Siewior wrote: >> On 09/08/2014 08:33 PM, Frans Klaver wrote: >>> Thanks. I'll give it a spin on Wednesday. >> >> Could you please pull the upcoming v9 first? >> >> git://git.breakpoint.cc/bigeasy/linux.git uart_v9_pre1 >> >> This solves a few of my am335x related issues. > > Using v9_pre1, I get a kernel panic in edma_dma_pause() on echan->edesc > being NULL. I do get data before this happens. This is at high speed, > high rate. No mention of the irq having too much to do, though. The more > data I transmit, the more likely this is to occur. Hmm. This shouldn't happen because if dma->rx_running is set, then there should be a descriptor to pause. Could check how this could happen? (and which event tries to do so) In the meantime, the lower part of [0] should fix the NULL bug. [0] https://lkml.org/lkml/2014/7/29/506 > I don't currently have the setup to lower the baudrate. I would probably > need to reproduce this on a beaglebone, instead of our custom board. > I'll see if I can do that. > > If you need more info, just let me know. I just pushed uart_v9_pre2 and I will post it once I rebased it on top Greg's latest. There was a bug where THRE could be active longer than needed caused a few not needed interrupts until the FIFO was empty again. My "less on file" test case did not fail anymore with this. > Thanks, > Frans Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
