[ktrzcinx]

#2203

dw_dma: Remove redundant write pointer increment

Function dw_dma_increment_pointer is called in each
dw_dma_copy and moves write pointer by number of passed
bytes a priori. Its why this function shouldn't be called
after dma stops before whole transmission ends.
It leads to misalignment in data stored in any queue between
source buffer and output, with data written to this interface
and glitch when first data after release command come.

dw_dma: Shorten DW_DMA_TIMEOUT value below 1 ms

Timeout values above 1ms (task period) shouldn't happen.
In such a situation system agent is likely to panic
because of time drift, what shouldn't happen in such
a situation.

dw_dma: Suspend DMA channel in stop function

Suspend flag should be set regardless of draining mode to stop
draining data from source buffer.

ssp: Keep SSP connected with DMA in pause state

When there is not enough time to wait for FIFO empty and we care about
data continuous - like in pause state - then SSP should be kept connected
with DMA in pause state. Such a solution is less error prone.
After this change, glitches after pause/resume sequence disappear.

[lgirdwood]

Good find.

[lgirdwood]

SOFCI TEST

[lgirdwood]

@fredoh9 do we have a DUT issue with BSW_CYN_MAX98090 ? Same tests are passing on BYT.
@ktrzcinx can you check internal CI

[plbossart]

This looks like serious/well-structured work, but it would be useful if there was a cover letter or something that indicates what you are trying to fix. What is the issue with pause really? Is this a problem exposed by low-level tests, or something that can happen in a driver/linux environment.

Also I am not clear on how well the PAUSE is supported. To the best of my knowledge we didn't enable a number of hardware capabilities, e.g. to restore DMA context after resume.

Thanks!

[ktrzcinx]

Also I am not clear on how well the PAUSE is supported

@plbossart me too but from firmware side STOP and PAUSE are separate commands. I've checked my solution with low-level tests only.

@ktrzcinx can you check internal CI

As I see there is introduced one issue, I'm going to fix it.

[lgirdwood]

@xiulipan @tlauda @slawblauciak seeing this on several PRs now on APL

kernel: [  559.964590] sof-audio-pci 0000:00:0e.0: ipc tx succeeded: 0x80010000: GLB_DAI_MSG: CONFIG
kernel: [  559.964596] sof-audio-pci 0000:00:0e.0: ipc tx: 0x80010000: GLB_DAI_MSG: CONFIG
kernel: [  560.469206] sof-audio-pci 0000:00:0e.0: error: ipc timed out for 0x80010000 size 120

Do we have a issue # for this on bug scrub ?

[xiulipan]

@lgirdwood We also find IPC timeout issue on APL/TGL now. @ranj063 @fredoh9 @ClarexZhou thesofproject/linux#1783 #2348
please help to root cause or bisect the issue

[lgirdwood]

@xiulipan @zrombel has ran some tests and does not see this at his end on latest master. Could be a DUT issue since it always seems to be APL nocdec.
@ktrzcinx the BSW failures are NOT ipc timeouts and need to be addressed (IPC returns an error code - no FW crash)

[tlauda]

@lgirdwood @zrombel I think we need more testing regarding IPC timeout. In this PR #2367 it failed on two separate APL platforms and both times on DAI config for SSP5. It looks very suspicious. Also DMIC DAI config timeout disappeared with some random changes in the FW, so I suspect some kind of memory issue.

[slawblauciak]

@lgirdwood I don't think we do

[ktrzcinx]

SOFCI TEST

[lgirdwood]

@ktrzcinx any idea why TestPtpComplexStreamOperations24000Hz24b32b4ch would fail ?
@xiulipan @fredoh9 what's the ETA for restoring BDW on last working kernel ?

[xiulipan]

@lgirdwood From suggestion of @wenqingfu, we will keep the BDW status to track when the BDW will recovery. For SOF PR that need to check BDW status, we can do some manually check. Is that OK for you?

[ktrzcinx]

@ktrzcinx any idea why TestPtpComplexStreamOperations24000Hz24b32b4ch would fail ?

@lgirdwood after rerun (without code change), TestKdSsp16000Hz16b16b2ch failed and TestPtpComplexStreamOperations24000Hz24b32b4ch pass, so I guess it's some CI issue.

[lgirdwood]

SOFCI TEST

[lgirdwood]

Running CI again for BDW test. Internal CI will need bisected.

[lgirdwood]

SOFCI TEST

[juimonen]

check the commit message, there's quite a lot of typos etc.

1. continuous -> continuity?
2. "Such a solution is less error prone.", remove this sentence altogether
3. in paused state and after channel stop state should be preprare, to be
   conistent with sof-docs -> typos and grammar

[lgirdwood]

@plbossart @keyonjie I'm assuming the PM failures on BDW are known/WIP and wont block this merging ?

[keyonjie]

@plbossart @keyonjie I'm assuming the PM failures on BDW are known/WIP and wont block this merging ?

I remember @ranj063 was working on BYT/CHT/BDW PM implementation but looks not integrated yet? But I am not sure if we will hit error or the driver will just not do power cycle and everything looks fine when system suspending triggered on BDW? @plbossart @ranj063 do you know the latest status about this?

[lgirdwood]

SOFCI TEST

[lgirdwood]

Let me retry, I did see this pass yesterday so it could be the DUT or a recent kernel update.