On Tuesday 20 September 2016 06:38 PM, Peter Ujfalusi wrote: > 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? >> Not sure that might be an error in the TRM, clearly bit 7 is for Enables the CTS* interrupt. So Bit 7 cannot be simultaneously used for EOF interrupt as well. >> Given the HW, I think it is wrong to have RX FIFO set in a way we do atm. I think RX trigger was set to 48 bytes as that is 3/4th the size of UART FIFO size. That may not a wise choice for console usecase. But there is one thing to verify: with .src_maxburst = 1 and .rx_size = 4K, there won't be any timeout as every byte that arrives at RX FIFO is immediately taken out by DMA and if <4K bytes of data is received, DMA does not raise completion interrupt and data is stuck in destination buffer forever. It is never pushed to higher layer. (I have not verified whether this is the case when RX_TRIGGER is 1 or we will get a TIMEOUT at the end of transfer irrespective of whether data is taken out from FIFO or not with RX_TRIGGER as 1) >> >> 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; Did you test after removing the line: priv->rx_dma_broken = true; W/o this, DMA is still disabled. > > 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. > So, I guess we can use TX_TRIGGER = RX_TRIGGER = 48 bytes if we ignore DMA for console use case -- Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
