[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