[BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW #4779

1994lwz · 2021-09-17T02:39:44Z

Describe the bug
DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW

To Reproduce
Run command: "TPLG=/lib/firmware/intel/sof-tplg/sof-cml-rt711-rt1308-mono-rt715.tplg ~/sof-test/test-case/check-suspend-resume-with-audio.sh -l 5 -m capture"
The reproduction rate is 100%

Environment
Kernel Branch: topic/sof-dev
Kernel Commit: a7bb845e
SOF Branch: main
SOF Commit: 9fadef7
Platform: CML-SKU0983-SDW

Screenshots or console output
[dmesg & slogger]
dmesg.txt
slogger.txt

[console]

2021-09-16 23:12:22 UTC Sub-Test: [REMOTE_COMMAND] Run the command: rtcwake -m mem -s 5
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Sep 16 23:12:28 2021
2021-09-16 23:12:28 UTC Sub-Test: [REMOTE_COMMAND] sleep for 5
2021-09-16 23:12:33 UTC Sub-Test: [REMOTE_INFO] Check for the kernel log status
declare -- cmd="journalctl_cmd --since=@1631833937"
2021-09-16 23:12:34 UTC Sub-Test: [REMOTE_INFO] Check for the wakeup_count
2021-09-16 23:12:34 UTC Sub-Test: [REMOTE_INFO] ===== Round(4/5) =====
2021-09-16 23:12:34 UTC Sub-Test: [REMOTE_COMMAND] Run the command: rtcwake -m mem -s 5
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Sep 16 23:12:40 2021
2021-09-16 23:12:48 UTC Sub-Test: [REMOTE_COMMAND] sleep for 5
arecord: suspend:1716: suspend: prepare error: Connection timed out
2021-09-16 23:12:53 UTC Sub-Test: [REMOTE_INFO] Check for the kernel log status
declare -- cmd="journalctl_cmd --since=@1631833949"
2021-09-16 23:12:53 UTC [ERROR] Caught kernel log error
===========================>>
[ 6554.616307] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: hda_dsp_stream_trigger: cmd 5 on dai_link "Jack In" (Capture, stream_tag: 2): timeout on STREAM_SD_OFFSET read
[ 6563.817077] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: cl_copy_fw: timeout HDA_DSP_SRAM_REG_ROM_STATUS read
[ 6563.817746] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: hda_dsp_stream_trigger: cmd 0 on -- (Playback, stream_tag: 1): timeout on STREAM_SD_OFFSET read
[ 6563.817758] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: DMA trigger stop failed
[ 6563.817765] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ------------[ DSP dump start ]------------
[ 6563.817793] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: extended rom status:  0x5000001 0x0 0x0 0x0 0x0 0x0 0x1811102 0x0
[ 6563.817800] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ------------[ DSP dump end ]------------
[ 6563.817805] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: load fw failed ret: -110
[ 6563.817862] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: failed to start DSP
[ 6563.817869] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: error: failed to boot DSP firmware after resume -110
[ 6563.817875] kernel: PM: dpm_run_callback(): pci_pm_resume+0x0/0x80 returns -110
[ 6563.817906] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: PM: failed to resume async: error -110
[ 6563.819289] kernel: soundwire_intel soundwire_intel.link.0: Failed to power up link: -11
[ 6568.918927] kernel: rt711 sdw:0:025d:0711:00: Initialization not complete, timed out
[ 6568.918943] kernel: PM: dpm_run_callback(): acpi_subsys_resume+0x0/0x70 returns -110
[ 6568.918975] kernel: rt711 sdw:0:025d:0711:00: PM: failed to resume: error -110
[ 6568.920244] kernel: soundwire_intel soundwire_intel.link.1: Failed to power up link: -11
[ 6568.920603] kernel: soundwire_intel soundwire_intel.link.1: sdw_cdns_init failed: MCP_CONTROL_SW_RST is not cleared
[ 6568.920612] kernel: soundwire_intel soundwire_intel.link.1: sdw_cdns_init failed: MCP_CONTROL_CLK_STOP_CLR is not cleared
[ 6568.920620] kernel: soundwire_intel soundwire_intel.link.1: sdw_cdns_init failed: MCP_CONTROL_HW_RST is not cleared
[ 6568.922181] kernel: soundwire_intel soundwire_intel.link.1: intel_resume failed: MCP_CONTROL_SW_RST is not cleared
[ 6568.922187] kernel: soundwire_intel soundwire_intel.link.1: intel_resume failed: MCP_CONTROL_CLK_STOP_CLR is not cleared

[coredump log]

# Core header:

# arch        00030500 # totalsize   80000000 # stackptr    00000000 # stackoffset 00000000
# configidhi  00000000 # configidlo  00000000 # numaregs    00000000

# CPU registers:

# exccause    00000000 # excvaddr    00000000 # ps          00000000
# epc1        00000000 # epc2        00000000 # epc3        00000000 # epc4        00000000
# epc5        00000000 # epc6        00000000 # epc7        00000000
# eps2        00000000 # eps3        00000000 # eps4        00000000 # eps5        00000000
# eps6        00000000 # eps7        00000000
# depc        00000000 # intenable   00000000 # interrupt   00000000 # sar         00000000
# debugcause  00000000
# windowbase  00000000 # windowstart 00000000
# excsave1    00000000
# ar0         00000000 # ar1         00000000 # ar2         00000000 # ar3         00000000
# ar4         00000000 # ar5         00000000 # ar6         00000000 # ar7         00000000
# ar8         00000000 # ar9         00000000 # ar10        00000000 # ar11        00000000
# ar12        00000000 # ar13        00000000 # ar14        00000000 # ar15        00000000
# ar16        00000000 # ar17        00000000 # ar18        00000000 # ar19        00000000
# ar20        00000000 # ar21        00000000 # ar22        00000000 # ar23        00000000
# ar24        00000000 # ar25        00000000 # ar26        00000000 # ar27        00000000
# ar28        00000000 # ar29        00000000 # ar30        00000000 # ar31        00000000
# ar32        00000000 # ar33        00000000 # ar34        00000000 # ar35        00000000
# ar36        00000000 # ar37        00000001 # ar38        00000000 # ar39        00000000
# ar40        00000000 # ar41        00000001 # ar42        00000000 # ar43        00000000
# ar44        00000000 # ar45        00000001 # ar46        00000000 # ar47        00000000
# ar48        00000000 # ar49        00000001 # ar50        00000000 # ar51        00000000
# ar52        00000000 # ar53        00000001 # ar54        00000000 # ar55        00000000
# ar56        00000000 # ar57        00000001 # ar58        00000000 # ar59        00000000
# ar60        00000000 # ar61        00000001 # ar62        00000000 # ar63        00000000


# windowbase: 0
#
# windowstart: b0

#      reg         a0         a1
#                  (return)   (sptr)
#      ---         --------   -------

# Stack dumped from 00000000 dwords num 406

# *EXCEPTION*

# exccause: IllegalInstructionCause: Illegal instruction

The text was updated successfully, but these errors were encountered:

XiaoyunWu6666 · 2021-09-17T07:30:44Z

this happened in 6200 6292 6655
Sorry for skipping them since 'MCP_CONTROL_HW_RST is not cleared at iteration' exists and I took them as thesofproject/linux#3012

plbossart · 2021-09-17T15:48:42Z

Sorry @XiaoyunWu6666, not following you. Are you saying the "timeout on STREAM_SD_OFFSET" and "MCP_CONTROL_HW_RST is not cleared at iteration N" errors are correlated somehow?

@bardliao this would be interesting indeed.

lgirdwood · 2021-09-17T16:10:49Z

@XiaoyunWu6666 @1994lwz can someone try reverting 9fadef7 and retest.
@ranj063 and I have a suspicion this is related to

DSP -> host DMA traffic volume prior to suspend (in which case multiple capture streams would also show this).
Time between trace being disabled and DSP entering D3. More traffic may mean DMA takes longer to enter idle (and safe to enter D3).
@keyonjie fyi.

XiaoyunWu6666 · 2021-09-18T03:04:44Z

@lgirdwood @RanderWang @plbossart
In today's inner daily 6686
both CML_SKU0983_SDW and CML_SKU0955_HDA have this issue

FYI , I tried to revert 9fadef7 and retest on CML_SKU0983_SDW (running suspend-resume-5-time during capture , for 100 rounds )
so far so good . haven't reproduce the issue (noted that this issue isn't 100% reproducible so this is just a reference)

