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
ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed #3388
ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed #3388
Conversation
active_streams = hda_dsp_check_for_dma_streams(sdev); | ||
|
||
sdev->system_suspend_target = SOF_SUSPEND_S3; | ||
ret = snd_sof_suspend(sdev->dev); |
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.
@ranj063 had a comment ealrlier #3377 (comment)
what if this fails? static checkers will complain that 'ret' is overwritten before being used in some cases.
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.
I'd prefer to keep going. If the DMA state is still running after failed suspend attempt, that will block system entry to S5.
But hmm, static checker could complain about it, so let me add another variable.
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.
Thank you for reviews, wlll update.
active_streams = hda_dsp_check_for_dma_streams(sdev); | ||
|
||
sdev->system_suspend_target = SOF_SUSPEND_S3; | ||
ret = snd_sof_suspend(sdev->dev); |
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.
I'd prefer to keep going. If the DMA state is still running after failed suspend attempt, that will block system entry to S5.
But hmm, static checker could complain about it, so let me add another variable.
If system shutdown has not been completed cleanly, it is possible the DMA stream shutdown has not been done, or was not clean. If this is the case, Intel TGL/ADL HDA platforms may fail to shutdown cleanly due to pending HDA DMA transactions. To avoid this, detect this scenario in the shutdown callback, and perform an additional controller reset. This has been tested to unblock S5 entry if this condition is hit. Co-developed-by: Archana Patni <archana.patni@intel.com> Signed-off-by: Archana Patni <archana.patni@intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
252cff3
to
380b0c7
Compare
A new version addressing comments so far. |
active_streams); | ||
ret2 = hda_dsp_s5_quirk(sdev); | ||
if (ret2 < 0) | ||
dev_err(sdev->dev, "shutdown recovery failed (%d)\n", ret2); |
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.
nitpick: but if ret was OK, but ret2 was not, then should we
if (!ret)
ret = ret2;
or does it matter at this point?
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.
@ujfalusi I'd say it doesn't matter at this point. The pci_driver driver ops has a void return type anyways.
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.
@kv2019i, I only have one nitpick, but no objection, looks nice.
More limited-scope-of-platforms version of #3377
If system shutdown has not been completed cleanly, it is possible the
DMA stream shutdown has not been done, or was not clean.
If this is the case, Intel TGL/ADL HDA platforms may fail to shutdown
cleanly due to pending HDA DMA transactions. To avoid this, detect this
scenario in the shutdown callback, and perform an additional controller
reset. This has been tested to unblock S5 entry if this condition is
hit.
Co-developed-by: Archana Patni archana.patni@intel.com
Signed-off-by: Archana Patni archana.patni@intel.com
Signed-off-by: Kai Vehmanen kai.vehmanen@linux.intel.com