Found that the loop only occurs when the SAI driver is also in, and also Daniel just told me as I got to work today that tweaking the various memory region sizes has an effect on whether the bug manifests or not.
I will investigate today.
Right now, the only thing I'm getting in etrace is the failure to enable DMA trace (which is benign, I didn't push any implementation for that with my Dummy DMA driver) but no other issues.
Don't pointer updates happen via IPC (which on our platform is putting the message in the mailbox and giving an interrupt to the ARM core via the MU) anyway?
Also on the buggy version whenever I do Ctrl-C on the aplay I get continuous ipc_period_elapsed messages on a null runtime (of course, the DSP did not receive the STOP and RESET triggers for some reason and it keeps trying to play -- and I'm getting silence in my headphones).
I think I'll try to look into the MU driver (i.MX IPC implementation) on both sides and see why I'm getting issues. This is really fishy.
-----Original Message----- From: Liam Girdwood liam.r.girdwood@linux.intel.com Sent: Thursday, October 17, 2019 8:26 PM To: Paul Olaru paul.olaru@nxp.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] How does one debug IPC errors?
On Wed, 2019-10-16 at 15:57 +0000, Paul Olaru wrote:
Right now I'm still working on the ESAI SOF driver. Based on the current branch I'm getting an out of memory issue. Solved by increasing the system runtime heap, not a real problem even if a surprising one to me, will probably send the fix together with the ESAI driver.
However, I'm getting a second issue: Whenever I'm trying to play anything I see the etrace log filled with "ipc: msg hdr for 0x600a0000 not found replace 0" and playback doesn't progress. Also in another weirder circumstance (invalid aplay followed by a valid one) I heard it play but for some reason the host buffer was copied only at odd times (and I heard the same 64k or 16384 samples many times over instead of once).
Seems like the pointer is not being updated. ALSA wont copy more periods and the buffer will repeat.
You can either update the pointer via IPC or update via mailbox (preferred).
How should I continue investigating this issue?
(also due to a failed stop - kernel reported IPC timeout for 0x60050000 and 0x60030000, I'm still getting the issues for 0x600a0000 in a continuous loop on the firmware side, about the time it would take to normally play those samples; until reboot I cannot send any other commands to the DSP either).
Looks like your DMA or I2S driver may be looping forever ? Possible in IRQ context if no other work can be scheduled ?
Also, should I send the current state of the ESAI driver, even if there is a little more cleanup that needs to be done on it? Now that I cannot reliably test it anymore.
We can wait until you have fixed this issue.
Liam
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...