Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
	lgirdwood@gmail.com, broonie@kernel.org
Cc: linux-sound@vger.kernel.org, kai.vehmanen@linux.intel.com,
	yung-chuan.liao@linux.intel.com, yuhsuan@google.com
Subject: Re: [PATCH] ASoC: SOF: Use high-priority workqueue for PCM period elapsed
Date: Mon, 3 Aug 2026 12:13:18 +0200	[thread overview]
Message-ID: <dceba070-0304-4d08-bf11-acafd63270ae@linux.dev> (raw)
In-Reply-To: <ff12793e-1afa-449b-a19b-5c6f0cfbdb94@linux.intel.com>


>> Could it be that the level of priority should be configurable (Kconfig,
>> sysfs, kernel parameter) to let distros pick what they need?
> 
> I guess, it could, but what about the graphic, network, touchscreen,
> etc? Should they all have the same way to select?
> 
> I think audio is a bit special among devices, if there is a slight
> scheduling delay it will be noticeable.
> 
> Not saying that we should not look for other cases where it would make
> noticeable difference, but using high_pri workqueue is not uncommon
> among audio drivers where the period elapsed must be handled by a work
> for a reason.

if you do a search this workqueue is actually used only 10 times in the
entire sound/ directory

https://github.com/search?q=repo%3Athesofproject%2Flinux+path%3Asound%2F+system_highpri_wq&type=code

Again I am not disagreeing that audio is 'special', just that there's no
real precedent for this move and that deciding unilaterally what's high
priority without looking at the rest of the system is a bit problematic.

Anyways, case closed since the patch is merged...

  reply	other threads:[~2026-08-03 10:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 13:04 [PATCH] ASoC: SOF: Use high-priority workqueue for PCM period elapsed Peter Ujfalusi
2026-07-31  9:20 ` Pierre-Louis Bossart
2026-07-31  9:31   ` Péter Ujfalusi
2026-07-31 12:19     ` Pierre-Louis Bossart
2026-07-31 13:04       ` Péter Ujfalusi
2026-08-03 10:13         ` Pierre-Louis Bossart [this message]
2026-07-31 22:21 ` Mark Brown

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=dceba070-0304-4d08-bf11-acafd63270ae@linux.dev \
    --to=pierre-louis.bossart@linux.dev \
    --cc=broonie@kernel.org \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-sound@vger.kernel.org \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=yuhsuan@google.com \
    --cc=yung-chuan.liao@linux.intel.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