From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Mark Brown <broonie@kernel.org>,
linux-rt-users@vger.kernel.org,
Arseniy Krasnov <avkrasnov@salutedevices.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
alsa-devel@alsa-project.org, linux-sound@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
kernel@sberdevices.ru, oxffffaa@gmail.com,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v1] ASoC: meson: axg-fifo: set option to use raw spinlock
Date: Mon, 5 Aug 2024 17:33:09 +0200 [thread overview]
Message-ID: <20240805153309.k_SfHw62@linutronix.de> (raw)
In-Reply-To: <1j1q3cw5ri.fsf@starbuckisacylon.baylibre.com>
On 2024-07-29 17:57:05 [+0200], Jerome Brunet wrote:
> On Mon 29 Jul 2024 at 16:28, Mark Brown <broonie@kernel.org> wrote:
>
> > On Mon, Jul 29, 2024 at 05:06:50PM +0200, Jerome Brunet wrote:
> >> On Mon 29 Jul 2024 at 15:44, Mark Brown <broonie@kernel.org> wrote:
> >
> >> > I don't recall this coming up much TBH. It may be that people just set
> >> > raw spinlocks when they need it, or that there's not many people using
> >> > relevant devices with RT kernels.
> >
> >> I have not been playing much with RT TBH, but AFAIK, with RT irq
> >> handlers are threaded unless IRQF_NO_THREAD is set. In this case,
> >> something preemptible in the handler should not be a problem.
> >
> >> The axg-fifo drivers do not have IRQF_NO_THREAD so something is a bit
> >> unclear here.
> >
> > Yeah, it's definitely likely to happen all the time for people using RT
> > with relevant devices. I'm not sure I have a good sense of if it's
> > likely to be a nasty surprise to switch raw spinlocks on by default when
> > it's currently controllable, I'd expect it'll generally be fine but it's
> > possibly a bit rude to any users that don't use interrupts...
>
> Indeed it is bit radical.
>
> My concern with this patch is that, IIUC, the handler should be
> threaded under RT and there should be no problem with the spinlock API.
>
> Adding the RT folks to try to get a better understanding, they should
> have been CCed anyway.
I'm not sure if making the lock a raw_spinlock_t solves all the
problems. The regmap is regmap_mmio so direct memory-access and looks
simple enough to do so. In regmap_mmio_write() I see clk_enable() and
and this uses a spinlock_t so we should be back at the same problem.
There might be an additional problem if reg-caching is enabled.
Let me propose two alternatives:
#1: Why two handlers if we have IRQF_ONESHOT and the primary does almost
nothing. Assuming the thread is always woken up and the "unexpected
irq" case does not happen. If so, why not:
diff --git a/sound/soc/meson/axg-fifo.c b/sound/soc/meson/axg-fifo.c
index 7e6090af720b9..60af05a3cad6b 100644
--- a/sound/soc/meson/axg-fifo.c
+++ b/sound/soc/meson/axg-fifo.c
@@ -220,9 +220,21 @@ static irqreturn_t axg_fifo_pcm_irq_block(int irq, void *dev_id)
static irqreturn_t axg_fifo_pcm_irq_block_thread(int irq, void *dev_id)
{
struct snd_pcm_substream *ss = dev_id;
+ struct axg_fifo *fifo = axg_fifo_data(ss);
+ unsigned int status;
+
+ regmap_read(fifo->map, FIFO_STATUS1, &status);
+ status = FIELD_GET(STATUS1_INT_STS, status);
+
+ /* Use the thread to call period elapsed on nonatomic links */
+ if (!(status & FIFO_INT_COUNT_REPEAT)) {
+ dev_dbg(axg_fifo_dev(ss), "unexpected irq - STS 0x%02x\n",
+ status);
+ return IRQ_NONE;
+ }
+ axg_fifo_ack_irq(fifo, status);
snd_pcm_period_elapsed(ss);
-
return IRQ_HANDLED;
}
@@ -251,9 +263,9 @@ int axg_fifo_pcm_open(struct snd_soc_component *component,
if (ret)
return ret;
- ret = request_threaded_irq(fifo->irq, axg_fifo_pcm_irq_block,
- axg_fifo_pcm_irq_block_thread,
- IRQF_ONESHOT, dev_name(dev), ss);
+ ret = request_threaded_irq(fifo->irq, NULL,
+ axg_fifo_pcm_irq_block_thread, IRQF_ONESHOT,
+ dev_name(dev), ss);
if (ret)
return ret;
#2: If two handers are required due to $REASON then primary should ACK/
disable the interrupt line while the secondary/ threaded handler is
running. In this is case then IRQF_ONESHOT is not needed because its
"tasks" is performed by the primary handler:
diff --git a/sound/soc/meson/axg-fifo.c b/sound/soc/meson/axg-fifo.c
index 7e6090af720b9..5b4c518eb4ccd 100644
--- a/sound/soc/meson/axg-fifo.c
+++ b/sound/soc/meson/axg-fifo.c
@@ -205,11 +205,16 @@ static irqreturn_t axg_fifo_pcm_irq_block(int irq, void *dev_id)
regmap_read(fifo->map, FIFO_STATUS1, &status);
status = FIELD_GET(STATUS1_INT_STS, status);
- axg_fifo_ack_irq(fifo, status);
/* Use the thread to call period elapsed on nonatomic links */
- if (status & FIFO_INT_COUNT_REPEAT)
+ if (status & FIFO_INT_COUNT_REPEAT) {
+ /*
+ * ACKs/ Disables the interrupt until re-enabled by
+ * axg_fifo_pcm_irq_block_thread()
+ */
+ axg_fifo_ack_irq(fifo, status);
return IRQ_WAKE_THREAD;
+ }
dev_dbg(axg_fifo_dev(ss), "unexpected irq - STS 0x%02x\n",
status);
@@ -253,7 +258,7 @@ int axg_fifo_pcm_open(struct snd_soc_component *component,
ret = request_threaded_irq(fifo->irq, axg_fifo_pcm_irq_block,
axg_fifo_pcm_irq_block_thread,
- IRQF_ONESHOT, dev_name(dev), ss);
+ 0, dev_name(dev), ss);
if (ret)
return ret;
On the PREEMPT_RT both handler will be threaded.
My favorite is #1. Also ACKing the interrupt only if it occurred for the
device/ driver in charge. Otherwise don't care…
Sebastian
next prev parent reply other threads:[~2024-08-05 15:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 13:16 [PATCH v1] ASoC: meson: axg-fifo: set option to use raw spinlock Arseniy Krasnov
2024-07-29 14:15 ` Jerome Brunet
2024-07-29 14:44 ` Mark Brown
2024-07-29 15:06 ` Jerome Brunet
2024-07-29 15:28 ` Mark Brown
2024-07-29 15:57 ` Jerome Brunet
2024-08-05 15:33 ` Sebastian Andrzej Siewior [this message]
2024-08-05 16:07 ` Jerome Brunet
2024-08-06 6:50 ` Sebastian Andrzej Siewior
2024-08-06 9:21 ` Jerome Brunet
2024-08-06 10:03 ` Sebastian Andrzej Siewior
2024-08-05 16:56 ` Mark Brown
2024-08-06 6:57 ` Sebastian Andrzej Siewior
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=20240805153309.k_SfHw62@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=alsa-devel@alsa-project.org \
--cc=avkrasnov@salutedevices.com \
--cc=broonie@kernel.org \
--cc=jbrunet@baylibre.com \
--cc=kernel@sberdevices.ru \
--cc=khilman@baylibre.com \
--cc=lgirdwood@gmail.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=neil.armstrong@linaro.org \
--cc=oxffffaa@gmail.com \
--cc=perex@perex.cz \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).