On Thu, 22 Oct 2020 15:24:12 +0200, Maxime Ripard wrote:
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.
I see, thanks for clarification.
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
Well, we have to align either to atomic or non-atomic operation. If we want to solve solely in vc4, the fix would be to make the trigger action into some own work.
Takashi