[TGL] runtime PM always in active on TGL chromebook/I2S mode

Describe the bug
We found this issue on TGL chromebook and only happens with I2S mode. looks like there’s a dependency between SDW driver and runtime PM. if no SDW drivers loaded, runtime PM will always be active.
I also tried to disable SDW in kconfig, but got same results.

To Reproduce
Check runtime PM status when sof is idle for more than 3 seconds.

$cat /sys/bus/pci/devices/0000\:00\:1f.3/power/runtime_status

Reproduction Rate
10/10

Expected behavior
runtime PM will be suspended after sof is idle for more than 3 seconds.

Environment
Driver: fce7f93 + #1971 + https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-next&id=914f674bec6efe42f9d6b036850a618fd1698290
Firmware:
SOF branch: tgl-005-drop-stable Commit: 277a9717
TPLG: sof-tgl-max98373-rt5682.tplg

dmesg.txt
logger.txt

@keqiaozhang

@keqiaozhang please revisit this. If you still have an issue without SoundWire support, then it's not an issue due to SoundWire.

@keqiaozhang

@keqiaozhang please revisit this. If you still have an issue without SoundWire support, then it's not an issue due to SoundWire.

The interesting thing is that I have 2 TGL Chromebook, these TGL devices support both I2S codec(RT5682I+MAX98373) and SDW codec(RT5682+MAX98373), since coreboot is not yet supported, so we need to override the acpi table for both codecs.
On device-1. we only overrode the acpi table for I2S codec.
On device-2, we overrode the acpi table for both I2S and SDW codecs.
Both devices are connected with I2S codec. then I found that with same kernel(with or without SoundWire support), runtime PM always failed to suspend on device-1 but works well on device-2.

@keqiaozhang

@keqiaozhang I am not able to parse your description, sorry. can you please use terms like

configuration a): rt5682 in I2S mode, MAX.. in I2S mode, pointer to acpi override table, results.
configuration b),...

thanks

@plbossart

@plbossart I'm sorry to confuse you.
I will try to make this issue clearly.
First, we found this issue in 5.6.0-rc6+, because latest sof-dev has a regression, kernel 5.7.0 failed to boot on chrome device. please refer to issue #2063.

Let's back to this issue. I did some debugging today and found that this issue only related to DSM, if we set the max98373 codec to feedback mode for DSM pipelines , then runtime PM will always be active. @keyonjie is doing further debugging.

@keqiaozhang

@keqiaozhang @keyonjie There was a know issue on KBL where the team had to play with the speaker pin to let the amplifier suspend when DSM was used.

@sathya-nujella does this ring a bell?

@keqiaozhang

@keqiaozhang @keyonjie There was a know issue on KBL where the team had to play with the speaker pin to let the amplifier suspend when DSM was used.

@sathya-nujella does this ring a bell?

KBL issue was there, but it was related to loading of DSM parameters from UCM.
But here in Kequiao's test, it is not UCM.. so not sure same.. but issue details and UCM fix for our reference:

Soraka: Move DSM param loading to Speaker Enable

Loading DSM params from Default Enable prevented
audio pci device from entering RTD3.
Moved the DSM param loading loagically to the speaker
enable section. This ensures Audio device enters RTD3
https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/930346/

@plbossart

Thanks for sharing @plbossart @sathya-nujella, that's really good information, looks the speaker switch is the culprit, I am working on understand how it impact to the PCI device.

@sathyap-chrome

Adding @sathyap-chrome

So this is actually the expected behavior, we need to add setting/clearing the switch "Left/Right Spk Switch" to the Speaker enable/disable sequence to fix this.

So this is actually the expected behavior, we need to add setting/clearing the switch "Left/Right Spk Switch" to the Speaker enable/disable sequence to fix this.

where would we add this? In the past it was added in the machine driver so that we wouldn't be adding more things in UCM.

The following mixer settings can be set to off before the SPK playback and will be turned on when the usecase TRIGGER_START happens.
amixer -c0 cset name='Left Spk Switch' off
amixer -c0 cset name='Right Spk Switch' off
Following patch fixes the runtime issue:
#2123

