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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Quentin,

> On 1/21/25 10:41 AM, Quentin Schulz <quentin.schulz@xxxxxxxxx> 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@xxxxxxxxxxxxxx/
> > 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@xxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxx/
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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux