Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TEST] SoundWire: check interrupts multiple times #4976

Conversation

plbossart
Copy link
Member

add a set of logs to make sure our interrupt sequences are done right on LNL

Link: #4943

Log what the interrupt enable state is.

we should merge this but there's no real merit in upstreaming this.

Link: thesofproject#4943
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Log what the interrupt enable state is.

we should merge this but there's no real merit in upstreaming this.

Link: thesofproject#4943
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
@plbossart plbossart marked this pull request as draft May 6, 2024 23:53
@plbossart plbossart changed the title [TEST] SoundWire: log interrupt enable disable [TEST] SoundWire: check interrupts multiple times May 7, 2024
@plbossart
Copy link
Member Author

wow, I did not expect the first test to report this:

https://sof-ci.01.org/linuxpr/PR4976/build2742/devicetest/index.html?model=LNLM_SDW_AIOC&testcase=verify-kernel-boot-log

[    5.709458] kernel: soundwire_intel soundwire_intel.link.3: New SoundWire interrupt signaled in 2nd pass!!
[    5.709699] kernel: soundwire_intel soundwire_intel.link.0: New SoundWire interrupt signaled in 2nd pass!!
[    5.709799] kernel: soundwire_intel soundwire_intel.link.1: New SoundWire interrupt signaled in 2nd pass!!
[    5.710110] kernel: soundwire_intel soundwire_intel.link.0: New SoundWire interrupt signaled in 2nd pass!!

But I guess it makes sense for enumeration... we first see a device0, then program its device_number N so we will see another interrupt when the device reports as deviceN

@plbossart plbossart force-pushed the sdw/log-interrupt-enable-disable branch from 069cbaa to c8c85f6 Compare May 7, 2024 16:26
Test the theory that some links can report an interrupt that is lost
if reported *after* the link is handled.

Add a second pass to re-check all links that have not been serviced in
the first pass. This filter is necessary as an interrupt will usually
generate a set of commands that are handled with, d'uh, interrupts.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
@plbossart plbossart force-pushed the sdw/log-interrupt-enable-disable branch from c8c85f6 to 15bffa8 Compare May 7, 2024 19:07
@plbossart
Copy link
Member Author

But I guess it makes sense for enumeration... we first see a device0, then program its device_number N so we will see another interrupt when the device reports as deviceN

Stupid me forgot that all commands are handled with interrupts, not just peripheral state changes. we need to filter and only deal with links not handled in the first pass.

@plbossart
Copy link
Member Author

not needed, interrupts are level based.

@plbossart plbossart closed this May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant