[PATCH 00/11] Enable I2S support for RK3588/RK3588S SoCs
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(-)
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 cristian.ciocaltea@collabora.com --- 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
+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.
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...
Thanks, Cristian
On Fri, Mar 17, 2023 at 4:59 AM Cristian Ciocaltea cristian.ciocaltea@collabora.com 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 3/17/23 16:27, Rob Herring wrote:
On Fri, Mar 17, 2023 at 4:59 AM Cristian Ciocaltea cristian.ciocaltea@collabora.com 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
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 cristian.ciocaltea@collabora.com --- .../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
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 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 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 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 expectedA 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 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 expectedA 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 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
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 cristian.ciocaltea@collabora.com --- 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
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 cristian.ciocaltea@collabora.com
Documentation/devicetree/bindings/sound/everest,es8316.yaml | 4 ++++ 1 file changed, 4 insertions(+)
Acked-by: Rob Herring robh@kernel.org
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 cristian.ciocaltea@collabora.com --- 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
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 cristian.ciocaltea@collabora.com
Documentation/devicetree/bindings/sound/rockchip-i2s.yaml | 4 ++++ 1 file changed, 4 insertions(+)
Acked-by: Rob Herring robh@kernel.org
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 cristian.ciocaltea@collabora.com --- 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:
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 cristian.ciocaltea@collabora.com
Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml | 4 ++++ 1 file changed, 4 insertions(+)
Acked-by: Rob Herring robh@kernel.org
The binding document is missing the power-domains property. Add it.
Signed-off-by: Cristian Ciocaltea cristian.ciocaltea@collabora.com --- 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:
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 cristian.ciocaltea@collabora.com
Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml | 3 +++ 1 file changed, 3 insertions(+)
Acked-by: Rob Herring robh@kernel.org
Add new compatible string for the Rockchip I2S/PCM controller found on RK3588 and RK3588S SoCs.
Signed-off-by: Cristian Ciocaltea cristian.ciocaltea@collabora.com --- 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
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 cristian.ciocaltea@collabora.com
Documentation/devicetree/bindings/sound/rockchip-i2s.yaml | 1 + 1 file changed, 1 insertion(+)
Acked-by: Rob Herring robh@kernel.org
The Rockchip I2S driver supports the RK3588/RK3588S SoCs, hence add the corresponding compatible string.
Signed-off-by: Cristian Ciocaltea cristian.ciocaltea@collabora.com --- 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", }, {}, };
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 cristian.ciocaltea@collabora.com --- 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 */
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 cristian.ciocaltea@collabora.com --- 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>;
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 cristian.ciocaltea@collabora.com --- .../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>; + }; + }; +};
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
participants (6)
-
Conor Dooley -
Cristian Ciocaltea -
Krzysztof Kozlowski -
Mark Brown -
Rob Herring -
Sudeep Holla