-
Notifications
You must be signed in to change notification settings - Fork 318
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
[BUG][ARL] DSP panic when freeing dmic capture pipeline #8503
Labels
Milestone
Comments
kv2019i
added
bug
Something isn't working as expected
P1
Blocker bugs or important features
ARL
Applies to Intel Arrow Lake platform
labels
Nov 20, 2023
Reproduced the bug, happens both with SOF main and also with latest mtl-007 branch. Debug continues. |
kv2019i
added a commit
to kv2019i/zephyr
that referenced
this issue
Nov 27, 2023
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue with following sequence: - dma_start -> device powered up - dma_stop -> device powered down - dma_stop -> call to dw_dma_is_enabled() and crash Fix the issue by tracking hardware status in the driver, and blocking the stop if hardware is already powered down. Multiple starts are already handled in dw_dma_start(). Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
added a commit
to kv2019i/zephyr
that referenced
this issue
Nov 28, 2023
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
added a commit
to kv2019i/zephyr
that referenced
this issue
Dec 7, 2023
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
added a commit
to kv2019i/zephyr
that referenced
this issue
Dec 14, 2023
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
added a commit
to kv2019i/zephyr
that referenced
this issue
Dec 14, 2023
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
fabiobaltieri
pushed a commit
to zephyrproject-rtos/zephyr
that referenced
this issue
Dec 15, 2023
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
added a commit
to kv2019i/sof
that referenced
this issue
Dec 19, 2023
Update Zephyr to bring in total of 169 commits, including the following related to SOF targets: dab6f665ca77 xtensa: fix build errors with cache functions 039e5ef1b813 intel_adsp: remove rimage sign() from `west flash` c7e3ccd51ad4 drivers: dma: intel_adsp_gpdma: fix issue with stop and PM refcounts Link: thesofproject#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
lgirdwood
pushed a commit
that referenced
this issue
Dec 20, 2023
Update Zephyr to bring in total of 169 commits, including the following related to SOF targets: dab6f665ca77 xtensa: fix build errors with cache functions 039e5ef1b813 intel_adsp: remove rimage sign() from `west flash` c7e3ccd51ad4 drivers: dma: intel_adsp_gpdma: fix issue with stop and PM refcounts Link: #8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Fix merged via #8650 |
coreboot-org-bot
pushed a commit
to coreboot/zephyr-cros
that referenced
this issue
Dec 23, 2023
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. (cherry picked from commit c7e3ccd) Original-Link: thesofproject/sof#8503 Original-Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> GitOrigin-RevId: c7e3ccd Change-Id: I9373f09038d2eccf6007c7aac440d1b747e0f3b6 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/5129136 Tested-by: ChromeOS Prod (Robot) <chromeos-ci-prod@chromeos-bot.iam.gserviceaccount.com> Commit-Queue: Fabio Baltieri <fabiobaltieri@google.com> Reviewed-by: Yuval Peress <peress@google.com> Reviewed-by: Fabio Baltieri <fabiobaltieri@google.com> Tested-by: Fabio Baltieri <fabiobaltieri@google.com> Reviewed-by: Keith Short <keithshort@chromium.org>
abonislawski
pushed a commit
to abonislawski/zephyr
that referenced
this issue
Jan 22, 2024
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
abonislawski
pushed a commit
to abonislawski/zephyr
that referenced
this issue
Jan 22, 2024
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
tmleman
pushed a commit
to tmleman/zephyr
that referenced
this issue
Jan 25, 2024
The DMA interface allows start and stop to be called multiple times and driver should ensure nothing bad happens if the calls are not balanced. Fix an issue where after a start-stop sequence the DMA would be powered down, and then a subsequent stop would result in a crash as driver accesses registers of a powered down hardware block. Fix the issue by handling stop without actually reading the hw registers to check channel status. Link: thesofproject/sof#8503 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
DSP panic is hit at end of dmic capture pipeline playback. The issue only happens with dmic pipeline, HDA codec capture is ok as is playback.
To Reproduce
arecord -c4 -fS32_LE -r48000 -Dhw:sofhdadsp,6 -traw -d10 /dev/null
Reproduction Rate
100%
Expected behavior
No DSP crash.
Impact
showstopper
Environment
Kernel: sof-dev f8d998e836de400abc185788b0e9af3d48cb5429
SOF: 8b1a01f
Topology: sof-hda-generic.tplg
Platform: arl
Screenshots or console output
DSP crash log
The text was updated successfully, but these errors were encountered: