linux-kernel - Re: [PATCH] arm64: dts: rockchip: rk3399: Hook up DMA for UARTs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Oct 2021 10:10:25 +0200
From:   Heiko Stuebner <heiko@...ech.de>
To:     Chen-Yu Tsai <wens@...nel.org>
Cc:     Chen-Yu Tsai <wens@...e.org>, Robin Murphy <robin.murphy@....com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: rk3399: Hook up DMA for UARTs

Hi,

Am Montag, 20. September 2021, 19:56:47 CEST schrieb Chen-Yu Tsai:
> From: Chen-Yu Tsai <wens@...e.org>
> 
> The RK3399 has two DMA controllers, one of which is wired up to work
> with the SPI controllers and UARTs. The SPI controllers are already
> hooked up, but the UARTs aren't.
> 
> Add the "dmas" and "dma-names" to the UART device nodes to hook up DMA.

last time this came up, there was the issue of the pl330 driver in the
kernel not being able to handle the case where the number of channels
hooked up was larger than the number of possible channels handled
at the same time (8 for dmac peri according to the TRM).

Did this get solved meanwhile or are we then possibly starving the spi
controllers from dma access when the uarts also get dma channels
and are possibly probed earlier?


Heiko


> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 3871c7fd83b0..87d6e4eb1337 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -608,6 +608,8 @@ uart0: serial@...80000 {
>  		reg = <0x0 0xff180000 0x0 0x100>;
>  		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
>  		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac_peri 0>, <&dmac_peri 1>;
> +		dma-names = "tx", "rx";
>  		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH 0>;
>  		reg-shift = <2>;
>  		reg-io-width = <4>;
> @@ -621,6 +623,8 @@ uart1: serial@...90000 {
>  		reg = <0x0 0xff190000 0x0 0x100>;
>  		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
>  		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac_peri 2>, <&dmac_peri 3>;
> +		dma-names = "tx", "rx";
>  		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH 0>;
>  		reg-shift = <2>;
>  		reg-io-width = <4>;
> @@ -634,6 +638,8 @@ uart2: serial@...a0000 {
>  		reg = <0x0 0xff1a0000 0x0 0x100>;
>  		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
>  		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac_peri 4>, <&dmac_peri 5>;
> +		dma-names = "tx", "rx";
>  		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH 0>;
>  		reg-shift = <2>;
>  		reg-io-width = <4>;
> @@ -647,6 +653,8 @@ uart3: serial@...b0000 {
>  		reg = <0x0 0xff1b0000 0x0 0x100>;
>  		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
>  		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac_peri 6>, <&dmac_peri 7>;
> +		dma-names = "tx", "rx";
>  		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH 0>;
>  		reg-shift = <2>;
>  		reg-io-width = <4>;
> @@ -1142,6 +1150,8 @@ uart4: serial@...70000 {
>  		reg = <0x0 0xff370000 0x0 0x100>;
>  		clocks = <&pmucru SCLK_UART4_PMU>, <&pmucru PCLK_UART4_PMU>;
>  		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac_peri 8>, <&dmac_peri 9>;
> +		dma-names = "tx", "rx";
>  		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH 0>;
>  		reg-shift = <2>;
>  		reg-io-width = <4>;
>