ranj063 · 2021-09-18T03:43:24Z

@1994lwz @XiaoyunWu6666 could you please check if thesofproject/linux#3166 helps fix the issue?

1994lwz · 2021-09-18T03:57:09Z

I tried to revert 9fadef7 and retest on CML_SKU0955_HDA (running suspend-resume-5-time during capture , for 50 rounds ), haven't reproduce the issue.

XiaoyunWu6666 · 2021-09-18T05:50:09Z

@1994lwz @XiaoyunWu6666 could you please check if thesofproject/linux#3166 helps fix the issue?

hi @ranj063 . I am afraid not , the same error appears again.
kernel commit : 0620fb04b2d01
sof commit ：509eef9c96b8
PR ：3166
@1994lwz will make a double confirm

Also I run a test in CI with 3166 (see inner result test 6693) , it got a FAIL too

1994lwz · 2021-09-18T06:01:52Z

@1994lwz @XiaoyunWu6666 could you please check if thesofproject/linux#3166 helps fix the issue?

hi @ranj063 . I am afraid not , the same error appears again.
kernel commit : 0620fb04b2d01
sof commit ：509eef9c96b8
PR ：3166
@1994lwz will make a double confirm

the same error appears again on CML_SKU0955_HDA.

When the stream is cleared during the suspend trigger, the dma_data must be set to NULL and snd_hdac_ext_stream_release() must be called to release the link dev. Without this, some platforms run into issues with triggering the host DMA during system resume. Add the missing sequences to both hda_link_pcm_trigger() to handle all streams that get suspended and to hda_dsp_set_hw_params_upon_resume() to handle paused streams that are reset during system suspend. Also, because the dma_data is set to NULL during suspend, add the checks to ensure link_dev is not NULL during hw_params and hw_free to prevent NULL pointer dereferences. BugLink: thesofproject/sof#4779 Signed-off-by: Ranjani Sridharan <[email protected]>

