Fixup! ASoC: rt711-sdca: add GE selected mode control

[shumingfan]

This patch enables/disables the mic switch in manual mode.

[bardliao]

@fredoh9 Can you test this PR? Check if capture always work with the splitter.

[fredoh9]

Sure, I will check with this PR, let you know

[fredoh9]

Based on LNL PR test result https://sof-ci.01.org/linuxpr/PR4996/build2972/devicetest/index.html Looks very promising. But I see the same failure rate in JF device. Will check more.

[fredoh9]

I tested again with ba-lnlm-rvp-sdw-03, which was used for the PR test. 9/10 passed. One failure case, captured wave file has white noise (kind).

The other devices, jf-lnlm-rvp-sdw-1, ba-lnlm-rvp-sdw-01 are completely opposite. 1/10 passing rate. no different without this PR. While following/debugging the alsabat test results, I do see some device-specific difference also. but hard to explain this difference.

[fredoh9]

In same device, ba-lnlm-rvp-sdw-03. I compared dmesg between pass and fail. Not seen specific clue. Related with this PR, for failure case detected_mode=0x0 once, right after it became detected_mode=0x5. I checked other passed dmesg logs, don't see this toggling.

Pass case: dmesg_passed.txt

[   88.784248] kernel: soundwire_cadence:cdns_update_slave_status_work: soundwire_intel soundwire_intel.link.0: Slave status change: 0x40000000
[   88.785333] kernel: snd_soc_rt711_sdca:rt711_sdca_interrupt_callback: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_interrupt_callback control_port_stat=4, sdca_cascade=1
[   88.787015] kernel: soundwire_cadence:cdns_update_slave_status_work: soundwire_intel soundwire_intel.link.0: Slave status change: 0x20000000
[   88.819593] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x5
[   88.819597] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, jack_type=0x3
[   88.819598] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, btn_type=0x0
[   88.819599] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, scp_sdca_stat1=0x1, scp_sdca_stat2=0x0
[   89.722807] kernel: snd_sof_intel_hda_common:hda_dai_trigger: soundwire_intel soundwire_intel.link.0: cmd=0 dai SDW0 Pin3 direction 1

Failure case: dmesg_failed.txt

[   70.411232] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x0
[   70.411238] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, jack_type=0x0
[   70.411242] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, btn_type=0x0
[   70.411244] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, scp_sdca_stat1=0x1, scp_sdca_stat2=0x0
[   70.857304] kernel: snd_soc_rt711_sdca:rt711_sdca_interrupt_callback: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_interrupt_callback control_port_stat=4, sdca_cascade=1
[   70.893756] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x5
[   70.893779] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, jack_type=0x3
[   70.893789] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, btn_type=0x0
[   70.893796] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, scp_sdca_stat1=0x1, scp_sdca_stat2=0x0
[   70.896023] kernel: snd_soc_rt711_sdca:rt711_sdca_interrupt_callback: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_interrupt_callback control_port_stat=4, sdca_cascade=1
[   70.930851] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x5
[   70.930868] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, jack_type=0x3
[   70.930875] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, btn_type=0x0
[   70.930880] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, scp_sdca_stat1=0x1, scp_sdca_stat2=0x0
[   71.390864] kernel: snd_sof_intel_hda_common:hda_dai_trigger: soundwire_intel soundwire_intel.link.0: cmd=0 dai SDW0 Pin3 direction 1

[fredoh9]

with ba-lnlm-rvp-sdw-03, I tried 20 extra tests again it's 20/20, all passed. hmm, it shows solid passing rate. I will release the device and play with the other unstable DUTs.

[fredoh9]

With jf-lnlm-rvp-sdw-1, it passes now. I rebooted again, tested it from beginning. The result is fail - pass - pass - pass ..., 9/10 passing rate. After that keep passing, i didn't even count. I don't see any difference in dmesg between pass and fail. No detected_mode toggling in failure case.

[bardliao]

From https://github.com/thesofproject/linux/pull/4996#issuecomment-2113188409, [ 70.411232] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x0 [ 70.893756] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x5 [ 70.930851] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x5 It looks like a jack removal is detected. Can the jack socket have some issue?

[marc-hb]

It looks like a jack removal is detected. Can the jack socket have some issue?

Or, the LNL RVP board design put something too close to the jack which interferes...

EDIT: @fredoh9 do we really need to use the RVP's jack?

[marc-hb]

Or, the LNL RVP board design put something too close to the jack which interferes...

Sorry if this has been tried before; I lost track of all the experiments: has anyone already tried to run alsabat the other way round? Playing from this jack instead of recording.

In theory this should work while forcing to anything?

[bardliao]

In theory this should work while forcing to anything?

Yes, playback should work.

[marc-hb]

Yes, playback should work.

So if it doesn't or poorly, then maybe we have a smoking gun near that jack.

Testing playback removes the jack detection out the equation. AFAIK detection has always worked for playback, it has been flaky only for the microphone ring.

[plbossart]

@fredoh9 @marc-hb I don't think we've seen any alsa-bat playback issues reported? But yeah the removal is suspicious.

[plbossart]

With this patch the results are ok on ba-lnlm-rvp-sdw-03, see https://sof-ci.01.org/linuxpr/PR4996/build2972/devicetest/index.html

Let's try once more, I am tempted to merge blindly and see if the results improve.

[plbossart]

SOFCI TEST

[marc-hb]

Let's try once more, I am tempted to merge blindly and see if the results improve.

As long as it doesn't make anything worse then no one will complain.

[marc-hb]

Sorry if this has been tried before; I lost track of all the experiments: has anyone already tried to run alsabat the other way round? Playing from this jack instead of recording.

I got confused and assumed we were using the AIOC board for alsabat-playback. We never use the AIOC board for any alsabat test with LNL-SDW. We've always used the problematic, on-board jack always. And playback has been very reliable with that same jack; I know that much.

[plbossart]

merging, let's see what happens