On Tue, Oct 23, 2018 at 01:22:18PM -0500, Pierre-Louis Bossart wrote: > ok, but not sure what to define. You don't want too many identifiers either, > this generated lots of patches for no good reason. What are the needs here? > You probably don't want to identify the DMIC vendor so this could be an > Intel-defined ID. But I wonder if this might be reused on AMD platforms? There's nothing stopping AMD systems using the Intel device IDs. We already get some of that with the other non-Intel components that have been assigned Intel IDs due to their presence on Intel reference systems. > Changing the dailink to point to one device instead of another is not a good > idea, the machine driver should be independent from all this, and be > reusable between the SKL driver or SOF drivers. The last thing you want is a > hack in there. The firmware binding really ought to be OS neutral, never mind driver neutral :( > ok, makes sense. Do you think it'd be possible to use ACPI initrd overlays > to add support for those parameters if they don't natively exist in the > BIOS? Don't know about that (I'm not familiar enough with how this stuff gets shipped on x86 systems) but the traditionl solution for ACPI appears to be to have DMI based quirks.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