ranj063 · 2021-09-18T22:53:35Z

@XiaoyunWu6666 @1994lwz I have updated my PR thesofproject/linux#3166 to fix the issues during suspend-resume on capture on the CML Helios and the CML-HDA. Could you please double confirm?

@plbossart I need your help for the CML SDW case.

When the stream is cleared during the suspend trigger, the dma_data must be set to NULL and snd_hdac_ext_stream_release() must be called to release the link dev. Without this, some platforms run into issues with triggering the host DMA during system resume. Add the missing sequences to both hda_link_pcm_trigger() to handle all streams that get suspended and to hda_dsp_set_hw_params_upon_resume() to handle paused streams that are reset during system suspend. Also, because the dma_data is set to NULL during suspend, add the checks to ensure link_dev is not NULL during hw_params and hw_free to prevent NULL pointer dereferences. BugLink: thesofproject/sof#4779 Signed-off-by: Ranjani Sridharan <[email protected]>

lgirdwood · 2021-09-20T09:25:56Z

@ranj063 @1994lwz @XiaoyunWu6666 has anyone tried reverting 9fadef7 AND trying multiple capture streams for this test. i.e. try 2 then 3 capture streams in this test.
This will help us determine if its more likely to be

Capture DMA traffic prior to D3
Capture (trace) DMA shutdown prior to D3.

ranj063 · 2021-09-20T15:32:20Z

@ranj063 @1994lwz @XiaoyunWu6666 has anyone tried reverting 9fadef7 AND trying multiple capture streams for this test. i.e. try 2 then 3 capture streams in this test.
This will help us determine if its more likely to be

Capture DMA traffic prior to D3

Capture (trace) DMA shutdown prior to D3.

@lgirdwood I tried 2 capture streams during suspend with my kernel PR on the helios and it works fine. My PR fixes this issue on both the helios and the HDA laptop.

plbossart · 2021-09-20T16:39:36Z

This issue and related PRs are really hard to follow. I ran a quick test on CML_SKU09C6_SDW (same as CML-SKU0983-SDW) and I don't see any issue.

"TPLG=/lib/firmware/intel/sof-tplg/sof-cml-rt711-rt1308-mono-rt715.tplg ~/sof-test/test-case/check-suspend-resume-with-audio.sh -l 5 -m capture"
The reproduction rate is 100% <<< NOT REPRODUCED AT ALL.

We should really deal with separate sightings and validations, it's not helpful if we conflate HDaudio, Chromebook and SoundWire platforms in the same bucket. They use different links and there's no real rationale for errors being common.

kernel: 73e5ae02dd8c
SOF: 4de6627

plbossart · 2021-09-20T17:43:05Z

ok, so the command above is a bit misleading. I changed it to "TPLG=/lib/firmware/intel/sof-tplg/sof-cml-rt711-rt1308-mono-rt715.tplg ~/sof-test/test-case/check-suspend-resume-with-audio.sh -l 200 -m capture" and I see errors happening somewhat randomly, e.g. round 19, 2, 25.