Tested with #2123 on tgl chromebook/i2s mode, runtime pm still always in active. And the default Left/Right Spk Switch value is on. then i tried to turn them off manually, the pm runtime can be in suspended status.

dmesg.log

Tested with #2123 on tgl chromebook/i2s mode, runtime pm still always in active. And the default Left/Right Spk Switch value is on. then i tried to turn them on manually, the pm runtime can be in suspended status.

dmesg.log

Yvonne, have you removed below amixer settings from shell script or UCM file?
amixer -c0 cset name='Left Spk Switch' off
amixer -c0 cset name='Right Spk Switch' off

Verified #2123 again. Behaviors as below: Pusleaudio is already disabled.

boot up system, runtime PM keeps active.
"Left Spk Switch" and "Right Spk Switch" is on, amixer is here
amixerContents.txt
Trigger headset playback and stop to check, headset audio output works ok. But runtime PM keeps active,
Trigger 373-spk playabck and stop to check, runtime PM auto enter suspended successfully.
Trigger headset playback again, Headset audio output quality is very bad (1 channel output both 2 channels output, and the sound is harsh), but runtime PM can auto enter suspended after stop stream. Amixer contents is here
amixerContents_afterRuntimePmSuspend.txt
dmesg and sof logger as below:
dmesg.txt
full_soflogger_afterPMsuspended.txt

Difference except "Left Spk Switch" and "Right Spk Switch" is as below:
numid=83,iface=MIXER,name='Left ADC PVDD' is changed from 0 t 183
numid=84,iface=MIXER,name='Left ADC TEMP' is changed from 0 to 49
numid=27,iface=MIXER,name='Right ADC PVDD' is changed form 0 to 183
numid=28,iface=MIXER,name='Right ADC TEMP' is changed from 0 to 49
And can't set back to 0 via cset. No any message in dmesg when run cset

ubuntu@TGL-Volteer-01:~/pmlog$ amixer cset numid=83,iface=MIXER,name='Left ADC PVDD' 0
numid=83,iface=MIXER,name='Left ADC PVDD'
  ; type=INTEGER,access=rw------,values=1,min=0,max=255,step=0
  : values=183
ubuntu@TGL-Volteer-01:~/pmlog$ amixer cset numid=84 0
numid=84,iface=MIXER,name='Left ADC TEMP'
  ; type=INTEGER,access=rw------,values=1,min=0,max=255,step=0
  : values=49

No difference for 5682 register, check via /sys/kernel/debug/regmap/i2c-10EC5682:00/registers
afterboot log was caught after above step1, which runtime PM always active, and headset output is good.
after373playback log was caught after above step3, which runtime PM works ok and headset output got issue
Loopback headset output audio are in
headset_output.zip

5682_register_afterboot.txt
5682_register_afterboot_afterheadsetplayback.txt
5682_register_after373playback.txt
5682_register_after373playback_afterheadsetplayback.txt
5682_register_after373_duringheadsetplayback.txt
5682_register_afterboot_duringheadsetplayback.txt

@ClarexZhou

Thanks for the detail information @ClarexZhou .
@RDharageswari I think you have tested this on Chrome environment, can you provide UCM file then we can port it to Ubuntu and align for the testing?

Verified #2123 again. Behaviors as below: Pusleaudio is already disabled.

boot up system, runtime PM keeps active.
"Left Spk Switch" and "Right Spk Switch" is on, amixer is here
amixerContents.txt

Trigger headset playback and stop to check, headset audio output works ok. But runtime PM keeps active,

Trigger 373-spk playabck and stop to check, runtime PM auto enter suspended successfully.

Trigger headset playback again, Headset audio output quality is very bad (1 channel output both 2 channels output, and the sound is harsh), but runtime PM can auto enter suspended after stop stream. Amixer contents is here
amixerContents_afterRuntimePmSuspend.txt
dmesg and sof logger as below:
dmesg.txt
full_soflogger_afterPMsuspended.txt

