[Draft] Revert/pr7700 tdfb

[fredoh9]

#7700 reverted

[fredoh9]

I have checked the device test result, still ongoing but it looks good so far.

[andrula-song]

can you share the log of exception? as I know, in our default pipeline it should not contain TDFB component right know. I'am afraid it is another issue has not been exposed before.

[fredoh9]

Kernel driver caught DSP Exeption but mtrace doesn't have the exception.

Intel internal test result link: planresultdetail/28228

mtl-nocodec-mtrace.txt
mtl-nocodec-dmesg.txt

[andrula-song]

I tested on device by my own, it seems the error does not happen every time. And the ipc timeout first appeared here https://sof-ci.ostc.intel.com/#/result/planresultdetail/28182?model=MTLP_RVP_NOCODEC&testcase=check-suspend-resume-with-playback-5. So I tried to keep my code and revert the commit 73cd960(#7857), and I never met this anymore.
Since there is no TDFB in our pipeline, I think the root cause may not be the TDFB optimization, can you @fredoh9 double check?

[ranj063]

I tested on device by my own, it seems the error does not happen every time. And the ipc timeout first appeared here https://sof-ci.ostc.intel.com/#/result/planresultdetail/28182?model=MTLP_RVP_NOCODEC&testcase=check-suspend-resume-with-playback-5. So I tried to keep my code and revert the commit 73cd960(#7857), and I never met this anymore. Since there is no TDFB in our pipeline, I think the root cause may not be the TDFB optimization, can you @fredoh9 double check?

I Have to agree that the tdfb optimization cannot possibly result in the PM regression. @fredoh9 Can you pleae check if #7857 is the culprit?

[fredoh9]

#7857 has included multiple commits but it was tested in yesterday daily.
Let me revert it while keeping TDFB changes.

[marc-hb]

#7857 has included multiple commits but it was tested in yesterday daily.
Let me revert it while keeping TDFB changes.

You will have to revert #7325 first because 7325 depends on 7857

[fredoh9]

confirmed, after reverting #7857 while keeping TDFB, there is no dsp exception.
The easiest way to check is checking booting log and running runtime pm test.

#7857 has multiple zephyr commits jump, please advise how to pinpoint the commit

[fredoh9]

And #7857 was daily tested. It alone doesn't create the crash.

Yesterday's daily test link: planresultdetail/28254 == PASS
Start Time: 2023-06-27 10:32:56 UTC
SOF Branch: main
SOF Commit: 73cd960e0ed4 == #7857

[fredoh9]

To double checking the result, submitted reverting pr(7857+7325) #7873

[marc-hb]

https://sof-ci.01.org/sofpr/PR7869/build10168/devicetest is all green, which means reverting 7700 is enough...

Discussion moved to new bug filed by @fredoh9 (thx):

• [BUG][MTL] MOD_SET_DX causes DSP exception (very recent regression) #7875

[fredoh9]

closing this, discussion in #7875