> Basic UCM configuration for HDA DSP generic enabling codec playback > and > capture on both HDA codec and DMIC ports.
Could you describe for what Linux driver (source code) is this configuration?
This file is for Intel Skylake SST driver. Information added in v2.
Ok, do we have this code in the vanilla linux kernel? Which .c file? The driver name 'hdadsp' looks suspicious. We usually have a delimiter in the driver name (like sof-hda-dsp).
Yes, it is a part of Skylake driver, "hdadsp" is the name of sound card created on machine when using HDA generic machine driver. This machine driver is made of 2 .c files:
- skl_hda_dsp_common.c - skl_hda_dsp_generic.c
both are located in: sound/soc/intel/boards/
Example on production laptop:
test@test-Swift-SF515-51T:/proc/asound$ cat cards 0 [hdadsp ]: hda-dsp - hda-dsp WL-SwiftSF515_51T-V1.02-Guinness_WL
Ok, I see now. The 'hdadsp' is the user configurable card identification (alias to the card number) not the driver name. The UCM should be in 'hda-dsp' directory. If the UCM validator works for you, it should be corrected.
Could you point me to the alsa-info.sh output for this hardware?
Thank you for the explanation, adjustments are coming in v4. Still, I was able to test ucm's on DUT using "alsaucm -c hdadsp" command and it worked..
I had some problems uploading the output automatically, so done it manually, here's the link:
http://www.alsa-project.org/db/?f=986bf4515b2af1de75d42f2df2f812664fb7ec6e
I also sent a patch adding output to configs subtree in alsa-tests repo.
V4 was tested with ucm-validator, no errors.
Thank you, Jaroslav
Thanks, Mateusz
Is there anything else I could do regarding this change? I think all of the issues/hints were adressed.
Thanks, Mateusz