Allowing some timing adjustments for the clock transitions is a good thing. The way it's done is questionable and raises a number of concerns.
First, there was an Intel internal discussion before my extended break on why this 'dmic-codec' is needed on Intel platforms. To the best of my knowledge we don't control the mics with GPIOs, which was the initial purpose of this driver. We have experimental evidence on ApolloLake and GeminiLake that using the soc-dummy/soc-dummy-dai definitions are enough, and it may be a good thing to agree on the direction here. If you want a parameter, you can still use a machine driver DMI-based kernel quirk and/or pass a kernel parameter, the need to extend this dmic-codec is far from obvious to me.
The driver already exposes another parameter (wakeup-delay-ms) using device tree. Enabling ACPI device enumeration provides a way to pass existing parameter and also cover the new parameter(modeswitch_delay_ms) introduced in this patch set. Isn't it good to adopt ACPI enumeration if the driver has multiple parameters to handle?
Assuming you still want to use this codec, then there are still major concerns about the ACPI directions. As Mark noted it, "DMIC" does not follow any of the guidelines or accepted definitions with an unambiguous vendor and part ID. We know we already have conflicts between Intel-defined ACPI IDs, e.g. for RT298 on multiple platforms, let's be careful here, shall we?
Agree, need to find proper ACPI ID for the device.
And I am coming to my last point. The Skylake driver already contains code to create the dmic devices by hand (see below the git grep results). So I wonder what happens if you use both ACPI-based enumeration AND manually create the dmic device - I view these solutions as mutually incompatible. Either you have not tested against the upstream code or something is missing from your patchset. What am I missing?
Skl driver already registers a DMIC (dmic-codec) device and with ACPI enumeration one more device (DMIC:00) gets registered. The snd_soc_dai_link structure populated in the machine driver decides which codec device to be used in the capture path and there by handles the compatibility issue you pointed out.
I forgot to add another open on ACPI support: what would be the scope of the "DMIC" device? With ACPI we typically have a parent-child relationship, e.g. we put audio codec below the relevant I2C/SPI controller in the DSDT definitions. In the absence of a DMIC bus, you need to be careful how the DMIC device is added in the DSDT - it'd likely need to be below the scope of the HDaudio controller.
In DSDT, the device is added under the Intel HDA (1f.3 for SKL/KBL) parent device.
-Jenny