There are five I2S/PCM/TDM controllers and two I2S/PCM controllers embedded
in the RK3588 and RK3588S SoCs. Furthermore, RK3588 provides four additional
I2S/PCM/TDM controllers.
This patch series adds the required device tree nodes to support all the above.
Additionally, it enables analog audio support for the Rock 5B SBC, which has
been used to test both audio playback and recording.
Note that some of the DT bindings fixes in this series are not particularly
related to I2S, but are required for a proper dtbs_check validation.
Cristian Ciocaltea (11):
dt-bindings: firmware: arm,scmi: Document assigned-clocks and
assigned-clock-rates
dt-bindings: serial: snps-dw-apb-uart: Relax dma-names order
constraint
ASoC: dt-bindings: everest,es8316: Document audio graph port
ASoC: dt-bindings: rockchip: Document audio graph port
ASoC: dt-bindings: rockchip: i2s-tdm: Document audio graph port
ASoC: dt-bindings: rockchip: i2s-tdm: Document power-domains
ASoC: dt-bindings: rockchip: Add compatible for RK3588
ASoC: rockchip: i2s: Add compatible for RK3588
arm64: dts: rockchip: rk3588s: Add I2S nodes
arm64: dts: rockchip: rk3588: Add I2S nodes
arm64: dts: rockchip: rk3588-rock-5b: Add analog audio
.../bindings/firmware/arm,scmi.yaml | 3 +
.../bindings/serial/snps-dw-apb-uart.yaml | 10 +-
.../bindings/sound/everest,es8316.yaml | 4 +
.../bindings/sound/rockchip,i2s-tdm.yaml | 7 +
.../bindings/sound/rockchip-i2s.yaml | 5 +
.../boot/dts/rockchip/rk3588-rock-5b.dts | 62 ++++++++
arch/arm64/boot/dts/rockchip/rk3588.dtsi | 68 ++++++++
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 148 ++++++++++++++++++
sound/soc/rockchip/rockchip_i2s.c | 1 +
9 files changed, 305 insertions(+), 3 deletions(-)
--
2.39.1
Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
protocol child node properties") the following dtbs_check warning is
shown:
rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
Add the missing properties.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 2f7c51c75e85..10cc7ee46893 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -246,6 +246,9 @@ $defs:
Channel specifier required when using OP-TEE transport and
protocol has a dedicated communication channel.
+ assigned-clocks: true
+ assigned-clock-rates: true
+
required:
- reg
--
2.39.1
Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
dma-names properties") documented dma-names property to handle Allwiner
D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
the reverse of what a different board expects:
rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
A quick and incomplete check shows the inconsistency is present in many
other DT files:
$ git grep -A10 snps,dw-apb-uart | grep dma-names | sort -u
arch/arm64/boot/dts/rockchip/px30.dtsi- dma-names = "tx", "rx";
arch/arm64/boot/dts/rockchip/rk3328.dtsi- dma-names = "tx", "rx";
arch/arm64/boot/dts/rockchip/rk3588s.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rk3066a.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rk3128.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rk3288.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rv1126.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/socfpga.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/sun6i-a31.dtsi- dma-names = "rx", "tx";
arch/arm/boot/dts/sun8i-a23-a33.dtsi- dma-names = "rx", "tx";
arch/arm/boot/dts/sun8i-v3s.dtsi- dma-names = "rx", "tx";
arch/arm/boot/dts/sunxi-h3-h5.dtsi- dma-names = "rx", "tx";
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dma-names = "rx", "tx";
Do not enforce the order of the dma-names items.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
.../devicetree/bindings/serial/snps-dw-apb-uart.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index 2becdfab4f15..d374844a61a5 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -71,9 +71,13 @@ properties:
minItems: 2
dma-names:
- items:
- - const: rx
- - const: tx
+ oneOf:
+ - items:
+ - const: tx
+ - const: rx
+ - items:
+ - const: rx
+ - const: tx
snps,uart-16550-compatible:
description: reflects the value of UART_16550_COMPATIBLE configuration
--
2.39.1
The ES8316 codec is currently used in conjunction with audio-graph-card
to provide an endpoint for binding with the other side of the audio
link.
This is achieved via the 'port' property, which is not allowed:
rk3399-rockpro64.dtb: codec@11: Unevaluated properties are not allowed ('port' was unexpected)
Fix the issue by documenting the missing property.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
Documentation/devicetree/bindings/sound/everest,es8316.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/everest,es8316.yaml b/Documentation/devicetree/bindings/sound/everest,es8316.yaml
index d9f8f0c7f6bb..80cd81ecae6f 100644
--- a/Documentation/devicetree/bindings/sound/everest,es8316.yaml
+++ b/Documentation/devicetree/bindings/sound/everest,es8316.yaml
@@ -28,6 +28,10 @@ properties:
items:
- const: mclk
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
"#sound-dai-cells":
const: 0
--
2.39.1
The Rockchip I2S controller is currently used in conjunction with
audio-graph-card to provide an endpoint for binding with the other side
of the audio link.
This is achieved via the 'port' property, which is not allowed:
rk3399-rockpro64.dtb: i2s@ff890000: Unevaluated properties are not allowed ('port' was unexpected)
Fix the issue by documenting the missing property.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
Documentation/devicetree/bindings/sound/rockchip-i2s.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
index 1cb4da300607..c32b4750651c 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
@@ -82,6 +82,10 @@ properties:
resets:
maxItems: 2
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
rockchip,capture-channels:
$ref: /schemas/types.yaml#/definitions/uint32
default: 2
--
2.39.1
Document the 'port' property to allow the Rockchip I2S TDM controller to
be used in conjunction with the audio-graph-card.
The property will be used to provide an endpoint for binding to the
other side of the audio link.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
index 4c95895de75e..7d2c2991c566 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
@@ -86,6 +86,10 @@ properties:
- tx-m
- rx-m
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
--
2.39.1
The binding document is missing the power-domains property. Add it.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
index 7d2c2991c566..7bb6c5dff786 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
@@ -90,6 +90,9 @@ properties:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
+ power-domains:
+ maxItems: 1
+
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
--
2.39.1
The Rockchip I2S driver supports the RK3588/RK3588S SoCs, hence add the
corresponding compatible string.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
sound/soc/rockchip/rockchip_i2s.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index a8758ad68442..2e24cc0570eb 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -659,6 +659,7 @@ static const struct of_device_id rockchip_i2s_match[] __maybe_unused = {
{ .compatible = "rockchip,rk3366-i2s", },
{ .compatible = "rockchip,rk3368-i2s", },
{ .compatible = "rockchip,rk3399-i2s", .data = &rk3399_i2s_pins },
+ { .compatible = "rockchip,rk3588-i2s", },
{ .compatible = "rockchip,rv1126-i2s", },
{},
};
--
2.39.1
Add new compatible string for the Rockchip I2S/PCM controller found on
RK3588 and RK3588S SoCs.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
Documentation/devicetree/bindings/sound/rockchip-i2s.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
index c32b4750651c..fcb01abffa97 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
@@ -34,6 +34,7 @@ properties:
- rockchip,rk3366-i2s
- rockchip,rk3368-i2s
- rockchip,rk3399-i2s
+ - rockchip,rk3588-i2s
- rockchip,rv1126-i2s
- const: rockchip,rk3066-i2s
--
2.39.1
There are five I2S/PCM/TDM controllers and two I2S/PCM controllers
embedded in the RK3588 and RK3588S SoCs.
Add the DT nodes corresponding to the above mentioned Rockchip
controllers.
Also note RK3588 SoC contains four additional I2S/PCM/TDM controllers,
which are handled via a separate patch.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 148 ++++++++++++++++++++++
1 file changed, 148 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 005cde61b4b2..a137e3450bd6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -810,6 +810,57 @@ power-domain@RK3588_PD_SDMMC {
};
};
+ i2s4_8ch: i2s@fddc0000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfddc0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S4_8CH_TX>, <&cru MCLK_I2S4_8CH_TX>, <&cru HCLK_I2S4_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S4_8CH_TX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac2 0>;
+ dma-names = "tx";
+ power-domains = <&power RK3588_PD_VO0>;
+ resets = <&cru SRST_M_I2S4_8CH_TX>;
+ reset-names = "tx-m";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s5_8ch: i2s@fddf0000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfddf0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S5_8CH_TX>, <&cru MCLK_I2S5_8CH_TX>, <&cru HCLK_I2S5_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S5_8CH_TX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac2 2>;
+ dma-names = "tx";
+ power-domains = <&power RK3588_PD_VO1>;
+ resets = <&cru SRST_M_I2S5_8CH_TX>;
+ reset-names = "tx-m";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s9_8ch: i2s@fddfc000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfddfc000 0x0 0x1000>;
+ interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S9_8CH_RX>, <&cru MCLK_I2S9_8CH_RX>, <&cru HCLK_I2S9_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S9_8CH_RX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac2 23>;
+ dma-names = "rx";
+ power-domains = <&power RK3588_PD_VO1>;
+ resets = <&cru SRST_M_I2S9_8CH_RX>;
+ reset-names = "rx-m";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
qos_gpu_m0: qos@fdf35000 {
compatible = "rockchip,rk3588-qos", "syscon";
reg = <0x0 0xfdf35000 0x0 0x20>;
@@ -1117,6 +1168,103 @@ sdhci: mmc@fe2e0000 {
status = "disabled";
};
+ i2s0_8ch: i2s@fe470000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfe470000 0x0 0x1000>;
+ interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S0_8CH_TX>, <&cru MCLK_I2S0_8CH_RX>, <&cru HCLK_I2S0_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S0_8CH_TX_SRC>, <&cru CLK_I2S0_8CH_RX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>, <&cru PLL_AUPLL>;
+ dmas = <&dmac0 0>, <&dmac0 1>;
+ dma-names = "tx", "rx";
+ power-domains = <&power RK3588_PD_AUDIO>;
+ resets = <&cru SRST_M_I2S0_8CH_TX>, <&cru SRST_M_I2S0_8CH_RX>;
+ reset-names = "tx-m", "rx-m";
+ rockchip,trcm-sync-tx-only;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0_lrck
+ &i2s0_sclk
+ &i2s0_sdi0
+ &i2s0_sdi1
+ &i2s0_sdi2
+ &i2s0_sdi3
+ &i2s0_sdo0
+ &i2s0_sdo1
+ &i2s0_sdo2
+ &i2s0_sdo3>;
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s1_8ch: i2s@fe480000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfe480000 0x0 0x1000>;
+ interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S1_8CH_TX>, <&cru MCLK_I2S1_8CH_RX>, <&cru HCLK_I2S1_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ dmas = <&dmac0 2>, <&dmac0 3>;
+ dma-names = "tx", "rx";
+ resets = <&cru SRST_M_I2S1_8CH_TX>, <&cru SRST_M_I2S1_8CH_RX>;
+ reset-names = "tx-m", "rx-m";
+ rockchip,trcm-sync-tx-only;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_lrck
+ &i2s1m0_sclk
+ &i2s1m0_sdi0
+ &i2s1m0_sdi1
+ &i2s1m0_sdi2
+ &i2s1m0_sdi3
+ &i2s1m0_sdo0
+ &i2s1m0_sdo1
+ &i2s1m0_sdo2
+ &i2s1m0_sdo3>;
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s2_2ch: i2s@fe490000 {
+ compatible = "rockchip,rk3588-i2s", "rockchip,rk3066-i2s";
+ reg = <0x0 0xfe490000 0x0 0x1000>;
+ interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S2_2CH>, <&cru HCLK_I2S2_2CH>;
+ clock-names = "i2s_clk", "i2s_hclk";
+ assigned-clocks = <&cru CLK_I2S2_2CH_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac1 0>, <&dmac1 1>;
+ dma-names = "tx", "rx";
+ power-domains = <&power RK3588_PD_AUDIO>;
+ rockchip,trcm-sync-tx-only;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s2m1_lrck
+ &i2s2m1_sclk
+ &i2s2m1_sdi
+ &i2s2m1_sdo>;
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s3_2ch: i2s@fe4a0000 {
+ compatible = "rockchip,rk3588-i2s", "rockchip,rk3066-i2s";
+ reg = <0x0 0xfe4a0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S3_2CH>, <&cru HCLK_I2S3_2CH>;
+ clock-names = "i2s_clk", "i2s_hclk";
+ assigned-clocks = <&cru CLK_I2S3_2CH_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac1 2>, <&dmac1 3>;
+ dma-names = "tx", "rx";
+ power-domains = <&power RK3588_PD_AUDIO>;
+ rockchip,trcm-sync-tx-only;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s3_lrck
+ &i2s3_sclk
+ &i2s3_sdi
+ &i2s3_sdo>;
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@fe600000 {
compatible = "arm,gic-v3";
reg = <0x0 0xfe600000 0 0x10000>, /* GICD */
--
2.39.1
Add the necessary DT nodes for the Rock 5B board to enable the analog
audio support provided by the Everest Semi ES8316 codec.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
.../boot/dts/rockchip/rk3588-rock-5b.dts | 62 +++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
index 95805cb0adfa..945eac304766 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
@@ -2,6 +2,7 @@
/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
#include "rk3588.dtsi"
/ {
@@ -25,6 +26,59 @@ vcc5v0_sys: vcc5v0-sys-regulator {
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
+
+ sound {
+ compatible = "audio-graph-card";
+ label = "Analog";
+
+ widgets = "Microphone", "Mic Jack",
+ "Headphone", "Headphones";
+
+ routing = "MIC2", "Mic Jack",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR";
+
+ dais = <&i2s0_8ch_p0>;
+ hp-det-gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+
+ es8316: es8316@11 {
+ compatible = "everest,es8316";
+ reg = <0x11>;
+ clocks = <&cru I2S0_8CH_MCLKOUT>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+
+ port {
+ es8316_p0_0: endpoint {
+ remote-endpoint = <&i2s0_8ch_p0_0>;
+ };
+ };
+ };
+};
+
+&i2s0_8ch {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0_lrck
+ &i2s0_mclk
+ &i2s0_sclk
+ &i2s0_sdi0
+ &i2s0_sdo0>;
+ status = "okay";
+
+ i2s0_8ch_p0: port {
+ i2s0_8ch_p0_0: endpoint {
+ dai-format = "i2s";
+ mclk-fs = <256>;
+ remote-endpoint = <&es8316_p0_0>;
+ };
+ };
};
&sdhci {
@@ -42,3 +96,11 @@ &uart2 {
pinctrl-0 = <&uart2m0_xfer>;
status = "okay";
};
+
+&pinctrl {
+ sound {
+ hp_detect: hp-detect {
+ rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
--
2.39.1
In addition to the five I2S/PCM/TDM controllers and the two I2S/PCM
controllers shared between the RK3588 and RK3588S SoCs, RK3588 contains
another four I2S/PCM/TDM controllers.
Add the DT nodes corresponding to the additional controllers.
Signed-off-by: Cristian Ciocaltea <[email protected]>
---
arch/arm64/boot/dts/rockchip/rk3588.dtsi | 68 ++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588.dtsi b/arch/arm64/boot/dts/rockchip/rk3588.dtsi
index d085e57fbc4c..8be75556af8f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588.dtsi
@@ -7,6 +7,74 @@
#include "rk3588-pinctrl.dtsi"
/ {
+ i2s8_8ch: i2s@fddc8000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfddc8000 0x0 0x1000>;
+ interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S8_8CH_TX>, <&cru MCLK_I2S8_8CH_TX>, <&cru HCLK_I2S8_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S8_8CH_TX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac2 22>;
+ dma-names = "tx";
+ power-domains = <&power RK3588_PD_VO0>;
+ resets = <&cru SRST_M_I2S8_8CH_TX>;
+ reset-names = "tx-m";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s6_8ch: i2s@fddf4000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfddf4000 0x0 0x1000>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S6_8CH_TX>, <&cru MCLK_I2S6_8CH_TX>, <&cru HCLK_I2S6_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S6_8CH_TX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac2 4>;
+ dma-names = "tx";
+ power-domains = <&power RK3588_PD_VO1>;
+ resets = <&cru SRST_M_I2S6_8CH_TX>;
+ reset-names = "tx-m";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s7_8ch: i2s@fddf8000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfddf8000 0x0 0x1000>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S7_8CH_RX>, <&cru MCLK_I2S7_8CH_RX>, <&cru HCLK_I2S7_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S7_8CH_RX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac2 21>;
+ dma-names = "rx";
+ power-domains = <&power RK3588_PD_VO1>;
+ resets = <&cru SRST_M_I2S7_8CH_RX>;
+ reset-names = "rx-m";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
+ i2s10_8ch: i2s@fde00000 {
+ compatible = "rockchip,rk3588-i2s-tdm";
+ reg = <0x0 0xfde00000 0x0 0x1000>;
+ interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru MCLK_I2S10_8CH_RX>, <&cru MCLK_I2S10_8CH_RX>, <&cru HCLK_I2S10_8CH>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ assigned-clocks = <&cru CLK_I2S10_8CH_RX_SRC>;
+ assigned-clock-parents = <&cru PLL_AUPLL>;
+ dmas = <&dmac2 24>;
+ dma-names = "rx";
+ power-domains = <&power RK3588_PD_VO1>;
+ resets = <&cru SRST_M_I2S10_8CH_RX>;
+ reset-names = "rx-m";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
gmac0: ethernet@fe1b0000 {
compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";
reg = <0x0 0xfe1b0000 0x0 0x10000>;
--
2.39.1
+Stephen
On Wed, Mar 15, 2023 at 01:47:56PM +0200, Cristian Ciocaltea wrote:
> Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
> protocol child node properties") the following dtbs_check warning is
> shown:
>
> rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
I think that's a somewhat questionable use of assigned-clock-rates. It
should be located with the consumer rather than the provider IMO. The
consumers of those 2 clocks are the CPU nodes.
Rob
On Thu, Mar 16, 2023 at 03:34:17PM -0500, Rob Herring wrote:
> +Stephen
>
> On Wed, Mar 15, 2023 at 01:47:56PM +0200, Cristian Ciocaltea wrote:
> > Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
> > protocol child node properties") the following dtbs_check warning is
> > shown:
> >
> > rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
>
> I think that's a somewhat questionable use of assigned-clock-rates. It
> should be located with the consumer rather than the provider IMO. The
> consumers of those 2 clocks are the CPU nodes.
>
Agreed. We definitely don't use those in the scmi clk provider driver.
So NACK for the generic SCMI binding change.
--
Regards,
Sudeep
On 15/03/2023 12:47, Cristian Ciocaltea wrote:
> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
> dma-names properties") documented dma-names property to handle Allwiner
> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
> the reverse of what a different board expects:
>
> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
>
> A quick and incomplete check shows the inconsistency is present in many
> other DT files:
Why not fixing the DTS? The properties should have fixed order.
Best regards,
Krzysztof
On 3/17/23 00:26, Sudeep Holla wrote:
> On Thu, Mar 16, 2023 at 03:34:17PM -0500, Rob Herring wrote:
>> +Stephen
>>
>> On Wed, Mar 15, 2023 at 01:47:56PM +0200, Cristian Ciocaltea wrote:
>>> Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
>>> protocol child node properties") the following dtbs_check warning is
>>> shown:
>>>
>>> rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
>>
>> I think that's a somewhat questionable use of assigned-clock-rates. It
>> should be located with the consumer rather than the provider IMO. The
>> consumers of those 2 clocks are the CPU nodes.
>>
>
> Agreed. We definitely don't use those in the scmi clk provider driver.
> So NACK for the generic SCMI binding change.
According to [1], "configuration of common clocks, which affect multiple
consumer devices can be similarly specified in the clock provider node".
That would avoid duplicating assigned-clock-rates in the CPU nodes.
[1]
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/clock/clock.yaml
Thanks,
Cristian
On 3/17/23 10:31, Krzysztof Kozlowski wrote:
> On 15/03/2023 12:47, Cristian Ciocaltea wrote:
>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
>> dma-names properties") documented dma-names property to handle Allwiner
>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
>> the reverse of what a different board expects:
>>
>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
>>
>> A quick and incomplete check shows the inconsistency is present in many
>> other DT files:
>
> Why not fixing the DTS? The properties should have fixed order.
I was initially concerned about the risk of a potential ABI breakage,
but I think that's not really a problem since dma-names is not directly
accessed in the driver and DT Kernel API doesn't rely on a particular order.
If there are no objections, I would switch the order in the binding to
tx->rx, since that's what most of the DTS use, and fix the remaining ones.
> Best regards,
> Krzysztof
Thanks,
Cristian
On Fri, Mar 17, 2023 at 4:59 AM Cristian Ciocaltea
<[email protected]> wrote:
>
> On 3/17/23 00:26, Sudeep Holla wrote:
> > On Thu, Mar 16, 2023 at 03:34:17PM -0500, Rob Herring wrote:
> >> +Stephen
> >>
> >> On Wed, Mar 15, 2023 at 01:47:56PM +0200, Cristian Ciocaltea wrote:
> >>> Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
> >>> protocol child node properties") the following dtbs_check warning is
> >>> shown:
> >>>
> >>> rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
> >>
> >> I think that's a somewhat questionable use of assigned-clock-rates. It
> >> should be located with the consumer rather than the provider IMO. The
> >> consumers of those 2 clocks are the CPU nodes.
> >>
> >
> > Agreed. We definitely don't use those in the scmi clk provider driver.
> > So NACK for the generic SCMI binding change.
>
> According to [1], "configuration of common clocks, which affect multiple
> consumer devices can be similarly specified in the clock provider node".
True, but in this case it's really a single consumer because it's all
CPU nodes which are managed together.
> That would avoid duplicating assigned-clock-rates in the CPU nodes.
Wouldn't one node be sufficient?
Thinking more about this, why aren't you using OPP tables to define
CPU frequencies. Assigned-clocks looks like a temporary hack because
you haven't done proper OPP tables.
Rob
On 17/03/2023 11:21, Cristian Ciocaltea wrote:
> On 3/17/23 10:31, Krzysztof Kozlowski wrote:
>> On 15/03/2023 12:47, Cristian Ciocaltea wrote:
>>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
>>> dma-names properties") documented dma-names property to handle Allwiner
>>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
>>> the reverse of what a different board expects:
>>>
>>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
>>>
>>> A quick and incomplete check shows the inconsistency is present in many
>>> other DT files:
>>
>> Why not fixing the DTS? The properties should have fixed order.
>
> I was initially concerned about the risk of a potential ABI breakage,
> but I think that's not really a problem since dma-names is not directly
> accessed in the driver and DT Kernel API doesn't rely on a particular order.
>
> If there are no objections, I would switch the order in the binding to
> tx->rx, since that's what most of the DTS use, and fix the remaining ones.
Since we added the order recently, I rather assume it is the correct or
preferred one.
Best regards,
Krzysztof
On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote:
> On 17/03/2023 11:21, Cristian Ciocaltea wrote:
> > On 3/17/23 10:31, Krzysztof Kozlowski wrote:
> >> On 15/03/2023 12:47, Cristian Ciocaltea wrote:
> >>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
> >>> dma-names properties") documented dma-names property to handle Allwiner
> >>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
> >>> the reverse of what a different board expects:
> >>>
> >>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
> >>>
> >>> A quick and incomplete check shows the inconsistency is present in many
> >>> other DT files:
> >>
> >> Why not fixing the DTS? The properties should have fixed order.
> >
> > I was initially concerned about the risk of a potential ABI breakage,
> > but I think that's not really a problem since dma-names is not directly
> > accessed in the driver and DT Kernel API doesn't rely on a particular order.
> >
> > If there are no objections, I would switch the order in the binding to
> > tx->rx, since that's what most of the DTS use, and fix the remaining ones.
>
> Since we added the order recently, I rather assume it is the correct or
> preferred one.
IIRC I checked around the other serial bindings & there was not a
consistent order that all serial bindings used, so I picked the order that
was used across the various allwinner boards that do use dma-names.
Before changing dts files, it's probably a good idea to make sure that
the dma-names are not used somewhere outside of Linux.
Cheers,
Conor.
On 3/17/23 16:27, Rob Herring wrote:
> On Fri, Mar 17, 2023 at 4:59 AM Cristian Ciocaltea
> <[email protected]> wrote:
>>
>> On 3/17/23 00:26, Sudeep Holla wrote:
>>> On Thu, Mar 16, 2023 at 03:34:17PM -0500, Rob Herring wrote:
>>>> +Stephen
>>>>
>>>> On Wed, Mar 15, 2023 at 01:47:56PM +0200, Cristian Ciocaltea wrote:
>>>>> Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
>>>>> protocol child node properties") the following dtbs_check warning is
>>>>> shown:
>>>>>
>>>>> rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
>>>>
>>>> I think that's a somewhat questionable use of assigned-clock-rates. It
>>>> should be located with the consumer rather than the provider IMO. The
>>>> consumers of those 2 clocks are the CPU nodes.
>>>>
>>>
>>> Agreed. We definitely don't use those in the scmi clk provider driver.
>>> So NACK for the generic SCMI binding change.
>>
>> According to [1], "configuration of common clocks, which affect multiple
>> consumer devices can be similarly specified in the clock provider node".
>
> True, but in this case it's really a single consumer because it's all
> CPU nodes which are managed together.
>
>> That would avoid duplicating assigned-clock-rates in the CPU nodes.
>
> Wouldn't one node be sufficient?
Yeah, that should be fine.
> Thinking more about this, why aren't you using OPP tables to define
> CPU frequencies. Assigned-clocks looks like a temporary hack because
> you haven't done proper OPP tables.
Right, this is currently not possible since it depends on some work in
progress.
Thanks,
Cristian
On 3/17/23 18:26, Conor Dooley wrote:
> On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote:
>> On 17/03/2023 11:21, Cristian Ciocaltea wrote:
>>> On 3/17/23 10:31, Krzysztof Kozlowski wrote:
>>>> On 15/03/2023 12:47, Cristian Ciocaltea wrote:
>>>>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
>>>>> dma-names properties") documented dma-names property to handle Allwiner
>>>>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
>>>>> the reverse of what a different board expects:
>>>>>
>>>>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
>>>>>
>>>>> A quick and incomplete check shows the inconsistency is present in many
>>>>> other DT files:
>>>>
>>>> Why not fixing the DTS? The properties should have fixed order.
>>>
>>> I was initially concerned about the risk of a potential ABI breakage,
>>> but I think that's not really a problem since dma-names is not directly
>>> accessed in the driver and DT Kernel API doesn't rely on a particular order.
>>>
>>> If there are no objections, I would switch the order in the binding to
>>> tx->rx, since that's what most of the DTS use, and fix the remaining ones.
>>
>> Since we added the order recently, I rather assume it is the correct or
>> preferred one.
>
> IIRC I checked around the other serial bindings & there was not a
> consistent order that all serial bindings used, so I picked the order that
> was used across the various allwinner boards that do use dma-names.
Thanks for clarifying this, Conor! Would it be fine to switch to tx->rx
order as it requires less changes to fix the inconsistencies?
> Before changing dts files, it's probably a good idea to make sure that
> the dma-names are not used somewhere outside of Linux.
Right, that means we cannot exclude the ABI breakage concern. Not sure
how easy would be to actually verify this. Hence I wonder if there is
really no chance to allow the flexible order in the binding..
> Cheers,
> Conor
On Fri, Mar 17, 2023 at 12:21:41PM +0200, Cristian Ciocaltea via Alsa-devel wrote:
> Date: Fri, 17 Mar 2023 12:21:41 +0200
> From: Cristian Ciocaltea <[email protected]>
> To: Krzysztof Kozlowski <[email protected]>, Sudeep Holla
> <[email protected]>, Cristian Marussi <[email protected]>, Rob
> Herring <[email protected]>, Krzysztof Kozlowski
> <[email protected]>, Greg Kroah-Hartman
> <[email protected]>, Liam Girdwood <[email protected]>, Mark
> Brown <[email protected]>, Nicolas Frattaroli
> <[email protected]>, Heiko Stuebner <[email protected]>, Jaroslav
> Kysela <[email protected]>, Takashi Iwai <[email protected]>, Paul Walmsley
> <[email protected]>, Palmer Dabbelt <[email protected]>, Albert Ou
> <[email protected]>, Daniel Drake <[email protected]>, Katsuhiro
> Suzuki <[email protected]>
> CC: [email protected], [email protected],
> [email protected], [email protected],
> [email protected], [email protected],
> [email protected], [email protected]
> Subject: Re: [PATCH 02/11] dt-bindings: serial: snps-dw-apb-uart: Relax
> dma-names order constraint
> Message-ID: <[email protected]>
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
> Thunderbird/102.7.2
There is something strange going on with your mails as there are 2
copies in the archives with the 2nd one getting the header twice. It's
coming from the alsa-devel list.
>
> On 3/17/23 10:31, Krzysztof Kozlowski wrote:
> > On 15/03/2023 12:47, Cristian Ciocaltea wrote:
> > > Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
> > > dma-names properties") documented dma-names property to handle Allwiner
> > > D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
> > > the reverse of what a different board expects:
> > >
> > > rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
> > >
> > > A quick and incomplete check shows the inconsistency is present in many
> > > other DT files:
> >
> > Why not fixing the DTS? The properties should have fixed order.
>
> I was initially concerned about the risk of a potential ABI breakage, but I
> think that's not really a problem since dma-names is not directly accessed
> in the driver and DT Kernel API doesn't rely on a particular order.
>
> If there are no objections, I would switch the order in the binding to
> tx->rx, since that's what most of the DTS use, and fix the remaining ones.
>
> > Best regards,
> > Krzysztof
>
> Thanks,
> Cristian
On Wed, 15 Mar 2023 13:47:58 +0200, Cristian Ciocaltea wrote:
> The ES8316 codec is currently used in conjunction with audio-graph-card
> to provide an endpoint for binding with the other side of the audio
> link.
>
> This is achieved via the 'port' property, which is not allowed:
>
> rk3399-rockpro64.dtb: codec@11: Unevaluated properties are not allowed ('port' was unexpected)
>
> Fix the issue by documenting the missing property.
>
> Signed-off-by: Cristian Ciocaltea <[email protected]>
> ---
> Documentation/devicetree/bindings/sound/everest,es8316.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Acked-by: Rob Herring <[email protected]>
On Wed, 15 Mar 2023 13:48:00 +0200, Cristian Ciocaltea wrote:
> Document the 'port' property to allow the Rockchip I2S TDM controller to
> be used in conjunction with the audio-graph-card.
>
> The property will be used to provide an endpoint for binding to the
> other side of the audio link.
>
> Signed-off-by: Cristian Ciocaltea <[email protected]>
> ---
> Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Acked-by: Rob Herring <[email protected]>
On Wed, 15 Mar 2023 13:48:01 +0200, Cristian Ciocaltea wrote:
> The binding document is missing the power-domains property. Add it.
>
> Signed-off-by: Cristian Ciocaltea <[email protected]>
> ---
> Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Rob Herring <[email protected]>
On Wed, 15 Mar 2023 13:48:02 +0200, Cristian Ciocaltea wrote:
> Add new compatible string for the Rockchip I2S/PCM controller found on
> RK3588 and RK3588S SoCs.
>
> Signed-off-by: Cristian Ciocaltea <[email protected]>
> ---
> Documentation/devicetree/bindings/sound/rockchip-i2s.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <[email protected]>
On Fri, Mar 17, 2023 at 07:43:53PM +0200, Cristian Ciocaltea wrote:
> On 3/17/23 18:26, Conor Dooley wrote:
> > On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote:
> > > On 17/03/2023 11:21, Cristian Ciocaltea wrote:
> > > > On 3/17/23 10:31, Krzysztof Kozlowski wrote:
> > > > > On 15/03/2023 12:47, Cristian Ciocaltea wrote:
> > > > > > Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
> > > > > > dma-names properties") documented dma-names property to handle Allwiner
> > > > > > D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
> > > > > > the reverse of what a different board expects:
> > > > > >
> > > > > > rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
> > > > > >
> > > > > > A quick and incomplete check shows the inconsistency is present in many
> > > > > > other DT files:
> > > > >
> > > > > Why not fixing the DTS? The properties should have fixed order.
> > > >
> > > > I was initially concerned about the risk of a potential ABI breakage,
> > > > but I think that's not really a problem since dma-names is not directly
> > > > accessed in the driver and DT Kernel API doesn't rely on a particular order.
> > > >
> > > > If there are no objections, I would switch the order in the binding to
> > > > tx->rx, since that's what most of the DTS use, and fix the remaining ones.
> > >
> > > Since we added the order recently, I rather assume it is the correct or
> > > preferred one.
> >
> > IIRC I checked around the other serial bindings & there was not a
> > consistent order that all serial bindings used, so I picked the order that
> > was used across the various allwinner boards that do use dma-names.
>
> Thanks for clarifying this, Conor! Would it be fine to switch to tx->rx
> order as it requires less changes to fix the inconsistencies?
>
> > Before changing dts files, it's probably a good idea to make sure that
> > the dma-names are not used somewhere outside of Linux.
>
> Right, that means we cannot exclude the ABI breakage concern. Not sure how
> easy would be to actually verify this. Hence I wonder if there is really no
> chance to allow the flexible order in the binding..
If it changes and someone complains, then yes we'll allow flexible
order.
Rob
On Wed, 15 Mar 2023 13:47:59 +0200, Cristian Ciocaltea wrote:
> The Rockchip I2S controller is currently used in conjunction with
> audio-graph-card to provide an endpoint for binding with the other side
> of the audio link.
>
> This is achieved via the 'port' property, which is not allowed:
>
> rk3399-rockpro64.dtb: i2s@ff890000: Unevaluated properties are not allowed ('port' was unexpected)
>
> Fix the issue by documenting the missing property.
>
> Signed-off-by: Cristian Ciocaltea <[email protected]>
> ---
> Documentation/devicetree/bindings/sound/rockchip-i2s.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Acked-by: Rob Herring <[email protected]>
On Mon, Mar 20, 2023 at 10:58:12AM -0500, Rob Herring wrote:
> On Fri, Mar 17, 2023 at 12:21:41PM +0200, Cristian Ciocaltea via Alsa-devel wrote:
> > dma-names order constraint
> > Message-ID: <[email protected]>
> > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
> > Thunderbird/102.7.2
> There is something strange going on with your mails as there are 2
> copies in the archives with the 2nd one getting the header twice. It's
> coming from the alsa-devel list.
This is probably caused by alsa-devel, it'll be mailman rewriting bits
of the message. There's stuff coming up with other people's mails too.
On Wed, 15 Mar 2023 13:47:55 +0200, Cristian Ciocaltea wrote:
> There are five I2S/PCM/TDM controllers and two I2S/PCM controllers embedded
> in the RK3588 and RK3588S SoCs. Furthermore, RK3588 provides four additional
> I2S/PCM/TDM controllers.
>
> This patch series adds the required device tree nodes to support all the above.
>
> Additionally, it enables analog audio support for the Rock 5B SBC, which has
> been used to test both audio playback and recording.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[03/11] ASoC: dt-bindings: everest,es8316: Document audio graph port
commit: 2f43ef99ac623b6d9154c26d4f6785df18b4d8e4
[04/11] ASoC: dt-bindings: rockchip: Document audio graph port
commit: bf4062b7420d01b4fafd7211fd2dc68b916591bd
[05/11] ASoC: dt-bindings: rockchip: i2s-tdm: Document audio graph port
commit: bfbae373c55e3b1c15a6ba656211dbbe7c390aa1
[06/11] ASoC: dt-bindings: rockchip: i2s-tdm: Document power-domains
commit: 9971f3358338950d9d3345184fb2c0cfc6fc8552
[07/11] ASoC: dt-bindings: rockchip: Add compatible for RK3588
commit: b0fe6a91fa9d5599ba3cace2748906e086c5a56e
[08/11] ASoC: rockchip: i2s: Add compatible for RK3588
commit: 0e6c37610934e9b91f6f5f2599de5e2f1ab59e72
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
On 3/20/23 18:01, Rob Herring wrote:
> On Fri, Mar 17, 2023 at 07:43:53PM +0200, Cristian Ciocaltea wrote:
>> On 3/17/23 18:26, Conor Dooley wrote:
>>> On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote:
>>>> On 17/03/2023 11:21, Cristian Ciocaltea wrote:
>>>>> On 3/17/23 10:31, Krzysztof Kozlowski wrote:
>>>>>> On 15/03/2023 12:47, Cristian Ciocaltea wrote:
>>>>>>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
>>>>>>> dma-names properties") documented dma-names property to handle Allwiner
>>>>>>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
>>>>>>> the reverse of what a different board expects:
>>>>>>>
>>>>>>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
>>>>>>>
>>>>>>> A quick and incomplete check shows the inconsistency is present in many
>>>>>>> other DT files:
>>>>>>
>>>>>> Why not fixing the DTS? The properties should have fixed order.
>>>>>
>>>>> I was initially concerned about the risk of a potential ABI breakage,
>>>>> but I think that's not really a problem since dma-names is not directly
>>>>> accessed in the driver and DT Kernel API doesn't rely on a particular order.
>>>>>
>>>>> If there are no objections, I would switch the order in the binding to
>>>>> tx->rx, since that's what most of the DTS use, and fix the remaining ones.
>>>>
>>>> Since we added the order recently, I rather assume it is the correct or
>>>> preferred one.
>>>
>>> IIRC I checked around the other serial bindings & there was not a
>>> consistent order that all serial bindings used, so I picked the order that
>>> was used across the various allwinner boards that do use dma-names.
>>
>> Thanks for clarifying this, Conor! Would it be fine to switch to tx->rx
>> order as it requires less changes to fix the inconsistencies?
>>
>>> Before changing dts files, it's probably a good idea to make sure that
>>> the dma-names are not used somewhere outside of Linux.
>>
>> Right, that means we cannot exclude the ABI breakage concern. Not sure how
>> easy would be to actually verify this. Hence I wonder if there is really no
>> chance to allow the flexible order in the binding..
>
> If it changes and someone complains, then yes we'll allow flexible
> order.
I looked a bit further and it seems the allwiner boards are not really
affected as all of them are using the same DMA channel for both rx and
tx. So we should be fine by switching to tx->rx order.
$ git grep -A10 snps,dw-apb-uart | grep 'sun.*dmas' | sort -u
arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 10>, <&dma 10>;
arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 22>, <&dma 22>;
arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 6>, <&dma 6>;
arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 7>, <&dma 7>;
arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 8>, <&dma 8>;
arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 9>, <&dma 9>;
arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 10>, <&dma 10>;
arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 6>, <&dma 6>;
arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 7>, <&dma 7>;
arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 8>, <&dma 8>;
arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 9>, <&dma 9>;
arch/arm/boot/dts/sun8i-v3s.dtsi- dmas = <&dma 6>, <&dma 6>;
arch/arm/boot/dts/sun8i-v3s.dtsi- dmas = <&dma 7>, <&dma 7>;
arch/arm/boot/dts/sun8i-v3s.dtsi- dmas = <&dma 8>, <&dma 8>;
arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 6>, <&dma 6>;
arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 7>, <&dma 7>;
arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 8>, <&dma 8>;
arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 9>, <&dma 9>;
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 14>,
<&dma 14>;
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 15>,
<&dma 15>;
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 16>,
<&dma 16>;
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 17>,
<&dma 17>;
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 18>,
<&dma 18>;
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 19>,
<&dma 19>;
Thanks,
Cristian