From: "Cássio Gabriel" <cassiogabrielcontato@gmail.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: Maciej Strozek <mstrozek@opensource.cirrus.com>,
Bard Liao <yung-chuan.liao@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-sound@vger.kernel.org, patches@opensource.cirrus.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: SDCA: Write init table on function status IRQ
Date: Tue, 24 Mar 2026 08:13:01 -0300 [thread overview]
Message-ID: <acJnzC0qrMXcMGEW@ortodist> (raw)
In-Reply-To: <acJXZudDv8JjWrMK@opensource.cirrus.com>
On Tue, Mar 24, 2026 at 09:20:38AM +0000, Charles Keepax wrote:
> On Tue, Mar 24, 2026 at 12:03:59AM -0300, Cássio Gabriel wrote:
> > The function status IRQ handler currently acknowledges
> > SDCA_CTL_ENTITY_0_FUNCTION_NEEDS_INITIALIZATION but does
> > not perform the function initialization writes. Since the
> > handler clears the function status register afterwards,
> > the request is lost.
> >
> > Use sdca_regmap_write_init() when the initialization status
> > bit is reported and apply the writes through the device regmap
> > stored in the IRQ data, matching the existing class-function
> > boot and resume paths.
>
> Generally speaking the init writes should have happened as part
> of the device boot. What are the circumstances where you are
> encountering this?
>
> Thanks,
> Charles
Hi Charles,
This was found by inspection rather than from a concrete hardware
reproducer.
What drew my attention was that the current class-function boot and
resume paths already handle FUNCTION_NEEDS_INITIALIZATION by replaying
the init table, while the function-status IRQ handler would just
acknowledge and clear the same bit. My concern was that, if the bit can
legitimately appear in the normal IRQ path, it would be dropped without
taking the same initialization action.
I do not currently have hardware evidence showing that this case is
actually reachable, so I will drop the patch for now.
Thanks,
Cássio
next prev parent reply other threads:[~2026-03-24 11:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 3:03 [PATCH] ASoC: SDCA: Write init table on function status IRQ Cássio Gabriel
2026-03-24 9:20 ` Charles Keepax
2026-03-24 11:13 ` Cássio Gabriel [this message]
2026-03-24 11:23 ` Charles Keepax
2026-03-25 13:35 ` kernel test robot
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=acJnzC0qrMXcMGEW@ortodist \
--to=cassiogabrielcontato@gmail.com \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=mstrozek@opensource.cirrus.com \
--cc=patches@opensource.cirrus.com \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.dev \
--cc=tiwai@suse.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