Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221106161443.4104-1-wens@kernel.org> <CAMdYzYomgwo3RiUr4pptOD=AUgUS4f6Aqtio3agQP2F-bm2WZQ@mail.gmail.com>
 <CAGb2v64vKbgZxZUyVSdTfzuukHeUdK-8ymxUVGYg=GGShY6O-g@mail.gmail.com>
In-Reply-To: <CAGb2v64vKbgZxZUyVSdTfzuukHeUdK-8ymxUVGYg=GGShY6O-g@mail.gmail.com>
From:   Peter Geis <pgwipeout@gmail.com>
Date:   Sun, 6 Nov 2022 20:50:43 -0500
Message-ID: <CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com>
Subject: Re: [PATCH] arm64: dts: rockchip: rk356x: Add dma-names to UART
 device nodes
To:     wens@kernel.org
Cc:     Heiko Stuebner <heiko@sntech.de>, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Nov 6, 2022 at 8:28 PM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> On Mon, Nov 7, 2022 at 8:52 AM Peter Geis <pgwipeout@gmail.com> wrote:
> >
> > On Sun, Nov 6, 2022 at 11:15 AM Chen-Yu Tsai <wens@kernel.org> wrote:
> > >
> > > From: Chen-Yu Tsai <wens@csie.org>
> > >
> > > At least one implementation, Linux, requires "dma-names" properties
> > > be used together with "dmas" to describe DMA resources. These are
> > > currently missing, causing DMA to not be used for UARTs.
> > >
> > > Add "dma-names" to the UART device nodes.
> > >
> > > Fixes: a3adc0b9071d ("arm64: dts: rockchip: add core dtsi for RK3568 SoC")
> > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >
> > Enabling dma globally can cause some interesting issues, have you
> > tested this fully?
>
> It seems to work OK with the Bluetooth controller, though I'm not running
> extensive transfers over it. Scanning both traditional and LE works, and
> does exercise the DMA controller.
>
> If your worried about the DMA controller running out of channels and
> impacting other peripherals, the DMA controller for the UARTs is only
> shared with other UARTs, SPI, and PWM (which the kernel doesn't support
> DMAing to). The UART and SPI drivers can fall back to PIO if DMA isn't
> available.

Nah, enabling it for bluetooth is fine because you have flow control.
My issues have been on channels without flow control. Without DMA it
simply drops messages or the channel hangs until you close and reopen
it. With DMA, when an overflow locks up the channel it is usually
unavailable until the board is rebooted.

It's the main reason I've stopped daisy chaining boards to each other,
when the board powers off the pinmux pulls go crazy just long enough
to lock up the other end. It sometimes happens with reboots and large
data bursts as well.

I'd only enable them on bluetooth channels for the time being because of this.

>
> So this isn't like on the RK3399 and prior chips, where it was shared with
> audio, and exhausting the DMA channels would cause audio to not probe.
>
> Regards
> ChenYu