Re: [PATCH] ASoC: amd: Add support for ALC1015P codec in acp3x machine driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





   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.



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux