[alsa-devel] [PATCH 0/2] Introduce dmic mode switch delay parameter

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20181024/858516fa/attachment.sig>