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;
From:   Heiko =?ISO-8859-1?Q?St=FCbner?= <heiko@sntech.de>
To:     wens@kernel.org, Peter Geis <pgwipeout@gmail.com>
Cc:     devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: rk356x: Add dma-names to UART device nodes
Date:   Wed, 11 Jan 2023 11:41:27 +0100
Message-ID: <18284546.sWSEgdgrri@diego>
In-Reply-To: <CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com>
References: <20221106161443.4104-1-wens@kernel.org> <CAGb2v64vKbgZxZUyVSdTfzuukHeUdK-8ymxUVGYg=GGShY6O-g@mail.gmail.com> <CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

Am Montag, 7. November 2022, 02:50:43 CET schrieb Peter Geis:
> 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.

I guess I'll agree with Peter here. So enabling uart dmas should likely
happen on a board-level for bluetooth connections.