ARM: dts: rockchip: Add dmac_bus rx and tx for uart2
Subsystems (2)
PATCH 1/1 ARM: dts: rockchip: Add dmac_bus rx and tx for uart2
This removes warning "ttyS2 - Failed to request dma" from kernel logs
--- arch/arm/boot/dts/rk3288.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/boot/dts/rk3288.dtsi +2 -0
@@ -385,6 +385,8 @@ clock-names = "baudclk", "apb_pclk"; pinctrl-names = "default"; pinctrl-0 = <&uart2_xfer>; + dmas = <&dmac_bus_s 4>, <&dmac_bus_s 5>; + dma-names = "tx", "rx"; status = "disabled"; };
Signature · 1 line
1.9.1
Heiko Stuebner
maintainerPATCH 1/1 ARM: dts: rockchip: Add dmac_bus rx and tx for uart2
Hi,
Am Montag, 15. Juni 2015, 17:47:48 schrieb Romain Perier:
Quoted 12 lines
This removes warning "ttyS2 - Failed to request dma" from kernel logs
Signed-off-by Romain Perier <[email protected]>--- arch/arm/boot/dts/rk3288.dtsi | 2 ++ 1 file changed, 2 insertions(+)arch/arm/boot/dts/rk3288.dtsi +0
-0
arch/arm/boot/dts/rk3288.dtsi line 391
Quoted 7 lines
arch/arm/boot/dts/rk3288.dtsi +2
-0@@ -385,6 +385,8 @@ clock-names = "baudclk", "apb_pclk"; pinctrl-names = "default"; pinctrl-0 = <&uart2_xfer>; + dmas = <&dmac_bus_s 4>, <&dmac_bus_s 5>; + dma-names = "tx", "rx"; status = "disabled"; };
The dma channels are a property of the hardware, so we probably should add them for all uarts in one go, instead of everytime something complains :-)
in dmac_peri
uart0: tx 1, rx 2
uart1: tx 3, rx 4
uart3: tx 7, rx 8
uart4: tx 9, rx 10
Just for the record and if anybody is interested to work in this, we have an issue with the dma implementation [0] that is not yet solved upstream. From what I've remember, that mostly got triggered on higher speeds, like higher spi-speeds or i2s audio stuff (poping).
Heiko
PATCH 1/1 ARM: dts: rockchip: Add dmac_bus rx and tx for uart2
Hi,
Quoted 10 lines · Heiko Stuebner
Just for the record and if anybody is interested to work in this, we have an issue with the dma implementation [0] that is not yet solved upstream. From what I've remember, that mostly got triggered on higher speeds, like higher spi-speeds or i2s audio stuff (poping).
Heiko
Right. In the ChromeOS tree (used for rk3288-based Chromebooks) we think we solved the DMA issues for the most part by using burst mode. ...but we weren't brave enough to enable DMA for SPI and UART because we didn't want to track down any additional weird issues and PIO mode was working well enough.
The full list of things I see in the PL330 driver in ChromeOS:
3e12510 CHROMIUM: dmaengine: pl330: add quirk for broken no flushp ded3780 CHROMIUM: dmaengine: pl330: support quirks for some broken 7af450f FROMLIST: DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit
Skimming through the i2s driver (which we definitely use with DMA):
21fee4b CHROMIUM: ASoC: rockchip_i2s: modify DMA max burst to 1 4001251 UPSTREAM: ASoC: rockchip: i2s: fix maxburst of dma data to 4
...I was only peripherally involved here, but as you can see it looks like there were not only changes needed to the PL330 driver but also changes needed to the DMA client.
You can find links to patches from the same git tree that Heiko pointed at.