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>
In-Reply-To: <CAMdYzYomgwo3RiUr4pptOD=AUgUS4f6Aqtio3agQP2F-bm2WZQ@mail.gmail.com>
Reply-To: wens@kernel.org
From:   Chen-Yu Tsai <wens@kernel.org>
Date:   Mon, 7 Nov 2022 09:28:36 +0800
Message-ID: <CAGb2v64vKbgZxZUyVSdTfzuukHeUdK-8ymxUVGYg=GGShY6O-g@mail.gmail.com>
Subject: Re: [PATCH] arm64: dts: rockchip: rk356x: Add dma-names to UART
 device nodes
To:     Peter Geis <pgwipeout@gmail.com>
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 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.

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