Hi Takashi, On Thu, Oct 22, 2020 at 03:20:49PM +0200, Takashi Iwai wrote: > On Thu, 22 Oct 2020 14:57:41 +0200, > Maxime Ripard wrote: > > > > On Thu, Oct 22, 2020 at 12:03:19PM +0200, Jaroslav Kysela wrote: > > > Dne 22. 10. 20 v 11:50 Maxime Ripard napsal(a): > > > > > > > So, I'm not really sure what I'm supposed to do here. The drivers > > > > involved don't appear to be doing anything extraordinary, but the issues > > > > lockdep report are definitely valid too. What are the expectations in > > > > terms of context from ALSA when running the callbacks, and how can we > > > > fix it? > > > > > > I think that you should set the non-atomic flag and wake up the workqueue or > > > so from interrupt handler in this case. Call snd_pcm_period_elapsed() from the > > > workqueue not the interrupt handler context. > > > > Yeah, that was my first guess too. However, the DMA driver uses some > > kind of generic helpers using a tasklet, so getting rid of it would take > > some work and would very likely not be eligible for stable. > > Who sets the nonatomic flag for vc4? I couldn't find the relevant > code in the latest upstream. Sorry if this wasn't clear enough, it's not there at the moment, ALSA takes a spinlock and lockdep complains that we're sleeping in an atomic context. I tried to add the nonatomic flag in my tree to see if it was fixing the issue, but ran into another lockdep complain now with ALSA taking a mutex in a tasklet. > Ideally dmaengine PCM helper should support the nonatomic mode, but > until then, the other side needs to drop the nonatomic flag, I > suppose. In this case, I'm not sure the blame is in the PCM helper but if there's any blame, I guess it's the virt-chan layer inside dmaengine (so for providers) that use a tasklet instead of something that allows sleeping Maxime
Attachment:
signature.asc
Description: PGP signature
