On 09/20/16 15:57, Peter Ujfalusi wrote: > On 09/20/16 14:56, Vignesh R wrote: >> >> >> On Tuesday 20 September 2016 03:39 PM, Peter Ujfalusi wrote: >>> On 09/15/16 19:15, Sebastian Andrzej Siewior wrote: >>>> On 2016-09-15 16:32:18 [+0200], To Peter Ujfalusi wrote: >>>>> Before having the 48 bytes as burst I had 1 byte. At this point the DMA >>>>> engine transferred one byte at a time but something else was not perfect >>>>> so I went for 48. >>>> >>>> after transferring 30 out of 48 bytes (burst 1, size 48) there was >>>> nothing: no interrupt nothing. So it waited for another 18 bytes to >>>> happen. >>> >>> You need to program the DMA to read/write FIFO threshold number of bytes. >>> >>> In RX the DMA request will be asserted when the FIFO has threshold amount of >>> data and you need to read threshold amount out. >>> >>> In TX the request will be asserted if you have threshold amount of _free_ >>> space in the FIFO and you need to transfer threshold amount of data in response. >>> >>> But if there is a bug in the UART that it de-asserts the RX DMA request line >>> after you have read out some data, but not the threshold amount, then it will >>> still going to assert it when the FIFO level is up again to the threshold level. >>> >>>> With burst size = transfer size there is this timeout interrupt >>>> that helps. >>> >>> Yep, if the DMA is not reading you need to drain somehow, but I can not find >>> specific guidelines for it, apart from one place where it talks about some EOF >>> interrupt. >>> >> >> That IRQ is available in IrDA mode (infrared data transfer) and not in >> UART mode. >> >> AFAIK, there is no way to know end of transfer, if all data in FIFO is >> taken out by DMA and DMA is waiting for more data to arrive, while the >> sender has stopped sending more data. > > That might be true. It is nice to have one register with different bits in > different use cases... > But why 24.3.4.6.4.4 DMA Reception (am572x SR1.1 RevU TRM) talks about EOF > interrupt? > > Given the HW, I think it is wrong to have RX FIFO set in a way we do atm. > > FWIW the following change works on omap5-uevm (sDMA) with DMA enabled serial > console: > > diff --git a/drivers/tty/serial/8250/8250_omap.c > b/drivers/tty/serial/8250/8250_omap.c > index 61ad6c3b20a0..fa1b1b6fa83b 100644 > --- a/drivers/tty/serial/8250/8250_omap.c > +++ b/drivers/tty/serial/8250/8250_omap.c > @@ -80,7 +80,7 @@ > #define OMAP_UART_TX_WAKEUP_EN (1 << 7) > > #define TX_TRIGGER 1 > -#define RX_TRIGGER 48 > +#define RX_TRIGGER 1 > > #define OMAP_UART_TCR_RESTORE(x) ((x / 4) << 4) > #define OMAP_UART_TCR_HALT(x) ((x / 4) << 0) > @@ -1215,7 +1215,6 @@ static int omap8250_probe(struct platform_device *pdev) > priv->omap8250_dma.fn = the_no_dma_filter_fn; > priv->omap8250_dma.tx_dma = omap_8250_tx_dma; > priv->omap8250_dma.rx_dma = omap_8250_rx_dma; > - priv->omap8250_dma.rx_size = RX_TRIGGER; > priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER; > priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER; and this fixes the annoying lag on the serial console as well I have since the DMA was enabled for the UART as typing one character would be not enough to trigger the DMA, resulting wait for the timeout and flushing the data out from the FIFO. I really see no point of having DMA for the serial console... not with the current setup. Probably for TX, but for sure not for the RX. So I give my: Tested-by/Reviewed-by/Recommended-by to this change. I know that this might affect performance as we constantly run the DMA from UART to memory, but it makes the serial console usable. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
