Date:   Mon, 23 Sep 2019 17:06:34 +0200
From:   Philipp Puschmann <philipp.puschmann@...ix.com>
To:     Adam Ford <aford173@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        fugang.duan@....com, jlu@...gutronix.de,
        Fabio Estevam <festevam@...il.com>,
        Sascha Hauer <s.hauer@...gutronix.de>, vkoul@...nel.org,
        NXP Linux Team <linux-imx@....com>,
        Sascha Hauer <kernel@...gutronix.de>,
        dmaengine@...r.kernel.org, dan.j.williams@...el.com,
        Robin Gong <yibin.gong@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Lucas Stach <l.stach@...gutronix.de>
Subject: Re: [PATCH v5 0/3] Fix UART DMA freezes for i.MX SOCs

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@...ix.com> 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@...il.com> #imx6q w/ 4.19 Kernel
> 
>> Signed-off-by: Philipp Puschmann <philipp.puschmann@...ix.com>
>> Reviewed-by: Fugang Duan <fugang.duan@....com>
>>
>> ---
>>
>> 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@...ts.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists