> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