we probably need to change the '5' value since it leads to missed errors in CI.

plbossart · 2021-09-20T19:29:07Z

PR thesofproject/linux#3166 does not solve anything on CML_SKU09C6_SDW, now trying to with a revert of 9fadef7

This reverts commit 9fadef7. After multiple trials on a CometLake SoundWire device, this revert to bring the trace back to what it was seems to be the only solution, the suggested PR thesofproject/linux#3166 does not help on this SoundWire device. We had similar issues with SD offset timeouts and a similar revert with thesofproject#4578 at the end of July, there's something that we are missing on what the trace does and how it impacts the DMA handling. BugLink: thesofproject#4779 Signed-off-by: Pierre-Louis Bossart <[email protected]>

plbossart · 2021-09-20T19:46:42Z

Reverting 9fadef7 works in my local tests, submitted PR #4785 for more tests.

@lgirdwood @ranj063 @1994lwz @keyonjie @marc-hb FYI

marc-hb · 2021-09-20T23:01:46Z

Found another recent CML suspend timeout but it looks a bit different: https://sof-ci.01.org/sofpr/PR4771/build10385/devicetest/?model=CML_HEL_RT5682&testcase=check-suspend-resume-with-capture

[ 1481.879185] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ipc tx: 0x60050000: GLB_STREAM_MSG: TRIG_STOP
[ 1481.879870] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ipc tx succeeded: 0x60050000: GLB_STREAM_MSG: TRIG_STOP
[ 1481.880649] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: FW Poll Status: reg[0xa0]=0x240002 timedout
[ 1481.880692] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: hda_dsp_stream_trigger: cmd 0 on dai_link "Port1" (Capture, stream_tag: 2): timeout on STREAM_SD_OFFSET read
[ 1481.880744] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ipc tx: 0x60030000: GLB_STREAM_MSG: PCM_FREE
[ 1481.881007] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ipc tx succeeded: 0x60030000: GLB_STREAM_MSG: PCM_FREE
[ 1481.881230] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: pcm: free stream 0 dir 1
[ 1481.896939] kernel: sof-audio-pci-intel-cnl 0000:00:1f.3: ipc tx: 0x80010000: GLB_DAI_MSG: CONFIG

This reverts commit 9fadef7. After multiple trials on a CometLake SoundWire device, this revert to bring the trace back to what it was seems to be the only solution, the suggested PR thesofproject/linux#3166 does not help on this SoundWire device. We had similar issues with SD offset timeouts and a similar revert with #4578 at the end of July, there's something that we are missing on what the trace does and how it impacts the DMA handling. BugLink: #4779 Signed-off-by: Pierre-Louis Bossart <[email protected]>

keyonjie · 2021-09-22T02:22:37Z

Reverting 9fadef7 works in my local tests, submitted PR #4785 for more tests.

@lgirdwood @ranj063 @1994lwz @keyonjie @marc-hb FYI

Not quite following here, @plbossart do you mean changing some Kconfig items will impact the DMA of the normal pipelines? But anyway someone can still manually unselect the trace filtering and then the issue will be exposed again, no?

XiaoyunWu6666 · 2021-09-22T02:27:57Z

#4785 has been merged ,and in today's inner daily 6739 , CML_SKU0983_SDW and CML_SKU0955_HDA are good
No DMA trigger stop error happened.
Let's keep observing it (Also observe on JSL_RVP_NOCODEC because this issue once happened on JSL_RVP_NOCODEC in inner daily 6697)

marc-hb · 2021-09-22T02:42:18Z

Not quite following here, @plbossart do you mean changing some Kconfig items will impact the DMA of the normal pipelines?

When the system is brittle or unstable then all bets are off.

ranj063 · 2021-09-22T03:18:03Z

@lgirdwood I think the right fix for this issue and #4558 is in Linux PR thesofproject/linux#3167 and SOF PR #4793

plbossart · 2021-09-22T16:44:15Z

@lgirdwood @keyonjie My theory for this timeout issue is a race condition where the firmware removes access to the L2 SRAM when we stop the DMA (by clearing the DGCS_GEN bit), and as a result if there are pending DMA transactions clearing the RUN bit from the driver side times out.

By changing the way the trace works, and possibly adding more trace transactions, we may see this race condition more often.

The recommended sequence is to remove access to the L2 SRAM AFTER the DMA is stopped with a follow-up IPC. This is clearly indicated in the hardware programming sequence, it's implemented in the Windows driver but we didn't follow it in the Linux firmware/driver for some reason.

