From: "Heiko Stübner" <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 [thread overview]
Message-ID: <18284546.sWSEgdgrri@diego> (raw)
In-Reply-To: <CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com>
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.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <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 [thread overview]
Message-ID: <18284546.sWSEgdgrri@diego> (raw)
In-Reply-To: <CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com>
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <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 [thread overview]
Message-ID: <18284546.sWSEgdgrri@diego> (raw)
In-Reply-To: <CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com>
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.
next prev parent reply other threads:[~2023-01-11 10:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-06 16:14 [PATCH] arm64: dts: rockchip: rk356x: Add dma-names to UART device nodes Chen-Yu Tsai
2022-11-06 16:14 ` Chen-Yu Tsai
2022-11-06 16:14 ` Chen-Yu Tsai
2022-11-07 0:52 ` Peter Geis
2022-11-07 0:52 ` Peter Geis
2022-11-07 0:52 ` Peter Geis
2022-11-07 1:28 ` Chen-Yu Tsai
2022-11-07 1:28 ` Chen-Yu Tsai
2022-11-07 1:28 ` Chen-Yu Tsai
2022-11-07 1:50 ` Peter Geis
2022-11-07 1:50 ` Peter Geis
2022-11-07 1:50 ` Peter Geis
2023-01-11 10:41 ` Heiko Stübner [this message]
2023-01-11 10:41 ` Heiko Stübner
2023-01-11 10:41 ` Heiko Stübner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18284546.sWSEgdgrri@diego \
--to=heiko@sntech.de \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=pgwipeout@gmail.com \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.