PGA X.Y switches - value inconsistency

[perexg]

I am trying remotely debug an issue where the PGA2.0 2 Master Capture Switch value is off (0) for the user space after boot, but the rt715-sdca microphone is working until the saved (value is off) state is restored. It seems that the kcontrol value is not updated to the DSP state when the driver is booted.

I'm looking to the driver, the scontrol->comp_data_dirty in ipc3-control.c seems to be set only when DSP notifies driver using IPC to do so..

May I ask to give me a light, how the initial value is obtained from (synced with) the DSP?

Related UCM change: https://github.com/alsa-project/alsa-ucm-conf/commit/b856040ab9f3eb0380014959f91ca13afe33a067 . I think that this problem was not visible before this change.

[plbossart]

@juimonen @ranj063 can you help?

I am not sure there's any initial state in the DSP. When the DSP firmware boots, it has no knowledge of such controls. It's only when a pipeline is created with the topology that these controls become meaningful.

[ranj063]

@plbossart @perexg there is no initial state for kcontrols in the DSP. But when the driver loads and the topology is parsed, we set the default values for the mixer controls and it seems like the switch controls would have a default value of 0. So when the pipeline is created, this default value will be updated for the kcontrol in the DSP

[perexg]

Thanks. But it's not observed behavior with the affected user on Dell SKU 0C11 - rt715-scda microphone chip.

1) First boot - microphone works, but when the ALSA kcontrols are stored to /var/lib/alsa/asound.state the PGA2.0 2 Master Capture Switch values are off. So the DSP path works although it should not from your comments.

2) Next boot - the state file is restored - microphone does not work until the PGA2.0 2 Master Capture Switch is turned on manually.

It's with the 6.0.18 kernel (plus RaptorLake/SDW patches) and also the user tested Fedora kernel before 14-days (I think 6.1 or so). I would appreciate, if you can test similar hw for this.

But based on the comments, the UCM boot sequence to set the PGA2.0 2 Master Capture Switch is missing for this platform ?

[plbossart]

@perexg We should never use the SOF PGA controls for rt715, this is not good at all. The UCM files need to use the codec controls. Didn't we talk about this for the LED issue?

[plbossart]

Put differently, the ONLY case where the use of SOF PGA is required is for HDAudio+DMIC platforms. There's no DMIC codec so the only controls are at the SOF level.

[perexg]

It would be perfect, but the user reports that the microphone is working only when:

1) first boot when the PGA2.0 2 Master Capture Switch is not touched by UCM, but reported by the driver as off 2) when the PGA2.0 2 Master Capture Switch is manually set to on

I'm trying to isolate the possible bug. If we should not take care in UCM, then it would be the best way.

[plbossart]

Isn't this the same issue as https://github.com/alsa-project/alsa-ucm-conf/pull/261 ?

[perexg]

Maybe. So PGA kcontrols should not control any active path for soundwire ? It seems that on/off/volume values affect the active (used) digital mixer part in the graph. The problem with UCM is that the applications should set the analog elements in the graph instead the digital elements.

[perexg]

Basically, digital routes should be on + 0dB volume when the analog on/off/volume controls are available.

[perexg]

@ranj063 :

But when the driver loads and the topology is parsed, we set the default values for the mixer controls and it seems like the switch controls would have a default value of 0. So when the pipeline is created, this default value will be updated for the kcontrol in the DSP

I cannot confirm. The path is activated from the cold boot for RT715.

I updated my test sdw machine with rt715 and did some tests:

1) first boot - all ok (in my case PGA5.0 5 Master Capture Switch is not touched, amixer says 'off,off') 2) second boot - microphone is silent (PGA5.0 5 Master Capture Switch restored to 'off,off')

The issue is really reproducible with the cold boot and disabled ALSA state management + pipewire, script/commands:

# omit ALSA state management and wireplumber (pipewire)
#mv /usr/sbin/alsactl /usr/sbin/alsactl1
#mv /usr/bin/wireplumber /usr/bin/wireplumber1
#poweroff

# from the clean cold boot - no UCM, no alsactl, no pipewire
# enable RT715
amixer -c sofsoundwire cset name='rt715 ADC 24 Mux' DMIC3
amixer -c sofsoundwire cset name='rt715 ADC 25 Mux' DMIC4
amixer -c sofsoundwire cset name='rt715 Capture Switch' on,on,on,on,on,on,on,on
amixer -c sofsoundwire cset name='rt715 DMIC3 Boost' 2
amixer -c sofsoundwire cset name='rt715 DMIC4 Boost' 2

# show PGA switches
IFS=$'\n' ; for a in $(amixer -c sofsoundwire controls | grep PGA | grep Switch); do
  name=$(echo $a | cut -d "'" -f 2)
  amixer -c sofsoundwire cget "name='$name'";
done

# really turn off PGA
#amixer -c sofsoundwire cset "name='PGA5.0 5 Master Capture Switch'" off,off

If I rename alsactl and wireplumber, do a cold reboot, initialize ONLY RT715 registers, the PGA controlled mixer path is active (although the driver says opposite):

numid=55,iface=MIXER,name='PGA5.0 5 Master Capture Switch'
  ; type=BOOLEAN,access=rw------,values=2
  : values=off,off

...

arecord -f dat -Dhw:sofsoundwire,4 -vvv a.wav
...
Max peak (8192 samples): 0x0000000f #                    0%
Max peak (8192 samples): 0x0000001f #                    0%
Max peak (8192 samples): 0x00000035 #                    0%

and now - DUPLICATE SET:

amixer -c sofsoundwire cset "name='PGA5.0 5 Master Capture Switch'" off,off

...

arecord -f dat -Dhw:sofsoundwire,4 -vvv a.wav
...
Max peak (8192 samples): 0x00000000 #                    0%
Max peak (8192 samples): 0x00000000 #                    0%
Max peak (8192 samples): 0x00000000 #                    0%

SOF FW: 2.2.4, kernel 6.1.11.

Where I can find the switch initialization in the current driver code ? The volume is set to 0dB in sof_ipc3_control_load_volume() but the switch state is not handled at all there (and the switch condition should be 'min == 0 && max == 1' not only 'max == 1' in this function).

[perexg]

I'd like point that this is a SERIOUS / CRITICAL issue. If you need any other co-operation from me, let me know.

[plbossart]

Sorry for being quiet @perexg, we have a number of folks either super-busy or away, No one is ignoring this issue, it's just a bandwidth overflow at the moment. Thanks for your understanding.

[perexg]

Seems related: https://bugzilla.redhat.com/show_bug.cgi?id=2188802