On Sun, Dec 23, 2018 at 11:16:31AM +0800, Chen-Yu Tsai wrote:
This sounds like the flush is happening after DMA transfers and/or I2S operations have started, disrupting the order of the audio samples. I think that might be the case since the regcache is synced sequentially, and the FIFO control register is after the enable bits. That would imply that the device is taken out of runtime suspend after the .start_capture or .start_playback callbacks. Not sure if that's the case, but that would mean the bus clocks are still off at this point, and bypassing the cache and updating the bits is basically moot.
I would expect that the device needs to be resumed from suspend before we start actually trying to transfer audio - there is stuff in the ASoC core which is supposed to have appropriate gets but it's possible something is going wrong there.
I think there's something else happening here, but we need to figure it out instead of papering over it with something that "just works" but we don't know why it works.
I agree.