From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
<lgirdwood@gmail.com>, <linux-sound@vger.kernel.org>,
<patches@opensource.cirrus.com>
Subject: Re: [PATCH] ASoC: cs42l43: Move shutter IRQ handling into a worker thread
Date: Wed, 31 Jul 2024 09:49:30 +0100 [thread overview]
Message-ID: <Zqn6mgRkjdtkf2ob@opensource.cirrus.com> (raw)
In-Reply-To: <87ikwmoyyw.wl-tiwai@suse.de>
On Wed, Jul 31, 2024 at 08:30:15AM +0200, Takashi Iwai wrote:
> On Wed, 31 Jul 2024 01:20:40 +0200,
> Mark Brown wrote:
> >
> > On Tue, Jul 30, 2024 at 11:47:48PM +0200, Jaroslav Kysela wrote:
> > > On 30. 07. 24 16:44, Mark Brown wrote:
> >
> > > > With some of these slower buses it's not immediately obvious that it's
> > > > worth the bother of caching - the overhead of doing the lookup is
> > > > negligable in the overall context of handling the interrupt.
> >
> > > I don't buy that argument. We should always try to write an optimal code.
> > > Every CPU tick counts.
> >
> > So do the bytes of memory you'd use caching the pointers!
>
> Adding two more works would be even more wastes, that's the beginning
> of the discussion :)
>
> The problem is the order of ASoC component initialization, though;
> AFAIUC, the kcontrols aren't instantiated at the point of component
> probe, hence you can't get kcontrol objects there.
>
I think there probably should be some way to cache the kcontrols,
I will have a look at implementing that. In general I chose the
delayed work as caching didn't obviously seem worth it as Mark notes,
and also the sdw_dev_lock tends to cause a lot of these inversions
and the delayed work is a very safe solution, whereas caching makes
me slightly nervous we will find another inversion at some point.
In general I think that is the actual problem here, the sdw_dev_lock
wraps too much stuff and frequently causes these inversions. Although
fixing that may not be possible and certainly requires a lot of
thinking.
Thanks,
Charles
prev parent reply other threads:[~2024-07-31 8:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 15:59 [PATCH] ASoC: cs42l43: Move shutter IRQ handling into a worker thread Charles Keepax
2024-07-29 16:18 ` Takashi Iwai
2024-07-29 16:44 ` Charles Keepax
2024-07-29 19:30 ` Takashi Iwai
2024-07-30 8:43 ` Charles Keepax
2024-07-30 12:33 ` Takashi Iwai
2024-07-30 14:13 ` Jaroslav Kysela
2024-07-30 14:27 ` Takashi Iwai
2024-07-30 14:44 ` Mark Brown
2024-07-30 21:47 ` Jaroslav Kysela
2024-07-30 23:20 ` Mark Brown
2024-07-31 6:30 ` Takashi Iwai
2024-07-31 8:49 ` Charles Keepax [this message]
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=Zqn6mgRkjdtkf2ob@opensource.cirrus.com \
--to=ckeepax@opensource.cirrus.com \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.de \
/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