Alright, removed some of the state checks from the EDMA driver. This changes the problem to the one of the hardware interaction between EDMA and ESAI. Channel states are now not preventing any flow from happening, although I'm not 100% certain they are correct.
Guess I need to focus on them now.
Jerome, Guido: Since I cannot access the DMA hardware from the ESAI driver or the ESAI hardware from the DAI driver (separation of concerns) how can I ensure that changing the ERQ/EARQ bits in the TCD will work correctly? Do I need to, on resume, fill the pipeline with silence? Do I need to do something else? At the end of my esai_start() function the TFE condition is signaled and afterwards dma_start is called in the resume flow.
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Paul Olaru Sent: Monday, September 16, 2019 1:12 PM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Cc: Jerome Laclavere jerome.laclavere@nxp.com; Daniel Baluta daniel.baluta@nxp.com; Guido Roncarolo guido.roncarolo@nxp.com Subject: Re: [Sound-open-firmware] Questions about the pause-release flow
Replies inline.
Shouldn't unpausing actually send COMP_TRIGGER_RELEASE?
Yeah, it should do - it's designed to mirror the ALSA trigger commands.
Somehow something is weirded out as in the IPC I now see that the trigger command does differ between pause and release. Funny enough, dai_comp_trigger receives command 3 for resume but then, without any extra error trace I get error -22. Will add more traces.
I am doing my own state checking but I suspect it may be wrong.
The FW does check pipeline and component state here, so please make sure any DMA has stopped and set the correct state before the stream is restarted.
I believe one of those checks fails even though I didn't even interact with the code in dai.c (AFAIK, I will check)
What should I look into, and is this actually correct behavior?
There is a state transition diagram in component.h iirc, so best to make sure that pause puts your pipeline in the correct state. I guess that STOP and START work fine ?
STOP and START work fine, barring the occasional IPC timeout issue which is caused by an unrelated problem on my platform.
Will do further checks and remove my manual state management (I trust the state management made by component_set_state even though it probably fails right there). Will reply if I uncover anything else. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...