Add ALC1015p codec support for acp3x machine driver.
Signed-off-by: Vijendar Mukunda <[email protected]>
---
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("[email protected]");
MODULE_AUTHOR("[email protected]");
-MODULE_DESCRIPTION("ALC5682 ALC1015 & MAX98357 audio support");
+MODULE_AUTHOR("[email protected]");
+MODULE_DESCRIPTION("ALC5682 ALC1015, ALC1015P & MAX98357 audio support");
MODULE_LICENSE("GPL v2");
--
2.7.4
> 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%2Facpi_id_list&data=04%7C01%7CVijendar.Mukunda%40amd.com%7C7406bd8053104c021c6c08d8f3875396%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637527109839548809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WXNykTVcn4tgxIHPsJVXaDf9J5a63c29IMUOhJ3X8LU%3D&reserved=0
>
>
> 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.