From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Shenghao Ding <shenghao-ding@ti.com>, tiwai@suse.de
Cc: robh+dt@kernel.org, lgirdwood@gmail.com, perex@perex.cz,
kevin-lu@ti.com, 13916275206@139.com,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
liam.r.girdwood@intel.com, mengdong.lin@intel.com,
baojun.xu@ti.com, thomas.gfeller@q-drop.com, peeyush@ti.com,
navada@ti.com, broonie@kernel.org, gentuser@gmail.com,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v3 2/2] ALSA: hda/tas2781: Add tas2781 HDA driver
Date: Fri, 18 Aug 2023 11:00:34 -0500 [thread overview]
Message-ID: <4c1b44b5-995a-fac7-a72b-89b8bf816dd2@linux.intel.com> (raw)
In-Reply-To: <20230818085558.1431-2-shenghao-ding@ti.com>
The first patch in this series has the same commit title as the second
one, can this be updated with a more meaningful description of the two
patches?
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 44fccfb93cff..ba1b02ed184a 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -6721,7 +6721,7 @@ static void comp_generic_playback_hook(struct hda_pcm_stream *hinfo, struct hda_
> }
> }
>
> -struct cs35l41_dev_name {
> +struct scodec_dev_name {
you are changing things in patch_realtek.c that are completely unrelated
to the tas2781, usually the recommendation is that the changes have to
be part of a different patch so that the real addition of tas2781 parts
are easier to review.
> const char *bus;
> const char *hid;
> int index;
> @@ -6730,7 +6730,7 @@ struct cs35l41_dev_name {
> /* match the device name in a slightly relaxed manner */
> static int comp_match_cs35l41_dev_name(struct device *dev, void *data)
> {
> - struct cs35l41_dev_name *p = data;
> + struct scodec_dev_name *p = data;
> const char *d = dev_name(dev);
> int n = strlen(p->bus);
> char tmp[32];
> @@ -6746,12 +6746,32 @@ static int comp_match_cs35l41_dev_name(struct device *dev, void *data)
> return !strcmp(d + n, tmp);
> }
>
> +static int comp_match_tas2781_dev_name(struct device *dev,
> + void *data)
> +{
> + struct scodec_dev_name *p = data;
> + const char *d = dev_name(dev);
> + int n = strlen(p->bus);
> + char tmp[32];
> +
> + /* check the bus name */
> + if (strncmp(d, p->bus, n))
> + return 0;
> + /* skip the bus number */
> + if (isdigit(d[n]))
> + n++;
> + /* the rest must be exact matching */
> + snprintf(tmp, sizeof(tmp), "-%s:00", p->hid);
ACPI can sometimes add :01 suffixes, this looks like the re-invention of
an ACPI helper?
Adding Andy for the ACPI review.
> +
> + return !strcmp(d + n, tmp);
> +}
> +
> static void cs35l41_generic_fixup(struct hda_codec *cdc, int action, const char *bus,
> const char *hid, int count)
> {
> struct device *dev = hda_codec_dev(cdc);
> struct alc_spec *spec = cdc->spec;
> - struct cs35l41_dev_name *rec;
> + struct scodec_dev_name *rec;
> int ret, i;
>
> switch (action) {
> @@ -6779,6 +6799,41 @@ static void cs35l41_generic_fixup(struct hda_codec *cdc, int action, const char
> }
> }
>
> +static void tas2781_generic_fixup(struct hda_codec *cdc, int action,
> + const char *bus, const char *hid)
> +{
> + struct device *dev = hda_codec_dev(cdc);
> + struct alc_spec *spec = cdc->spec;
> + struct scodec_dev_name *rec;
> + int ret;
> +
> + switch (action) {
> + case HDA_FIXUP_ACT_PRE_PROBE:
> + rec = devm_kmalloc(dev, sizeof(*rec), GFP_KERNEL);
> + if (!rec)
> + return;
> + rec->bus = bus;
> + rec->hid = hid;
> + rec->index = 0;
> + spec->comps[0].codec = cdc;
> + component_match_add(dev, &spec->match,
> + comp_match_tas2781_dev_name, rec);
> + ret = component_master_add_with_match(dev, &comp_master_ops,
> + spec->match);
> + if (ret)
> + codec_err(cdc,
> + "Fail to register component aggregator %d\n",
> + ret);
> + else
> + spec->gen.pcm_playback_hook =
> + comp_generic_playback_hook;
> + break;
> + case HDA_FIXUP_ACT_FREE:
This is the first use of FIXUP_ACT_FREE in this function, is this
required/intentional?
> + component_master_del(dev, &comp_master_ops);
Also is there a need to test that the PRE_PROBE actually worked?
> + break;
> + }
> +}
> +
> static void cs35l41_fixup_i2c_two(struct hda_codec *cdc, const struct hda_fixup *fix, int action)
> {
> cs35l41_generic_fixup(cdc, action, "i2c", "CSC3551", 2);
> @@ -6806,6 +6861,12 @@ static void alc287_fixup_legion_16ithg6_speakers(struct hda_codec *cdc, const st
> cs35l41_generic_fixup(cdc, action, "i2c", "CLSA0101", 2);
> }
>
> +static void tas2781_fixup_i2c(struct hda_codec *cdc,
> + const struct hda_fixup *fix, int action)
> +{
> + tas2781_generic_fixup(cdc, action, "i2c", "TIAS2781");
TI ACPI ID is TXNW
https://uefi.org/ACPI_ID_List?search=TEXAS
There's also a PNP ID PXN
https://uefi.org/PNP_ID_List?search=TEXAS
"TIAS" looks like an invented identifier. It's not uncommon but should
be recorded with a comment if I am not mistaken.
> +}
> +
> /* for alc295_fixup_hp_top_speakers */
> #include "hp_x360_helper.c"
>
> @@ -7231,6 +7292,7 @@ enum {
> ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS,
> ALC236_FIXUP_DELL_DUAL_CODECS,
> ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI,
> + ALC287_FIXUP_TAS2781_I2C,
> };
>
> /* A special fixup for Lenovo C940 and Yoga Duet 7;
> @@ -9309,6 +9371,12 @@ static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC269_FIXUP_THINKPAD_ACPI,
> },
> + [ALC287_FIXUP_TAS2781_I2C] = {
> + .type = HDA_FIXUP_FUNC,
> + .v.func = tas2781_fixup_i2c,
> + .chained = true,
> + .chain_id = ALC269_FIXUP_THINKPAD_ACPI,
If this is part of the THINKPAD chain, should this fixup name also refer
to THINKPAD, as e.g. ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI
next prev parent reply other threads:[~2023-08-18 16:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-18 8:55 [PATCH v3 1/2] ALSA: hda/tas2781: Add tas2781 HDA driver Shenghao Ding
2023-08-18 8:55 ` [PATCH v3 2/2] " Shenghao Ding
2023-08-18 16:00 ` Pierre-Louis Bossart [this message]
2023-08-18 17:01 ` Andy Shevchenko
2023-08-20 9:16 ` Takashi Iwai
2023-08-21 9:06 ` Andy Shevchenko
2023-08-21 9:14 ` Takashi Iwai
2023-08-21 9:26 ` Andy Shevchenko
2023-08-18 16:30 ` [PATCH v3 1/2] " Pierre-Louis Bossart
2023-08-20 9:35 ` Takashi Iwai
2023-08-21 14:43 ` Pierre-Louis Bossart
2023-08-21 14:57 ` Takashi Iwai
2023-08-21 15:04 ` Pierre-Louis Bossart
-- strict thread matches above, loose matches on Subject: below --
2023-08-17 8:26 Shenghao Ding
2023-08-17 8:26 ` [PATCH v3 2/2] " Shenghao Ding
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=4c1b44b5-995a-fac7-a72b-89b8bf816dd2@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=13916275206@139.com \
--cc=alsa-devel@alsa-project.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=baojun.xu@ti.com \
--cc=broonie@kernel.org \
--cc=gentuser@gmail.com \
--cc=kevin-lu@ti.com \
--cc=lgirdwood@gmail.com \
--cc=liam.r.girdwood@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mengdong.lin@intel.com \
--cc=navada@ti.com \
--cc=peeyush@ti.com \
--cc=perex@perex.cz \
--cc=robh+dt@kernel.org \
--cc=shenghao-ding@ti.com \
--cc=thomas.gfeller@q-drop.com \
--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