@@ -296,7 +296,6 @@ sdio0: mmc@fe310000 {
<&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
- power-domains = <&power RK3399_PD_SDIOAUDIO>;
resets = <&cru SRST_SDIO0>;
reset-names = "reset";
status = "disabled";
@@ -794,7 +793,6 @@ spi5: spi@ff200000 {
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
- power-domains = <&power RK3399_PD_SDIOAUDIO>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
@@ -1102,12 +1100,6 @@ power-domain@RK3399_PD_SD {
pm_qos = <&qos_sd>;
#power-domain-cells = <0>;
};
- power-domain@RK3399_PD_SDIOAUDIO {
- reg = <RK3399_PD_SDIOAUDIO>;
- clocks = <&cru HCLK_SDIO>;
- pm_qos = <&qos_sdioaudio>;
- #power-domain-cells = <0>;
- };
power-domain@RK3399_PD_TCPD0 {
reg = <RK3399_PD_TCPD0>;
clocks = <&cru SCLK_UPHY0_TCPDCORE>,
@@ -1648,7 +1640,6 @@ spdif: spdif@ff870000 {
clocks = <&cru SCLK_SPDIF_8CH>, <&cru HCLK_SPDIF>;
pinctrl-names = "default";
pinctrl-0 = <&spdif_bus>;
- power-domains = <&power RK3399_PD_SDIOAUDIO>;
#sound-dai-cells = <0>;
status = "disabled";
};
@@ -1664,7 +1655,6 @@ i2s0: i2s@ff880000 {
clocks = <&cru SCLK_I2S0_8CH>, <&cru HCLK_I2S0_8CH>;
pinctrl-names = "default";
pinctrl-0 = <&i2s0_8ch_bus>;
- power-domains = <&power RK3399_PD_SDIOAUDIO>;
#sound-dai-cells = <0>;
status = "disabled";
};
@@ -1679,7 +1669,6 @@ i2s1: i2s@ff890000 {
clocks = <&cru SCLK_I2S1_8CH>, <&cru HCLK_I2S1_8CH>;
pinctrl-names = "default";
pinctrl-0 = <&i2s1_2ch_bus>;
- power-domains = <&power RK3399_PD_SDIOAUDIO>;
#sound-dai-cells = <0>;
status = "disabled";
};
@@ -1692,7 +1681,6 @@ i2s2: i2s@ff8a0000 {
dma-names = "tx", "rx";
clock-names = "i2s_clk", "i2s_hclk";
clocks = <&cru SCLK_I2S2_8CH>, <&cru HCLK_I2S2_8CH>;
- power-domains = <&power RK3399_PD_SDIOAUDIO>;
#sound-dai-cells = <0>;
status = "disabled";
};
This reverts commit b0f2110af8475bc6812287b6598161a2c1a34c61. (With some minor changes for context that have changed since then.) I've found that speaker and headphone audio have issues on RK3399 Gru Scarlet devices after commit: b0f2110af847 ("arm64: dts: rockchip: add SdioAudio pd control for rk3399"). It's likely somehow related to the fact that we completely reset VD_LOGIC in S3 suspend, which includes the SDIOAUDIO domain. Problematic test case: 1. play audio (e.g., youtube) through speakers 2. plug in headphones to 3.5mm jack (youtube remains playing) 3. suspend/resume the system (S3) 4. resume audio 5. unplug headphones (and resume audio) 6. plug headphones (youtube remains playing) At step 4, the audio sounds like garbage through the headphones (like every other sample is missing or stretched out, so it sounds like a screechy version on the original track?). At step 5, the speakers are silent. At step 6, the audio is garbage again. These problems go away if we stop managing this power domain and instead leave it on all the time. Power impact should be minimal. Signed-off-by: Brian Norris <briannorris@chromium.org> --- I don't really expect this patch to be merged as-is, but I want to put it up as a form of bug report and place to point people if they somehow have the same issue. I've poked around at the rockchip-i2s and codec drivers in use and have come up dry, to explain why audio breaks like this for me on kernels with commit b0f2110af847 involved. I don't plan on spending a lot more time on debugging this but instead am simply going to run with this patch in my kernels. If anyone has hot tips, I may be willing to spend a few cycles looking at alternatives though... arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ------------ 1 file changed, 12 deletions(-)