1994lwz · 2021-09-27T07:36:10Z

Use the Linux PR thesofproject/linux#3167 and SOF PR #4793 to build the kernel and firmware, not reproduce on the cml-sku0983-sdw/ cml-sku0955-hda by test the suspend-resume during capturing 100 times

lgirdwood · 2021-10-13T11:02:25Z

@1994lwz can we close now ?

1994lwz · 2021-10-14T01:21:08Z

This issue is fixed by thesofproject/linux#3167 and not reproduce on the recent daily, so close it.

marc-hb · 2021-10-15T07:02:21Z

thesofproject/linux#3167 is not merged yet and neither is #4558

1994lwz · 2021-10-18T06:17:27Z

This issue is not reproduce anymore after merged the PR #4785, we will close it after the Linux PR thesofproject/linux#3167 and SOF PR #4793 be merged and verified.

marc-hb · 2021-11-02T07:12:37Z

#4793 was replaced by #4820 and #4844

XiaoyunWu6666 · 2021-11-08T02:50:54Z

Since relevant PRs were already merged and havent happened in inner daily tests for nearly 50 days . So close it

relevant PRs : thesofproject/linux#3167 #4820 and #4844

keqiaozhang · 2021-11-30T06:22:33Z

Observed this issue again when running suspend/resume stress testing on CML_SKU0983_SDW. Test ID:8054.

[ 1592.161340] kernel: rt1308 sdw:1:025d:1308:00: sdw_modify_slave_status: signaling enumeration completion for Slave 1
[ 1592.292468] kernel: rt1308 sdw:1:025d:1308:00: rt1308_io_init m_btl_l=0xffe2, m_btl_r=0x8
[ 1592.292481] kernel: rt1308 sdw:1:025d:1308:00: rt1308_io_init c_btl_l=0x2ef, c_btl_r=0x10
[ 1592.301784] kernel: rt1308 sdw:1:025d:1308:00: rt1308_io_init hw_init complete
[ 1592.301790] kernel: rt1308 sdw:1:025d:1308:00: sdw_handle_slave_status: signaling initialization completion for Slave 1
[ 1592.314783] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 0
[ 1592.316316] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 1
[ 1592.317774] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 2
[ 1592.319304] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 3
[ 1592.320779] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 4
[ 1592.322308] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 5
[ 1592.323777] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 6
[ 1592.325361] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 7
[ 1592.326844] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 8
[ 1592.328468] kernel: soundwire_intel soundwire_intel.link.2: intel_resume: MCP_CONTROL_HW_RST is not cleared at iteration 9
[ 1592.329841] kernel: soundwire_intel soundwire_intel.link.2: intel_resume failed: MCP_CONTROL_HW_RST is not cleared

plbossart · 2021-11-30T14:11:37Z

wrong bug @keqiaozhang, this had nothing to do with DMA. This should be added in thesofproject/linux#3012

1994lwz added bug Something isn't working as expected CML Applies to Comet Lake platform suspend-resume Issues observed when doing system suspend and resume labels Sep 17, 2021

XiaoyunWu6666 added the Intel Linux Daily tests This issue can be found in internal Linux daily tests label Sep 17, 2021

ranj063 mentioned this issue Sep 17, 2021

Trace fixes thesofproject/linux#3166

Closed

marc-hb mentioned this issue Sep 20, 2021

trace: fixes to help for heap allocation debugging #4548

Merged

plbossart mentioned this issue Sep 20, 2021

Revert "trace: Kconfig: disable filtering by default" #4785

Merged

plbossart mentioned this issue Sep 21, 2021

[BUG]DSP panic when suspend-resume on cml-sku0983-sdw and cml-sku0955-hda #4538

Closed

XiaoyunWu6666 added the JSL Applies to Jasper Lake platform label Sep 22, 2021

XiaoyunWu6666 mentioned this issue Sep 24, 2021

Re-enable trace filtering and implement DMA reset op #4793

Closed

1994lwz closed this as completed Oct 14, 2021

marc-hb reopened this Oct 15, 2021

1994lwz closed this as completed Oct 18, 2021

1994lwz reopened this Oct 18, 2021

marc-hb mentioned this issue Nov 2, 2021

[BUG] FW status on IPC timeout in test 07_05_TestKdDmicD0ix16000Hz16b16b2ch #4929

Closed

XiaoyunWu6666 closed this as completed Nov 8, 2021

keqiaozhang reopened this Nov 30, 2021

