soundwire: intel_bus_common: enable interrupts before exiting reset

[plbossart]

The existing code enables the Cadence IP interrupts after the bus reset sequence. The problem with this sequence is that it might be pre-empted, giving SoundWire devices time to sync and report as ATTACHED before the interrupts are enabled. In that case, the Cadence IP will not detect a state change and will not throw an interrupt to proceed with the enumeration of a Device0.

In our overnight stress tests, we observed that a slight sub-millisecond delay in enabling interrupts after the reset was correlated with detection failures. This problem is more prevalent on the LunarLake silicon, likely due to SOC integration changes, but it was observed on earlier generations as well.

This patch reverts the sequence, with the interrupts enabled before performing the bus reset. This removes the race condition and makes sure the Cadence IP is able to detect the presence of a Device0 in all cases.

[marc-hb]

multiple-pause-resume failed on all LNL models in https://sof-ci.01.org/linuxpr/PR5106/build4026/devicetest/index.html

At least one of the failures looks like #5109 which I just filed.

Everything else is either passing or missing.

[marc-hb]

SOFCI TEST

[plbossart]

@marc-hb we can ignore the pause/release issues, this isn't related to this PR at all. What is changed here is the SoundWire bus startup, it will only be influenced by pm_runtime transitions.

[plbossart]

@bardliao can you take this PR and let it run overnight on your device to see if this confirms my results that we don't see the enumeration issue?

[bardliao]

@bardliao can you take this PR and let it run overnight on your device to see if this confirms my results that we don't see the enumeration issue?

I can only run the test on a CI device as I work remotely this week. Currently all LNLM_SDW_AIOC devices are reserved. I will check if I can reserve one later.

[plbossart]

don't worry about it @bardliao I'll run a test myself then. We can re-run more tests next week.

[bardliao]

I ran a test last night, it passed 853 iterations before my network disconnected. I am running another test now.

[bardliao]

I didn't get "Peripheral 0" error, but got NACK. It failed at the 19th iteration

===========================>>
[  453.786241] kernel: soundwire_intel soundwire_intel.link.0: Msg NACK received, cmd 2
[  453.786426] kernel: soundwire_intel soundwire_intel.link.0: Msg NACKed for Slave 0
[  453.786447] kernel: soundwire sdw-master-0-0: trf on Slave 0 failed:-5 read addr 50 count 6
[  453.786529] kernel: soundwire sdw-master-0-0: DEVID read fail:-5
<<===========================

log2.txt

[plbossart]

NACK means the command isn't accepted by the Peripheral, that's usually a sign of low-level electrical issues.

But it's also possible that by enabling interrupts earlier, we might get some weird signals on the bus and then the interrupt and command channels might be disrupted.

So we should retry and see if this happens again... I was hoping to merge this quickly but that's a red flag.

[bardliao]

I retested and it passed more than 1500 iterations.

[plbossart]

ok let's merge then and see what happens. We can always revert.

[plbossart]

Humm let's redo the tests first, we seem to have a regression on CML? https://sof-ci.01.org/linuxpr/PR5106/build4064/devicetest/index.html?model=CML_RVP_SDW-ipc3&testcase=multiple-pipeline-all

[plbossart]

SOFCI TEST

[plbossart]

the CML problem didn't re-occur, let's merge then and see what the daily tests show

[marc-hb]

Humm let's redo the tests first, we seem to have a regression on CML?

Only if you count a bug filed in 2021 as a "regression" :-D

• [SoundWire] intel_resume: MCP_CONTROL_HW_RST not cleared at iteration (dev_err logs) #3012

[bardliao]

BTW, I am still running the test on a LNLM_SDW_AIOC device. It passed more than 1950 iterations so far. I will stop it before off work today.

[bardliao]

It passed more than 2500 iterations. I will stop here and release the device.