> > > 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