plbossart closed this as completed Nov 30, 2021

marc-hb changed the title ~~[BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW~~ [BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW (MCP_CONTROL_HW_RST) Feb 17, 2022

marc-hb changed the title ~~[BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW (MCP_CONTROL_HW_RST)~~ [BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW Feb 17, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW #4779

[BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW #4779

1994lwz commented Sep 17, 2021 •

edited

Loading

XiaoyunWu6666 commented Sep 17, 2021 •

edited

Loading

plbossart commented Sep 17, 2021

lgirdwood commented Sep 17, 2021

XiaoyunWu6666 commented Sep 18, 2021

ranj063 commented Sep 18, 2021

1994lwz commented Sep 18, 2021

XiaoyunWu6666 commented Sep 18, 2021 •

edited

Loading

1994lwz commented Sep 18, 2021

ranj063 commented Sep 18, 2021 •

edited

Loading

lgirdwood commented Sep 20, 2021 •

edited

Loading

ranj063 commented Sep 20, 2021

plbossart commented Sep 20, 2021

plbossart commented Sep 20, 2021

plbossart commented Sep 20, 2021

plbossart commented Sep 20, 2021

marc-hb commented Sep 20, 2021

keyonjie commented Sep 22, 2021 •

edited

Loading

XiaoyunWu6666 commented Sep 22, 2021 •

edited

Loading

marc-hb commented Sep 22, 2021

ranj063 commented Sep 22, 2021

plbossart commented Sep 22, 2021

1994lwz commented Sep 27, 2021 •

edited

Loading

lgirdwood commented Oct 13, 2021

1994lwz commented Oct 14, 2021 •

edited

Loading

marc-hb commented Oct 15, 2021 •

edited

Loading

1994lwz commented Oct 18, 2021 •

edited

Loading

marc-hb commented Nov 2, 2021

XiaoyunWu6666 commented Nov 8, 2021

keqiaozhang commented Nov 30, 2021

plbossart commented Nov 30, 2021

[BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW #4779

[BUG] DMA trigger stop failed when suspend-resume during capturing on CML-SKU0983-SDW #4779

Comments

1994lwz commented Sep 17, 2021 • edited Loading

XiaoyunWu6666 commented Sep 17, 2021 • edited Loading

plbossart commented Sep 17, 2021

lgirdwood commented Sep 17, 2021

XiaoyunWu6666 commented Sep 18, 2021

ranj063 commented Sep 18, 2021

1994lwz commented Sep 18, 2021

XiaoyunWu6666 commented Sep 18, 2021 • edited Loading

1994lwz commented Sep 18, 2021

ranj063 commented Sep 18, 2021 • edited Loading

lgirdwood commented Sep 20, 2021 • edited Loading

ranj063 commented Sep 20, 2021

plbossart commented Sep 20, 2021

plbossart commented Sep 20, 2021

plbossart commented Sep 20, 2021

plbossart commented Sep 20, 2021

marc-hb commented Sep 20, 2021

keyonjie commented Sep 22, 2021 • edited Loading

XiaoyunWu6666 commented Sep 22, 2021 • edited Loading

marc-hb commented Sep 22, 2021

ranj063 commented Sep 22, 2021

plbossart commented Sep 22, 2021

1994lwz commented Sep 27, 2021 • edited Loading

lgirdwood commented Oct 13, 2021

1994lwz commented Oct 14, 2021 • edited Loading

marc-hb commented Oct 15, 2021 • edited Loading

1994lwz commented Oct 18, 2021 • edited Loading

marc-hb commented Nov 2, 2021

XiaoyunWu6666 commented Nov 8, 2021

keqiaozhang commented Nov 30, 2021

plbossart commented Nov 30, 2021

1994lwz commented Sep 17, 2021 •

edited

Loading

XiaoyunWu6666 commented Sep 17, 2021 •

edited

Loading

XiaoyunWu6666 commented Sep 18, 2021 •

edited

Loading

ranj063 commented Sep 18, 2021 •

edited

Loading

lgirdwood commented Sep 20, 2021 •

edited

Loading

keyonjie commented Sep 22, 2021 •

edited

Loading

XiaoyunWu6666 commented Sep 22, 2021 •

edited

Loading

1994lwz commented Sep 27, 2021 •

edited

Loading

1994lwz commented Oct 14, 2021 •

edited

Loading

marc-hb commented Oct 15, 2021 •

edited

Loading

1994lwz commented Oct 18, 2021 •

edited

Loading