[PATCH] ucm2: hdadsp: add basic ucm config
Basic UCM configuration for HDA DSP generic enabling codec playback and capture on both HDA codec and DMIC ports.
Signed-off-by: Mateusz Gorski mateusz.gorski@linux.intel.com --- ucm2/hdadsp/hdadsp.conf | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 ucm2/hdadsp/hdadsp.conf
diff --git a/ucm2/hdadsp/hdadsp.conf b/ucm2/hdadsp/hdadsp.conf new file mode 100644 index 0000000..4e98545 --- /dev/null +++ b/ucm2/hdadsp/hdadsp.conf @@ -0,0 +1,16 @@ +# UCM for Intel CAVS platforms +# For Audio in HDA and DMIC mode + +ValueDefaults { + PlaybackChannels "2" + PlaybackPriority "1" + CaptureChannels "2" + CapturePriority "2" +} + +SectionDefaults [ + cdev "hw:hdadsp" + cset "name='codec0_out mo media0_in mi Switch' 1" + cset "name='media0_out mo codec0_in mi Switch' 1" + cset "name='mch_cap_out mo mch_cap_in mi Switch' 1" +]
Dne 06. 03. 20 v 12:30 Mateusz Gorski napsal(a):
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?
Signed-off-by: Mateusz Gorski mateusz.gorski@linux.intel.com
ucm2/hdadsp/hdadsp.conf | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 ucm2/hdadsp/hdadsp.conf
diff --git a/ucm2/hdadsp/hdadsp.conf b/ucm2/hdadsp/hdadsp.conf new file mode 100644 index 0000000..4e98545 --- /dev/null +++ b/ucm2/hdadsp/hdadsp.conf @@ -0,0 +1,16 @@ +# UCM for Intel CAVS platforms +# For Audio in HDA and DMIC mode
+ValueDefaults {
- PlaybackChannels "2"
- PlaybackPriority "1"
- CaptureChannels "2"
- CapturePriority "2"
+}
Remove PlaybackChannel and Priority defaults. The priorities should be defined in the device section.
+SectionDefaults [
- cdev "hw:hdadsp"
It should be "hw:${CardId}" for ucm2.
- cset "name='codec0_out mo media0_in mi Switch' 1"
- cset "name='media0_out mo codec0_in mi Switch' 1"
- cset "name='mch_cap_out mo mch_cap_in mi Switch' 1"
+]
This file does not define any devices. Does pulseaudio work with this configuration?
Jaroslav
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.
+ValueDefaults { + PlaybackChannels "2" + PlaybackPriority "1" + CaptureChannels "2" + CapturePriority "2" +}
Remove PlaybackChannel and Priority defaults. The priorities should be defined in the device section.
Thanks, moved to device section in v2.
+SectionDefaults [ + cdev "hw:hdadsp"
It should be "hw:${CardId}" for ucm2.
Thanks, applied in v2.
+ cset "name='codec0_out mo media0_in mi Switch' 1" + cset "name='media0_out mo codec0_in mi Switch' 1" + cset "name='mch_cap_out mo mch_cap_in mi Switch' 1" +]
This file does not define any devices. Does pulseaudio work with this configuration?
Devices added in v2. Regarding pulseaudio - are there any guidelines on how to test UCM files with it? These UCM files were writted mainly based on existing ones for other cards. Of course basic tests were made.
Thanks, Mateusz
Dne 13. 03. 20 v 11:59 Gorski, Mateusz napsal(a):
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).
+ValueDefaults { + PlaybackChannels "2" + PlaybackPriority "1" + CaptureChannels "2" + CapturePriority "2" +}
Remove PlaybackChannel and Priority defaults. The priorities should be defined in the device section.
I will check...
Thanks, moved to device section in v2.
+SectionDefaults [ + cdev "hw:hdadsp"
It should be "hw:${CardId}" for ucm2.
Thanks, applied in v2.
+ cset "name='codec0_out mo media0_in mi Switch' 1" + cset "name='media0_out mo codec0_in mi Switch' 1" + cset "name='mch_cap_out mo mch_cap_in mi Switch' 1" +]
This file does not define any devices. Does pulseaudio work with this configuration?
Devices added in v2. Regarding pulseaudio - are there any guidelines on how to test UCM files with it? These UCM files were writted mainly based on existing ones for other cards. Of course basic tests were made.
I wrote an ucm validator:
https://github.com/alsa-project/alsa-tests/tree/master/python/ucm-validator
Just type 'make' in the ucm-validator directory, the alsa-info.sh output should be added to the configs subtree.
The PA should be used latest from gitlab with the volume control and HDMI support.
Jaroslav
Thanks, Mateusz
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
+ValueDefaults { + PlaybackChannels "2" + PlaybackPriority "1" + CaptureChannels "2" + CapturePriority "2" +}
Remove PlaybackChannel and Priority defaults. The priorities should be defined in the device section.
I will check...
Thanks, moved to device section in v2.
+SectionDefaults [ + cdev "hw:hdadsp"
It should be "hw:${CardId}" for ucm2.
Thanks, applied in v2.
+ cset "name='codec0_out mo media0_in mi Switch' 1" + cset "name='media0_out mo codec0_in mi Switch' 1" + cset "name='mch_cap_out mo mch_cap_in mi Switch' 1" +]
This file does not define any devices. Does pulseaudio work with this configuration?
Devices added in v2. Regarding pulseaudio - are there any guidelines on how to test UCM files with it? These UCM files were writted mainly based on existing ones for other cards. Of course basic tests were made.
I wrote an ucm validator:
https://github.com/alsa-project/alsa-tests/tree/master/python/ucm-validator
Just type 'make' in the ucm-validator directory, the alsa-info.sh output should be added to the configs subtree.
The PA should be used latest from gitlab with the volume control and HDMI support.
Jaroslav
Thanks, used the validator on PATCH v2, it pointed out one more thing to be corrected. One thing that I've noticed - there are some problems when validating "included" files, for example:
<skylake-rt286/Hdmi1.conf> <skylake-rt286/Hdmi2.conf>
raise "aconfig.AlsaConfigError: unable to load config" error
Mateusz
Dne 17. 03. 20 v 12:45 Gorski, Mateusz napsal(a):
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, Jaroslav
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
> 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
Hey,
On Tue, 17 Mar 2020, Gorski, Mateusz wrote:
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
btw, this machine driver is also used by SOF, but name is prefixed:
- HDA with DSP and SST FW -> "hda-dsp" as the card name - HDA with DSP and SOF FW -> "sof-hda-dsp" as the card name
And of course without DSP we have also: - HDA no DSP -> "HDA-Intel" as card name
While we try to share what is possible, the topologies will be different for all three, and thus different UCM files are needed.
Br, Kai
Hey,
On Tue, 17 Mar 2020, Gorski, Mateusz wrote:
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
btw, this machine driver is also used by SOF, but name is prefixed:
- HDA with DSP and SST FW -> "hda-dsp" as the card name
- HDA with DSP and SOF FW -> "sof-hda-dsp" as the card name
And of course without DSP we have also:
- HDA no DSP -> "HDA-Intel" as card name
While we try to share what is possible, the topologies will be different for all three, and thus different UCM files are needed.
Br, Kai
UCMs for "sof-hda-dsp" and "HDA-Intel" are already present on the alsa-ucm-conf repo, only the "hda-dsp" one is missing right now. There is also a second e-mail thread with patch adding topology for hda-dsp which is compatible with this UCM configuration.
Thanks, Mateusz
participants (4)
-
Gorski, Mateusz -
Jaroslav Kysela -
Kai Vehmanen -
Mateusz Gorski