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; I would do something with the TX_TRIGGER as well if it were up to me... If the transfer size is less then the FIFO (64 bytes), use that number, if it is bigger, then use 42, 50, whatever number fits best, probably which can multiply evenly the whole amount we were asked to transfer... -- 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
