On Wed, Feb 22, 2023 at 07:39:45PM +0800, Chancel Liu wrote: Doing a 100ms busy wait in atomic context does not seem like a great idea, never mind a 1.5s one. This shouldn't be done in trigger, it needs to be done later - digital_mute() might be a better time to hook in, though longer delays like this are really quite bad.
Yes, such long time delay in driver is very bad. But this device requires waiting some time before able to output audio. We have to wait otherwise the beginning data may be lost.
It's not just that it's doing this in the driver, it's doing it in the trigger() function which runs in atomic context. That's unreasonable.
The power up to audio out timing occurs after MCLK, BCLK and MUTE=1 are ready. I added the delay in trigger() because some CPU DAI drivers enable BCLK in trigger(). You suggested moving the delay to digital_mute(). It seems digital_mute() is called before cpu_dai->trigger. Please correct me if I'm wrong.
Hrm, right - in any case, it needs to be somewhere that isn't atomic context.
OK. I will keep PATCH 1 and PATCH 3.
For PATCH 2 and PATCH 4, I have to find a better way in which long time delay can be avoided in atomic context.
Thank you very much for your comments.
Regards, Chancel Liu