From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Cc: broonie@kernel.org, lgirdwood@gmail.com,
yung-chuan.liao@linux.intel.com, peter.ujfalusi@linux.intel.com,
linux-sound@vger.kernel.org, patches@opensource.cirrus.com
Subject: Re: [PATCH 1/3] ASoC: SDCA: Add correct masks whilst reporting SDCA jack status
Date: Wed, 29 Apr 2026 14:10:13 +0100 [thread overview]
Message-ID: <afIDNXrQ23Cja0vm@opensource.cirrus.com> (raw)
In-Reply-To: <cb90c6dd-5976-4aef-92c4-e7f6b91fda90@linux.dev>
On Tue, Apr 28, 2026 at 10:18:17PM +0200, Pierre-Louis Bossart wrote:
> On 4/27/26 13:59, Charles Keepax wrote:
> > Currently, all SDCA jacks simply report against a mask of 0xFFFF. This
> > works fine for system with a single SDCA jack control as the status
> > reflects that single control at all times. However, if two SDCA
> > jack controls exist in the system, such as a separate representation for
> > input and output, then the second control can cancel reports from the
> > other since it will only report its relevant bits and zero in all other
> > slots. This is exactly what the mask is for.
> >
> > Build up a mask using all the possible states for an SCDA jack control
> > at registration time and use that mask when reporting a particular jack.
> > It is worth noting this still doesn't handle cases such as two headphone
> > jacks as that would require separate ALSA jacks to report to.
>
> I couldn't quite get the last sentence. If you have two
> functions for separate headphones, where would you have a
> conflict?
For the SDCA side this is fine, as in we create our controls
there is enough to distinguish everything.
> Don't you have separate ALSA jacks created independently by
> each function?
For the ALSA jack side we still have a jack object being created at
the machine driver level. Primarily because the existing jack
APIs require a card pointer. There is certainly an argument to
pull this into the class driver itself, such as we did for the
mic and speaker widgets. Doing so would let us support even more
topologies however that is definitely a bigger piece of work.
But either way this change is helpful we should really mask for
the bits we are reporting.
Thanks,
Charles
next prev parent reply other threads:[~2026-04-29 13:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 11:59 [PATCH 0/3] Improve SDCA support for duplicated features Charles Keepax
2026-04-27 11:59 ` [PATCH 1/3] ASoC: SDCA: Add correct masks whilst reporting SDCA jack status Charles Keepax
2026-04-28 20:18 ` Pierre-Louis Bossart
2026-04-29 13:10 ` Charles Keepax [this message]
2026-04-30 8:11 ` Pierre-Louis Bossart
2026-04-27 11:59 ` [PATCH 2/3] ASoC: SDCA: Remove sdca_function_data duplication Charles Keepax
2026-04-27 23:25 ` Mark Brown
2026-04-27 11:59 ` [PATCH 3/3] ASoC: SDCA: Support devices with multiple functions of identical type Charles Keepax
2026-04-27 23:27 ` Mark Brown
2026-04-28 8:26 ` Charles Keepax
2026-04-30 8:09 ` [PATCH 0/3] Improve SDCA support for duplicated features Pierre-Louis Bossart
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=afIDNXrQ23Cja0vm@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=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--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