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 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.