[UPDATE ZEPHYR] zephyr: dai: Check error code before xrun report #6965
Conversation
softwarecki
requested review from
dbaluta,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
src/audio/dai-zephyr.c
Outdated
There was a problem hiding this comment.
I recently found out that ALSA is using EPIPE to indicate xrun conditions, should we update our code to do the same?
src/audio/dai-zephyr.c
Outdated
There was a problem hiding this comment.
Shouldn't assume also -EPIPE according to https://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html ?
New example in DMA:
zephyrproject-rtos/zephyr#53327
There was a problem hiding this comment.
That does sound like a compelling argument, however here we don't have that error as a possible outcome from dma_get_status within SOF. Maybe a translation layer high above?
|
It seems that hda driver uses -EPIPE to signal xrun, as proposed in the alsa lib. In that case, I will change the error code used by dw dma from -ENODATA to -EPIPE. I will switch this PR as a draft until the error codes are unified in zephyr. Change of the error code in dw dma driver: zephyrproject-rtos/zephyr#53930 |
softwarecki
changed the title
|
SOFCI TEST |
|
@wszypelt This seems to have stuck in "merge/codecheck", can you check? |
|
rebased and force pushed to restart tests. |
|
Lots of failures around HDA and copier, @softwarecki we may have a Zephyr regression, perhaps in DT as it looks like copier cant find DAIs ? EDIT: https://sof-ci.01.org/sofpr/PR6965/build3587/devicetest/index.html |
west.yml
Outdated
There was a problem hiding this comment.
There seems to be a regression in here.
There was a problem hiding this comment.
@softwarecki @abonislawski @juimonen @teburd At least locally Isee failures with the DMA start/stop changes. Here's a test run with Zephyr just before the DMA driver changes -> #6998
There was a problem hiding this comment.
It was not that. The test run shows failures with HDMI before the start/stop changes on Zephyr side.
There was a problem hiding this comment.
@softwarecki @lgirdwood bisected problem to this change zephyrproject-rtos/zephyr#53327 (comment) -- this will show on MTL as well (once HDMI is enabled). I think we can't raise xruns on HDA link errors (to match previous behaviour expected on Linux).
Updated zephyr revision to 5d902ea621e43ec9a3916eed8dea5ab3647d81c3 Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
|
The tools build issue is fixed now, this was not related to this PR. |
This comment was marked as off-topic.
This comment was marked as off-topic.
The dma_get_status function returns -EINVAL if it detects an invalid parameter, -EPIPE if it detects an xrun. Added error code check before calling xrun handler. Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
|
@softwarecki @kv2019i do we have Zephyr fixes in flight ? if so, can we link them here so we know when to re-test. Thanks |
Not aware of any fixes yet. We have bisected the first problematic commit. I guess @makarukp you are looking at this (based on zephyrproject-rtos/zephyr#53327 (comment) ). |
|
@kv2019i I don't have any fixes yet. I made only initial analysis. I think SOF part would require improvements. I will try to solve it. |
|
Update: it turns out the old HD-DMA link driver had a feature of not actually reporting the xruns up in the stack, and Linux stack has grown to depend on this. Details in #7044 (comment) |
|
Closed because #7044 solves the same thing |
11 participants
The dma_get_status function returns -EINVAL if it detects an invalid parameter, -EPIPE if it detects an xrun. Added error code check before calling xrun handler.
Updated zephyr revision to 5d902ea621e43ec9a3916eed8dea5ab3647d81c3.