forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 140
ASoC: SOF: Intel: Retry codec probing if it fails #3255
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bardliao
previously approved these changes
Nov 3, 2021
Collaborator
bardliao
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
plbossart
reviewed
Nov 3, 2021
kv2019i
reviewed
Nov 3, 2021
kv2019i
previously approved these changes
Nov 9, 2021
Collaborator
kv2019i
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the conclusions in discussion 545d7ec#r745535189 , I think this is the best way to address this problem now.
plbossart
requested changes
Nov 10, 2021
On the latest Lenovo Thinkstation laptops, we often experience the speaker failure after rebooting, check the dmesg, we could see: sof-audio-pci-intel-tgl 0000:00:1f.3: codec #0 probe error, ret: -5 The analogue codec on the machine is ALC287, then we designed a testcase to reboot and check the codec probing result repeatedly, we found the analogue codec probing always failed at least once within several minutes to several hours (roughly 1 reboot per min). This issue happens on all laptops of this Thinkstation model, but with legacy HDA driver, we couldn't reproduce this issue on those laptops. And so far, this issue is not reproduced on machines which don't belong to this model. We tried to make the hda_dsp_ctrl_init_chip() same as hda_intel_init_chip() which is the controller init routine in the legacy HDA driver, but it didn't help. We found when issue happens, the resp is -1, and if we let driver re-run send_cmd() and get_response(), it will get the correct response 10ec0287, then driver continues the rest work, finally boot to the desktop and all audio function work well. Here adding codec probing retries to 3 times, it could fix the issue on this Thinkstation model, and it doesn't bring impact to other machines. Reviewed-by: Bard Liao <bard.liao@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hui Wang <hui.wang@canonical.com>
545d7ec to
99f5411
Compare
plbossart
approved these changes
Nov 11, 2021
kv2019i
approved these changes
Nov 11, 2021
marc-hb
added a commit
to marc-hb/sof-test
that referenced
this pull request
Feb 18, 2022
Now that the test has been just fixed in commit 71a9cca, of course it started failing: https://sof-ci.01.org/sofpr/PR5383/build12069/devicetest/?model=BYT_MB_NOCODEC&testcase=check-kmod-load-unload-after-playback This proves the older version wasn't testing anything: classic case of "green failure" https://github.com/thesofproject/sof-test/issues?q=+label%3A%22False+Pass+%2F+green+failure%22+ Firmware does not boot instantly. We even have retries: thesofproject/linux#3255 thesofproject/linux@2a3c9269474c So, poll journalctl for a maximum of 5 seconds before failing. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb
added a commit
to marc-hb/sof-test
that referenced
this pull request
Feb 18, 2022
Now that the test has been just fixed in commit 71a9cca, of course it started failing: https://sof-ci.01.org/sofpr/PR5383/build12069/devicetest/?model=BYT_MB_NOCODEC&testcase=check-kmod-load-unload-after-playback This proves the older version wasn't testing anything: classic case of "green failure" https://github.com/thesofproject/sof-test/issues?q=+label%3A%22False+Pass+%2F+green+failure%22+ Firmware does not boot instantly. We even have retries for when it fails: thesofproject/linux#3255 thesofproject/linux@2a3c9269474c So, poll journalctl for a maximum of 5 seconds before failing. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb
added a commit
to marc-hb/sof-test
that referenced
this pull request
Feb 18, 2022
Now that the test has been just fixed in commit 71a9cca, of course it started failing: https://sof-ci.01.org/sofpr/PR5383/build12069/devicetest/?model=BYT_MB_NOCODEC&testcase=check-kmod-load-unload-after-playback This proves the older version wasn't testing anything: classic case of "green failure" https://github.com/thesofproject/sof-test/issues?q=+label%3A%22False+Pass+%2F+green+failure%22+ Firmware does not boot instantly. We even have retries for when it fails: thesofproject/linux#3255 thesofproject/linux@2a3c9269474c So, poll journalctl for a maximum of 10 seconds before failing. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb
added a commit
to thesofproject/sof-test
that referenced
this pull request
Feb 23, 2022
Now that the test has been just fixed in commit 71a9cca, of course it started failing: https://sof-ci.01.org/sofpr/PR5383/build12069/devicetest/?model=BYT_MB_NOCODEC&testcase=check-kmod-load-unload-after-playback This proves the older version wasn't testing anything: classic case of "green failure" https://github.com/thesofproject/sof-test/issues?q=+label%3A%22False+Pass+%2F+green+failure%22+ Firmware does not boot instantly. We even have retries for when it fails: thesofproject/linux#3255 thesofproject/linux@2a3c9269474c So, poll journalctl for a maximum of 10 seconds before failing. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On the latest Lenovo Thinkstation laptops, we often experience the
speaker failure after rebooting, check the dmesg, we could see:
sof-audio-pci-intel-tgl 0000:00:1f.3: codec #0 probe error, ret: -5
The analogue codec on the machine is ALC287, then we designed a
testcase to reboot and check the codec probing result repeatedly, we
found the analogue codec probing always failed at least once within
several minutes to several hours (roughly 1 reboot per min). This
issue happens on all laptops of this Thinkstation model, but with
legacy HDA driver, we couldn't reproduce this issue on those laptops.
And so far, this issue is not reproduced on machines which don't
belong to this model.
We tried to make the hda_dsp_ctrl_init_chip() same as
hda_intel_init_chip() which is the controller init routine in the
legacy HDA driver, but it didn't help.
We found when issue happens, the resp is -1, and if we let driver
re-run send_cmd() and get_response(), it will get the correct response
10ec0287, then driver continues the rest work, finally boot to the
desktop and all audio function work well.
Here adding codec probing retries to 3 times, it could fix the issue
on this Thinkstation model, and it doesn't bring impact to other
machines.
Signed-off-by: Hui Wang hui.wang@canonical.com