Difference except "Left Spk Switch" and "Right Spk Switch" is as below:
numid=83,iface=MIXER,name='Left ADC PVDD' is changed from 0 t 183
numid=84,iface=MIXER,name='Left ADC TEMP' is changed from 0 to 49
numid=27,iface=MIXER,name='Right ADC PVDD' is changed form 0 to 183
numid=28,iface=MIXER,name='Right ADC TEMP' is changed from 0 to 49
And can't set back to 0 via cset. No any message in dmesg when run cset
ubuntu@TGL-Volteer-01:~/pmlog$ amixer cset numid=83,iface=MIXER,name='Left ADC PVDD' 0
numid=83,iface=MIXER,name='Left ADC PVDD'
  ; type=INTEGER,access=rw------,values=1,min=0,max=255,step=0
  : values=183
ubuntu@TGL-Volteer-01:~/pmlog$ amixer cset numid=84 0
numid=84,iface=MIXER,name='Left ADC TEMP'
  ; type=INTEGER,access=rw------,values=1,min=0,max=255,step=0
  : values=49

Tested it latest topic/sof-dev(d8ac95a) as #2123 was merged, same behavior as above.

@YvonneYang2

@YvonneYang2 @ClarexZhou those mixers are for maxim98373 read only registers, that's why you can't 'set' them.

The headset output issue isn't related with below mixers after runtime PM works.
numid=83,iface=MIXER,name='Left ADC PVDD'
numid=84,iface=MIXER,name='Left ADC TEMP'
numid=27,iface=MIXER,name='Right ADC PVDD'
numid=28,iface=MIXER,name='Right ADC TEMP'

There is one time i tried steps in #2053 (comment), above mixers are not changed after runtime PM works and headset output still got issue.
afterboot log was caught after system boot up, which runtime PM always active, and headset output is good.
after373playback log was caught after 373 playback, which runtime PM works ok and headset output got issue
5682_register_afterboot_duringheadsetplayback.txt
amixer_afterboot.txt
amxier_after373play.txt
dmesg.txt
5682_register_after373_duringheadsetplayback.txt

Split headset audio output issue and track in #2190

The spk switch is restored by alsactrl in user mode. Please disable it in /var/lib/alsa/asound.state

        control.121 {
                iface MIXER
                name 'Left Spk Switch'
                value false
                comment {
                        access 'read write'
                        type BOOLEAN
                        count 1
                }
        }
        control.122 {
                iface MIXER
                name 'Right Spk Switch'
                value false
                comment {
                        access 'read write'
                        type BOOLEAN
                        count 1
                }
        }

Runtime PM works ok after changed in /var/lib/alsa/asound.state

Close issue

Navigation Menu

Repository navigation

[TGL] runtime PM always in active on TGL chromebook/I2S mode #2053

KBL issue was there, but it was related to loading of DSM parameters from UCM.
But here in Kequiao's test, it is not UCM.. so not sure same.. but issue details and UCM fix for our reference:

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[TGL] runtime PM always in active on TGL chromebook/I2S mode #2053

Description

Activity

plbossart commented on Apr 27, 2020

keqiaozhang commented on Apr 28, 2020

plbossart commented on Apr 28, 2020

keqiaozhang commented on Apr 29, 2020

plbossart commented on Apr 29, 2020

sathya-nujella commented on Apr 29, 2020

KBL issue was there, but it was related to loading of DSM parameters from UCM. But here in Kequiao's test, it is not UCM.. so not sure same.. but issue details and UCM fix for our reference:

keyonjie commented on Apr 30, 2020

naveen-manohar commented on Apr 30, 2020

keyonjie commented on Apr 30, 2020

plbossart commented on Apr 30, 2020

7 remaining items

RDharageswari commented on May 15, 2020

YvonneYang2 commented on Jun 2, 2020

keyonjie commented on Jun 2, 2020

ClarexZhou commented on Jun 2, 2020

keyonjie commented on Jun 2, 2020

YvonneYang2 commented on Jun 9, 2020

keyonjie commented on Jun 10, 2020

ClarexZhou commented on Jun 11, 2020

ClarexZhou commented on Jun 12, 2020

RanderWang commented on Jun 15, 2020

ClarexZhou commented on Jun 16, 2020

ClarexZhou commented on Jun 16, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

KBL issue was there, but it was related to loading of DSM parameters from UCM.
But here in Kequiao's test, it is not UCM.. so not sure same.. but issue details and UCM fix for our reference: