From: Takashi Iwai <tiwai@suse.de>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
Dom Cobley <dom@raspberrypi.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Subject: Re: Context expectations in ALSA
Date: Thu, 22 Oct 2020 15:31:47 +0200 [thread overview]
Message-ID: <s5h7dribd4s.wl-tiwai@suse.de> (raw)
In-Reply-To: <20201022132412.vntap4kfb2aj24qy@gilmour.lan>
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
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Maxime Ripard <maxime@cerno.tech>
Cc: alsa-devel@alsa-project.org, Dom Cobley <dom@raspberrypi.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
Takashi Iwai <tiwai@suse.com>, Mark Brown <broonie@kernel.org>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Subject: Re: Context expectations in ALSA
Date: Thu, 22 Oct 2020 15:31:47 +0200 [thread overview]
Message-ID: <s5h7dribd4s.wl-tiwai@suse.de> (raw)
In-Reply-To: <20201022132412.vntap4kfb2aj24qy@gilmour.lan>
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
next prev parent reply other threads:[~2020-10-22 13:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 9:50 Context expectations in ALSA Maxime Ripard
2020-10-22 9:50 ` Maxime Ripard
2020-10-22 10:03 ` Jaroslav Kysela
2020-10-22 10:03 ` Jaroslav Kysela
2020-10-22 12:57 ` Maxime Ripard
2020-10-22 12:57 ` Maxime Ripard
2020-10-22 13:20 ` Takashi Iwai
2020-10-22 13:20 ` Takashi Iwai
2020-10-22 13:24 ` Maxime Ripard
2020-10-22 13:24 ` Maxime Ripard
2020-10-22 13:31 ` Takashi Iwai [this message]
2020-10-22 13:31 ` Takashi Iwai
2020-10-22 13:50 ` Mark Brown
2020-10-22 13:50 ` Mark Brown
2020-10-22 15:39 ` Maxime Ripard
2020-10-22 15:39 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5h7dribd4s.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dave.stevenson@raspberrypi.com \
--cc=dom@raspberrypi.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime@cerno.tech \
--cc=nsaenzjulienne@suse.de \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.