Hi Adam, Am 23.09.19 um 16:55 schrieb Adam Ford: > On Mon, Sep 23, 2019 at 8:58 AM Philipp Puschmann > <philipp.puschmann@xxxxxxxxx> wrote: >> >> For some years and since many kernel versions there are reports that >> RX UART DMA channel stops working at one point. So far the usual >> workaround was to disable RX DMA. This patches fix the underlying >> problem. >> >> When a running sdma script does not find any usable destination buffer >> to put its data into it just leads to stopping the channel being >> scheduled again. As solution we manually retrigger the sdma script for >> this channel and by this dissolve the freeze. >> >> While this seems to work fine so far, it may come to buffer overruns >> when the channel - even temporary - is stopped. This case has to be >> addressed by device drivers by increasing the number of DMA periods. >> >> This patch series was tested with the current kernel and backported to >> kernel 4.15 with a special use case using a WL1837MOD via UART and >> provoking the hanging of UART RX DMA within seconds after starting a >> test application. It resulted in well known >> "Bluetooth: hci0: command 0x0408 tx timeout" >> errors and complete stop of UART data reception. Our Bluetooth traffic >> consists of many independent small packets, mostly only a few bytes, >> causing high usage of periods. >> > > Using the 4.19.y branch, this seems to working just fine for me with an i.MX6Q > with WL1837MOD Bluetooth connected to UART2. I am still seeing some > timeouts with 5.3, but I'm going to continue to run some tests. Thanks for testing. With my local setup i still have very few tx timeouts too. But i think they have a different cause and especially different consequences. When the problem addressed by this series appear you get a whole bunch of tx timeouts (and maybe errors from Bluetooth layer) and monitoring received Bluetooth packets with hciconfig shows a complete freeze of rx counter. Only resetting the hci_uart driver and the wl1837mon then helps. With these patches applied the rx data shold still coming in even if a single or multiple tx timeout error happen. I'm not sure where the error comes from and what the consequences for the Bluetooth layer are. Regards, Philipp > > Tested-by: Adam Ford <aford173@xxxxxxxxx> #imx6q w/ 4.19 Kernel > >> Signed-off-by: Philipp Puschmann <philipp.puschmann@xxxxxxxxx> >> Reviewed-by: Fugang Duan <fugang.duan@xxxxxxx> >> >> --- >> >> Changelog v5: >> - join with patch version from Jan Luebbe >> - adapt comments and patch descriptions >> - add Reviewed-by >> >> Changelog v4: >> - fixed the fixes tags >> >> Changelog v3: >> - fixes typo in dma_wmb >> - add fixes tags >> >> Changelog v2: >> - adapt title (this patches are not only for i.MX6) >> - improve some comments and patch descriptions >> - add a dma_wb() around BD_DONE flag >> - add Reviewed-by tags >> - split off "serial: imx: adapt rx buffer and dma periods" >> >> Philipp Puschmann (3): >> dmaengine: imx-sdma: fix buffer ownership >> dmaengine: imx-sdma: fix dma freezes >> dmaengine: imx-sdma: drop redundant variable >> >> drivers/dma/imx-sdma.c | 37 +++++++++++++++++++++++++++---------- >> 1 file changed, 27 insertions(+), 10 deletions(-) >> >> -- >> 2.23.0 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
