-
Notifications
You must be signed in to change notification settings - Fork 319
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] BYT: Random stereo channels swaps happen with sof-byt-nocodec.tplg #3520
Comments
We should make sure the SSP port is disabled when trying to start new transmission or reception, to avoid any potential race between transmission and the reception on the same SSP port. Fixes thesofproject#3520 thesofproject#3525 Signed-off-by: Keyon Jie <[email protected]>
Add the similar fix to baytrail ssp which disabling the SSP port during ssp_start(), to avoid any potential race between transmission and the reception on the same SSP port. Fixes thesofproject#3520 Signed-off-by: Keyon Jie <[email protected]>
@keyonjie The channels swap issue happens still with BYT nocodec topology (LBM quirk is set). The kernel, firmware etc. are from git today.
When I last tested near month ago #3535 it didn't help with LBM, didn't help with Tx-Rx wire and no LBM quirk. |
Mimid the SSP RX FIFO flushing logic which verified work on CNL/WHL. We need to read out entries every time the FIFO is not empty. This flushing may need take place several rounds, and we need to wait 1 sample time between 2 flushing rounds. Fixes thesofproject#3520 Signed-off-by: Keyon Jie <[email protected]>
Hi @singalsu unfortunately, after several hours debugging, it looks to me that the external wired mode looks quite similar to internal LBM for BYT SSP, the capture can't be stopped separately so the RX FIFO watermark(RFL) keep increasing even we have cleared the RSRE (while SSE is set), so, to me, this issue looks is not easy to be fixed. |
@lyakh fyi |
Commit 05e1c26 ("byt-ssp: fixes for DSP modes") removed a work-around for known hardware bugs, causing channel swapping in I2S mode. Restore the work-around but make sure it's only enabled in I2S and LEFT_J modes. Fixes: thesofproject#3699, thesofproject#3520 Signed-off-by: Guennadi Liakhovetski <[email protected]>
Commit 05e1c26 ("byt-ssp: fixes for DSP modes") removed a work-around for known hardware bugs, causing channel swapping in I2S mode. Restore the work-around but make sure it's only enabled in I2S and LEFT_J modes. Fixes: #3699, #3520 Signed-off-by: Guennadi Liakhovetski <[email protected]>
presumably fixed by #3777 |
@lyakh I got still error and detected channels swap from check-volume-levels.sh. The same happens with LBM quirk an without with Tx-Rx jumper wire. |
do we have a list of "known won't-fix issues" to be tracked in case they do get fixed by accident or they have to be re-opened and we can benefit from earlier discussions? |
yes, we have a label for that, just add it to this issue |
closing this as wont_fix. |
Describe the bug
I have developed a test that plays different frequency sine waves in each channel to PCM0P and captures from PCM0C. The purpose of the test is volume control testing but it detects also basic issues like channel swap. The reported error indicates that the playback, ssp-loopback, or capture channels got swapped.
The topology contains also volume components and mixer in the playback path. Though since a similar topology passes in APL platform the bug in those components is unlikely. But I'll try to replicate with a minimized topology later.
To Reproduce
With PR thesofproject/sof-test#410 (to add the test) and sof PR #3509 (add the volume switch to nocodec topologies) run:
sof-test/test-case/check-volume-levels.sh
Reproduction Rate
For one sub-test (play-capture) about 50% occurrence. Below 2 of 3 sub-tests failed.
Expected behavior
No channels swapped, the test passed as it does in cAVS platforms.
Impact
Annoyance for stereo music, showstopper for applications where channels order is critical.
Environment
Screenshots or console output
Please also include the relevant sections from the firmware log and kernel log in the report (and attach the full logs for complete reference). Kernel log is taken from dmesg and firmware log from sof-logger. See https://thesofproject.github.io/latest/developer_guides/debugability/logger/index.html
The text was updated successfully, but these errors were encountered: