Messages in this thread | | | Subject | Re: [PATCH] ASoC: amd: Add support for ALC1015P codec in acp3x machine driver | From | Pierre-Louis Bossart <> | Date | Mon, 5 Apr 2021 11:24:22 -0500 |
| |
>>>>>> 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.
| |