On 09/20/16 20:28, Sebastian Andrzej Siewior wrote: > On 2016-09-20 13:09:46 [+0300], 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. > > correct. This happens. > >> 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. > > What is done is to pause the DMA transfer, cancel it and then read the > FIFO manually. As on sDMA the pause is not working, why not to: - disable DMA request generation in UART this will 'pause' the DMA as there will be no more requests coming - get DMA pointer - stop DMA - drain FIFO in PIO (if there is data in there) -- 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
