[PATCH 2/2] arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck

[Quentin Schulz]

Hi Łukasz,

On 1/21/25 11:28 AM, Łukasz Czechowski wrote:
> Hi Quentin,
> 
>> On 1/21/25 10:41 AM, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>>
>> Hi Lukasz,
>>
>> On 1/21/25 10:22 AM, Lukasz Czechowski wrote:
>>> UART controllers without flow control seem to behave unstable
>>> in case DMA is enabled. The issues were indicated in the message:
>>> https://lore.kernel.org/linux-arm-kernel/CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com/
>>> In case of PX30-uQ7 Ringneck SoM, it was noticed that after couple
>>> of hours of UART communication, the CPU stall was occurring,
>>> leading to the system becoming unresponsive.
>>> After disabling the DMA, extensive UART communication tests for
>>> up to two weeks were performed, and no issues were further
>>> observed.
>>> The flow control pins for uart5 are not available on PX30-uQ7
>>> Ringneck, as configured by pinctrl-0, so the DMA nodes were
>>> removed on SoM dtsi.
>>>
>>
>> Reviewed-by: Quentin Schulz <quentin.schulz at cherry.de>
>>
>> We should backport this to stable releases too, so please follow the
>> instructions from here:
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch
>>
>> Essentially:
>>
>> Cc: stable at vger.kernel.org
>>
>> in the commit log and we'll need a
>>
>> Fixes: <commit hash>
>>
>> trailer as well with the commit hash of the commit introducing the issue
>> (likely the one defining uart5 for Ringneck for us).
>>
>> Considering that UART0 CTS and RTS are routed to Q7 header but only
>> usable when Haikou exposes UART0 on the DB9 connector (via the SW2
>> switch), which is NOT the default state (and in any case not supported
>> by our current device tree), I believe we should make the same change to
>> the uart0 node in haikou dts for Ringneck. What do you think? Can you
>> send another patch for that one?
> 
> It seems that in case of uart0, that is configured as kernel console, the DMA
> is not used by the kernel:
> https://lore.kernel.org/linux-serial/20200217114016.49856-7-andriy.shevchenko@linux.intel.com/
> Which is likely why the issue was not observed so far. However it might be
> good to do the same change to be on the safe side.
> Should I extend this patch series with the fix for the Haikou device tree then,
> or create a new one?
> 

Ah, I had missed that one, thanks for the heads up. Just a small remark, 
better send links to merged commits rather than mailing list patches, 
it's a bit more difficult to figure out if the patch (and that version 
of the patch) is merged. If there was an interesting discussion on the 
patch and that information got lost when merging, nice to add the ML 
link though!
In the case of the linked patch, it is merged indeed: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/serial/8250/8250_port.c?id=089b6d36549160b535e109cd07ed6d578b81de46

No, no need to send a patch. When Haikou is configured to have UART0 on 
the DB9 connector (and the Device Tree is adapted for it) and not use it 
as kernel console, we should be able to use hardware flow control and 
not have this issue. So we don't need to remove dmas/dma-names when it's 
used as kernel console, and we don't need to remove them when routed to 
DB9 connector either, so all good :)

Cheers,
Quentin