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
[SDW] clock stop prepare failed: -61 #2621
Comments
Most registers in log are related to widget's properties, the only one I suspect is "3501 <= xxxx" operation, it's a audio power state control, not sure if the COMMAND_IGNORED is caused by this? But I reviewed previous log, the same operation didn't cause the COMMAND_IGNORED response. |
@jack-cy-yu in theory the power controls should have no impact on the SoundWire interface, and a COMMAND_IGNORED can only be generated if the device is not synchronized or if the register does not exist. |
Same error reported w/ RT1316 in Intel internal test 1118 cmd: TPLG=sof-tgl-rt711-rt1316-rt714.tplg ~/sof-test/test-case/check-suspend-resume-with-audio.sh -l 15 -m playback
The only think I see is that there was an interrupt generated, not sure what for. |
Are there detail steps to duplicate this issue? I got a test device from Compal, and I can try the same steps to duplicate issue on my side. |
daily test 2190 reported same issue on CML_SKU0983_SDW.
|
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: #2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: #2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: #2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: #2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: #2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: #2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com>
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
[ Upstream commit 58ef935 ] We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject/linux#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 58ef935 ] We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject/linux#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 58ef935 ] We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject/linux#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
closing since we've reworked the clock stop sequence and this wasn't noticed in 3 months. |
BugLink: https://bugs.launchpad.net/bugs/1928857 [ Upstream commit 58ef935 ] We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. IssueLink: thesofproject/linux#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1930095 [ Upstream commit 58ef935 ] We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: thesofproject/linux#2621 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210323013707.21455-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Intel internal test shows this:
dmesg_rt715_clock_stop_error.txt
@jack-cy-yu do you see any control value or writes that would cause the device to reply COMMAND_IGNORED?
The text was updated successfully, but these errors were encountered: