lkml.org 
[lkml]   [2021]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ASoC: amd: Add support for ALC1015P codec in acp3x machine driver
From
Date


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

\
 
 \ /
  Last update: 2021-04-05 21:10    [W:0.062 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site