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