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:20:49 +0200 [thread overview]
Message-ID: <s5ha6webdn2.wl-tiwai@suse.de> (raw)
In-Reply-To: <20201022125741.xxibhwgcr2mhxehe@gilmour.lan>
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.
Ideally dmaengine PCM helper should support the nonatomic mode, but
until then, the other side needs to drop the nonatomic flag, I
suppose.
thanks,
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:20:49 +0200 [thread overview]
Message-ID: <s5ha6webdn2.wl-tiwai@suse.de> (raw)
In-Reply-To: <20201022125741.xxibhwgcr2mhxehe@gilmour.lan>
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.
Ideally dmaengine PCM helper should support the nonatomic mode, but
until then, the other side needs to drop the nonatomic flag, I
suppose.
thanks,
Takashi
next prev parent reply other threads:[~2020-10-22 13:21 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 [this message]
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
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=s5ha6webdn2.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.