From: Akihiko Odaki <akihiko.odaki@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
Jaroslav Kysela <perex@perex.cz>,
Oder Chiou <oder_chiou@realtek.com>,
Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH] ASoC: rt5682: Add jack kcontrol
Date: Fri, 8 Apr 2022 01:11:22 +0900 [thread overview]
Message-ID: <f86a10e1-b5a7-5c59-8e53-cec65d97234b@gmail.com> (raw)
In-Reply-To: <Yk8Ktyyt0veW4g+j@sirena.org.uk>
On 2022/04/08 1:00, Mark Brown wrote:
> On Fri, Apr 08, 2022 at 12:46:04AM +0900, Akihiko Odaki wrote:
>> On 2022/04/08 0:09, Mark Brown wrote:
>
>>> Why not use DAPM for the jack? Note that normally the jack is part of
>>> the machine driver not the CODEC - there's no way the CODEC can know how
>>> it's been wired in on any given system.
>
>> It seems it is an unsual case where the codec knows the source of the jack.
>> RT5682 has interrupts and registers for the jack; see e.g.
>> rt5682_button_detect in sound/soc/codecs/rt5682.c for details.
>
> That bit is very common but there's still machine specific aspects - is
> the required hardware wired up, if it is wired up how exactly are things
> wired (separate microphone jack, headset jack, one of many jacks?). A
> lot of the machine driver part of things is about labeling things so
> that it can be displayed in a way that's easy to connect to the physical
> system. Generally the machine driver would define a jack and then
> connect the CODEC to it.
Whether the required hardware wired is told from the user of the codec
via jack's type specified with snd_soc_card_jack_new(). The other
details live in the codec.
next prev parent reply other threads:[~2022-04-07 16:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 14:13 [PATCH] ASoC: rt5682: Add jack kcontrol Akihiko Odaki
2022-04-07 15:09 ` Mark Brown
2022-04-07 15:46 ` Akihiko Odaki
2022-04-07 16:00 ` Mark Brown
2022-04-07 16:11 ` Akihiko Odaki [this message]
2022-04-07 16:37 ` Mark Brown
2022-04-07 17:16 ` Akihiko Odaki
2022-04-07 17:27 ` 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=f86a10e1-b5a7-5c59-8e53-cec65d97234b@gmail.com \
--to=akihiko.odaki@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oder_chiou@realtek.com \
--cc=perex@perex.cz \
/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