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

[Łukasz Czechowski]

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?

>
> Thanks!
> Quentin

Best Regards,
Lukasz