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.