[PATCH] ASoC: amd: Add support for ALC1015P codec in acp3x machine driver
Add ALC1015p codec support for acp3x machine driver.
Signed-off-by: Vijendar Mukunda Vijendar.Mukunda@amd.com --- sound/soc/amd/Kconfig | 1 + sound/soc/amd/acp3x-rt5682-max9836.c | 46 +++++++++++++++++++++++++++++++++++- 2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig index 256c192..ba5a85b 100644 --- a/sound/soc/amd/Kconfig +++ b/sound/soc/amd/Kconfig @@ -35,6 +35,7 @@ config SND_SOC_AMD_RV_RT5682_MACH select SND_SOC_CROS_EC_CODEC select I2C_CROS_EC_TUNNEL select SND_SOC_RT1015 + select SND_SOC_RT1015P depends on SND_SOC_AMD_ACP3x && I2C && CROS_EC help This option enables machine driver for RT5682 and MAX9835. diff --git a/sound/soc/amd/acp3x-rt5682-max9836.c b/sound/soc/amd/acp3x-rt5682-max9836.c index cea320a..8e11bb8 100644 --- a/sound/soc/amd/acp3x-rt5682-max9836.c +++ b/sound/soc/amd/acp3x-rt5682-max9836.c @@ -275,6 +275,8 @@ SND_SOC_DAILINK_DEF(rt5682, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-10EC5682:00", "rt5682-aif1"))); SND_SOC_DAILINK_DEF(max, DAILINK_COMP_ARRAY(COMP_CODEC("MX98357A:00", "HiFi"))); +SND_SOC_DAILINK_DEF(rt1015p, + DAILINK_COMP_ARRAY(COMP_CODEC("RTL1015:00", "HiFi"))); SND_SOC_DAILINK_DEF(rt1015, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-10EC1015:00", "rt1015-aif"), COMP_CODEC("i2c-10EC1015:01", "rt1015-aif"))); @@ -419,6 +421,43 @@ static struct snd_soc_card acp3x_1015 = { .num_controls = ARRAY_SIZE(acp3x_mc_1015_controls), };
+static const struct snd_soc_dapm_widget acp3x_1015p_widgets[] = { + SND_SOC_DAPM_HP("Headphone Jack", NULL), + SND_SOC_DAPM_MIC("Headset Mic", NULL), + SND_SOC_DAPM_MUX("Dmic Mux", SND_SOC_NOPM, 0, 0, + &acp3x_dmic_mux_control), + SND_SOC_DAPM_SPK("Speakers", NULL), +}; + +static const struct snd_soc_dapm_route acp3x_1015p_route[] = { + {"Headphone Jack", NULL, "HPOL"}, + {"Headphone Jack", NULL, "HPOR"}, + {"IN1P", NULL, "Headset Mic"}, + {"Dmic Mux", "Front Mic", "DMIC"}, + {"Dmic Mux", "Rear Mic", "DMIC"}, + /* speaker */ + { "Speakers", NULL, "Speaker" }, +}; + +static const struct snd_kcontrol_new acp3x_mc_1015p_controls[] = { + SOC_DAPM_PIN_SWITCH("Speakers"), + SOC_DAPM_PIN_SWITCH("Headphone Jack"), + SOC_DAPM_PIN_SWITCH("Headset Mic"), +}; + +static struct snd_soc_card acp3x_1015p = { + .name = "acp3xalc56821015p", + .owner = THIS_MODULE, + .dai_link = acp3x_dai, + .num_links = ARRAY_SIZE(acp3x_dai), + .dapm_widgets = acp3x_1015p_widgets, + .num_dapm_widgets = ARRAY_SIZE(acp3x_1015p_widgets), + .dapm_routes = acp3x_1015p_route, + .num_dapm_routes = ARRAY_SIZE(acp3x_1015p_route), + .controls = acp3x_mc_1015p_controls, + .num_controls = ARRAY_SIZE(acp3x_mc_1015p_controls), +}; + void *soc_is_rltk_max(struct device *dev) { const struct acpi_device_id *match; @@ -435,6 +474,9 @@ static void card_spk_dai_link_present(struct snd_soc_dai_link *links, if (!strcmp(card_name, "acp3xalc56821015")) { links[1].codecs = rt1015; links[1].num_codecs = ARRAY_SIZE(rt1015); + } else if (!strcmp(card_name, "acp3xalc56821015p")) { + links[1].codecs = rt1015p; + links[1].num_codecs = ARRAY_SIZE(rt1015p); } else { links[1].codecs = max; links[1].num_codecs = ARRAY_SIZE(max); @@ -486,6 +528,7 @@ static int acp3x_probe(struct platform_device *pdev) static const struct acpi_device_id acp3x_audio_acpi_match[] = { { "AMDI5682", (unsigned long)&acp3x_5682}, { "AMDI1015", (unsigned long)&acp3x_1015}, + { "AMDP1015", (unsigned long)&acp3x_1015p}, {}, }; MODULE_DEVICE_TABLE(acpi, acp3x_audio_acpi_match); @@ -503,5 +546,6 @@ module_platform_driver(acp3x_audio);
MODULE_AUTHOR("akshu.agrawal@amd.com"); MODULE_AUTHOR("Vishnuvardhanrao.Ravulapati@amd.com"); -MODULE_DESCRIPTION("ALC5682 ALC1015 & MAX98357 audio support"); +MODULE_AUTHOR("Vijendar.Mukunda@amd.com"); +MODULE_DESCRIPTION("ALC5682 ALC1015, ALC1015P & MAX98357 audio support"); MODULE_LICENSE("GPL v2");
static const struct acpi_device_id acp3x_audio_acpi_match[] = { { "AMDI5682", (unsigned long)&acp3x_5682}, { "AMDI1015", (unsigned long)&acp3x_1015},
- { "AMDP1015", (unsigned long)&acp3x_1015p},
This isn't a valid ACPI ID. AMDP does not exist in https://uefi.org/acpi_id_list
There was a similar issue with Intel platforms using this part, we had to use a different HID.
On 3/30/21 7:52 PM, Pierre-Louis Bossart wrote:
static const struct acpi_device_id acp3x_audio_acpi_match[] = { { "AMDI5682", (unsigned long)&acp3x_5682}, { "AMDI1015", (unsigned long)&acp3x_1015}, + { "AMDP1015", (unsigned long)&acp3x_1015p},
This isn't a valid ACPI ID. AMDP does not exist in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuefi.org%2...
There was a similar issue with Intel platforms using this part, we had to use a different HID.
Is it okay if i use "AMDI1016" for ALC1015P?
On Tue, Mar 30, 2021 at 09:12:11PM +0530, Mukunda,Vijendar wrote:
On 3/30/21 7:52 PM, Pierre-Louis Bossart wrote:
static const struct acpi_device_id acp3x_audio_acpi_match[] = { { "AMDI5682", (unsigned long)&acp3x_5682}, { "AMDI1015", (unsigned long)&acp3x_1015}, + { "AMDP1015", (unsigned long)&acp3x_1015p},
This isn't a valid ACPI ID. AMDP does not exist in
...
There was a similar issue with Intel platforms using this part, we had to use a different HID.
Is it okay if i use "AMDI1016" for ALC1015P?
That's valid, though obviously you might regret that later on if someone releases a CODEC with a 1016 name (equally well ACPI being what it is there's no good options for naming).
On 3/30/21 10:35 AM, Mark Brown wrote:
On Tue, Mar 30, 2021 at 09:12:11PM +0530, Mukunda,Vijendar wrote:
On 3/30/21 7:52 PM, Pierre-Louis Bossart wrote:
static const struct acpi_device_id acp3x_audio_acpi_match[] = { { "AMDI5682", (unsigned long)&acp3x_5682}, { "AMDI1015", (unsigned long)&acp3x_1015}, + { "AMDP1015", (unsigned long)&acp3x_1015p},
This isn't a valid ACPI ID. AMDP does not exist in
...
There was a similar issue with Intel platforms using this part, we had to use a different HID.
Is it okay if i use "AMDI1016" for ALC1015P?
That's valid, though obviously you might regret that later on if someone releases a CODEC with a 1016 name (equally well ACPI being what it is there's no good options for naming).
wish granted, the 1016 already exists :-) you may want to align with what we did for Intel and use the same HID: RTL1015
On 3/30/21 9:57 PM, Pierre-Louis Bossart wrote:
On 3/30/21 10:35 AM, Mark Brown wrote:
On Tue, Mar 30, 2021 at 09:12:11PM +0530, Mukunda,Vijendar wrote:
On 3/30/21 7:52 PM, Pierre-Louis Bossart wrote:
static const struct acpi_device_id acp3x_audio_acpi_match[] = { { "AMDI5682", (unsigned long)&acp3x_5682}, { "AMDI1015", (unsigned long)&acp3x_1015}, + { "AMDP1015", (unsigned long)&acp3x_1015p},
This isn't a valid ACPI ID. AMDP does not exist in
...
There was a similar issue with Intel platforms using this part, we had to use a different HID.
Is it okay if i use "AMDI1016" for ALC1015P?
That's valid, though obviously you might regret that later on if someone releases a CODEC with a 1016 name (equally well ACPI being what it is there's no good options for naming).
wish granted, the 1016 already exists :-) you may want to align with what we did for Intel and use the same HID: RTL1015
As per RTK team inputs, "RTL1015" ACPI HID is in use for RT1015p codec driver. RTK team suggested us to use "RTL1015A" as ACPI HID. Let us know, if we can use "RTL1015A" as an ACPI HID?
- Vijendar
static const struct acpi_device_id acp3x_audio_acpi_match[] = { { "AMDI5682", (unsigned long)&acp3x_5682}, { "AMDI1015", (unsigned long)&acp3x_1015}, + { "AMDP1015", (unsigned long)&acp3x_1015p},
This isn't a valid ACPI ID. AMDP does not exist in
...
There was a similar issue with Intel platforms using this part, we had to use a different HID.
Is it okay if i use "AMDI1016" for ALC1015P?
That's valid, though obviously you might regret that later on if someone releases a CODEC with a 1016 name (equally well ACPI being what it is there's no good options for naming).
wish granted, the 1016 already exists :-) you may want to align with what we did for Intel and use the same HID: RTL1015
As per RTK team inputs, "RTL1015" ACPI HID is in use for RT1015p codec driver. RTK team suggested us to use "RTL1015A" as ACPI HID. Let us know, if we can use "RTL1015A" as an ACPI HID?
Not if you want to be compliant. The part ID remains pegged to 4 hex digits, no matter what the vendor ID representation is.
The only solution I can suggest is using the PCI ID 0x1002, ie.
AMDI1015 -> AMD platform with RT1015 10021015 -> AMD platform with RT1015p
Note that it's not only ACPI's fault, other standards also only allow for 16 bits for part IDs, we'd have the same issue with SoundWire.
On 4/5/21 9:54 PM, Pierre-Louis Bossart wrote:
> static const struct acpi_device_id acp3x_audio_acpi_match[] = { > { "AMDI5682", (unsigned long)&acp3x_5682}, > { "AMDI1015", (unsigned long)&acp3x_1015}, > + { "AMDP1015", (unsigned long)&acp3x_1015p},
This isn't a valid ACPI ID. AMDP does not exist in
...
There was a similar issue with Intel platforms using this part, we had to use a different HID.
Is it okay if i use "AMDI1016" for ALC1015P?
That's valid, though obviously you might regret that later on if someone releases a CODEC with a 1016 name (equally well ACPI being what it is there's no good options for naming).
wish granted, the 1016 already exists :-) you may want to align with what we did for Intel and use the same HID: RTL1015
As per RTK team inputs, "RTL1015" ACPI HID is in use for RT1015p codec driver. RTK team suggested us to use "RTL1015A" as ACPI HID. Let us know, if we can use "RTL1015A" as an ACPI HID?
Not if you want to be compliant. The part ID remains pegged to 4 hex digits, no matter what the vendor ID representation is.
The only solution I can suggest is using the PCI ID 0x1002, ie.
AMDI1015 -> AMD platform with RT1015 10021015 -> AMD platform with RT1015p
Note that it's not only ACPI's fault, other standards also only allow for 16 bits for part IDs, we'd have the same issue with SoundWire.
We will modify ACPI ID as "10021015" and upload the patch as v2 version.
participants (4)
-
Mark Brown -
Mukunda,Vijendar -
Pierre-Louis Bossart -
Vijendar Mukunda