November 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 2/2] ASoC: topology: Only free TLV for volume mixers of a widget
by mengdong.lin＠linux.intel.com 05 Dec '16

05 Dec '16

From: Mengdong Lin <mengdong.lin(a)linux.intel.com> This patch will check the type of embedded controls for a widget, and only free the TLV of volume mixers. Bytes controls don't have TLV. Just free the private value which is used as struct soc_mixer_control for volume mixers or soc_bytes_ext for bytes controls. No need to cast to these types before freeing it. Signed-off-by: Mengdong Lin <mengdong.lin(a)linux.intel.com> diff --git a/include/sound/soc-topology.h b/include/sound/soc-topology.h index d318fe4..86c884a 100644 --- a/include/sound/soc-topology.h +++ b/include/sound/soc-topology.h @@ -53,7 +53,7 @@ struct snd_soc_dobj_control { /* dynamic widget object */ struct snd_soc_dobj_widget { - unsigned int kcontrol_enum:1; /* this widget is an enum kcontrol */ + unsigned int kcontrol_type; /* kcontrol type: mixer, enum, bytes */ }; /* generic dynamic object - all dynamic objects belong to this struct */ diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index 63e1a50..11feb19 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -489,7 +489,7 @@ static void remove_widget(struct snd_soc_component *comp, * Dynamic Widgets either have 1..N enum kcontrols or mixers. * The enum may either have an array of values or strings. */ - if (dobj->widget.kcontrol_enum) { + if (dobj->widget.kcontrol_type == SND_SOC_TPLG_TYPE_ENUM) { /* enumerated widget mixer */ for (i = 0; i < w->num_kcontrols; i++) { struct snd_kcontrol *kcontrol = w->kcontrols[i]; @@ -506,16 +506,21 @@ static void remove_widget(struct snd_soc_component *comp, } kfree(w->kcontrol_news); } else { - /* non enumerated widget mixer */ + /* volume mixer or bytes controls */ for (i = 0; i < w->num_kcontrols; i++) { struct snd_kcontrol *kcontrol = w->kcontrols[i]; - struct soc_mixer_control *sm = - (struct soc_mixer_control *) kcontrol->private_value; - kfree(w->kcontrols[i]->tlv.p); + if (dobj->widget.kcontrol_type + == SND_SOC_TPLG_TYPE_MIXER) + kfree(kcontrol->tlv.p); - snd_ctl_remove(card, w->kcontrols[i]); - kfree(sm); + snd_ctl_remove(card, kcontrol); + + /* Private value is used as struct soc_mixer_control + * for volume mixers or soc_bytes_ext for bytes + * controls. + */ + kfree((void *)kcontrol->private_value); } kfree(w->kcontrol_news); } @@ -1439,6 +1444,7 @@ static int soc_tplg_dapm_widget_create(struct soc_tplg *tplg, struct snd_soc_dapm_widget template, *widget; struct snd_soc_tplg_ctl_hdr *control_hdr; struct snd_soc_card *card = tplg->comp->card; + unsigned int kcontrol_type; int ret = 0; if (strnlen(w->name, SNDRV_CTL_ELEM_ID_NAME_MAXLEN) == @@ -1494,6 +1500,7 @@ static int soc_tplg_dapm_widget_create(struct soc_tplg *tplg, case SND_SOC_TPLG_CTL_VOLSW_XR_SX: case SND_SOC_TPLG_CTL_RANGE: case SND_SOC_TPLG_DAPM_CTL_VOLSW: + kcontrol_type = SND_SOC_TPLG_TYPE_MIXER; /* volume mixer */ template.num_kcontrols = w->num_kcontrols; template.kcontrol_news = soc_tplg_dapm_widget_dmixer_create(tplg, @@ -1508,7 +1515,7 @@ static int soc_tplg_dapm_widget_create(struct soc_tplg *tplg, case SND_SOC_TPLG_DAPM_CTL_ENUM_DOUBLE: case SND_SOC_TPLG_DAPM_CTL_ENUM_VIRT: case SND_SOC_TPLG_DAPM_CTL_ENUM_VALUE: - template.dobj.widget.kcontrol_enum = 1; + kcontrol_type = SND_SOC_TPLG_TYPE_ENUM; /* enumerated mixer */ template.num_kcontrols = w->num_kcontrols; template.kcontrol_news = soc_tplg_dapm_widget_denum_create(tplg, @@ -1519,6 +1526,7 @@ static int soc_tplg_dapm_widget_create(struct soc_tplg *tplg, } break; case SND_SOC_TPLG_CTL_BYTES: + kcontrol_type = SND_SOC_TPLG_TYPE_BYTES; /* bytes control */ template.num_kcontrols = w->num_kcontrols; template.kcontrol_news = soc_tplg_dapm_widget_dbytes_create(tplg, @@ -1555,6 +1563,7 @@ static int soc_tplg_dapm_widget_create(struct soc_tplg *tplg, } widget->dobj.type = SND_SOC_DOBJ_WIDGET; + widget->dobj.widget.kcontrol_type = kcontrol_type; widget->dobj.ops = tplg->ops; widget->dobj.index = tplg->index; kfree(template.sname); -- 2.5.0

3 2

[alsa-devel] [PATCH 0/2] ASoC: cq93vc: enable compiling on COMPILE_TEST
by Kuninori Morimoto 05 Dec '16

05 Dec '16

Hi Lee, Mark Current cq93vc sound codec indicates that it has MFD_DAVINCI_VOICECODEC dependency, but it doesn't. This means we can compile it from non DAVINCE environment by COMPILE_TEST. These patches solve this issue. I tested this on ARCH=x86 + make allyesconfig, and ARCH=ARM + shmobile_defconfig + COMPILE_TEST. Kuninori Morimoto (2): mfd: davinci_voicecodec: tidyup header difinitions ASoC: cq93vc: remove MFD_DAVINCI_VOICECODEC dependency for CQ0093VC drivers/mfd/davinci_voicecodec.c | 1 + include/linux/mfd/davinci_voicecodec.h | 4 ---- sound/soc/codecs/Kconfig | 2 +- 3 files changed, 2 insertions(+), 5 deletions(-) -- 1.9.1

3 9

[alsa-devel] [PATCH 0/3 v1] usb-misc fix
by Jiada Wang 05 Dec '16

05 Dec '16

This patch set contains the following patches Andreas Pape (1): ALSA: usb-audio: more tolerant packetsize Daniel Girnus (1): ALSA: usb-audio: avoid setting of sample rate multiple times on bus Mark Craske (1): ALSA: usb-audio: fix race in snd_usb_endpoint_stop sound/usb/endpoint.c | 24 ++++++++++++++++-------- sound/usb/pcm.c | 21 +++++++++++---------- 2 files changed, 27 insertions(+), 18 deletions(-) -- 2.9.3

4 22

[alsa-devel] [PATCH v3 0/3] ucm: Add support for component devices
by mengdong.lin＠linux.intel.com 02 Dec '16

02 Dec '16

From: Mengdong Lin <mengdong.lin(a)linux.intel.com> Sound cards are defined by machines. And off-soc codecs and DSPs embedded in DSP can be taken as the components and resued by different machines/ sound cards. This series allows codec and SOC vendors to install UCM configuration files for a specific codec or DSP, and sound card verb files can include these conf files of components. Component devices will not be exposed to applications for backward compatibility. So audio servers like PulseAudio and CRAS still only see the machine devices. History: v2: Use an array to define component directories. Document syntax to enable/disable a component device. Hide cdev defined by the parent device in ucm manager for executing a component sequence. v3: No longer use macros for UCM manager to enter/exit component domain, to make code simpler. Mengdong Lin (3): ucm: Skip component directories when scanning sound card configuration files ucm: Parse sequence of component devices ucm: Execute sequence of component devices src/ucm/main.c | 78 +++++++++++++++++++++++++- src/ucm/parser.c | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++- src/ucm/ucm_local.h | 19 +++++++ src/ucm/utils.c | 1 + 4 files changed, 249 insertions(+), 3 deletions(-) -- 2.7.4

3 5

[alsa-devel] [alsa-utils] alsaucm should come with a man page
by Antonio Ospite 02 Dec '16

02 Dec '16

Hi, I used alsaucm to test mixer use cases for an Intel Baytrail tablet, I wanted to use bare alsa before bringing pulseaudio in, and it took some time to get my head around it. The output from the "alsaucm --help" is too terse, I had to look at the alsa-lib code[1] to see the possible IDENTIFIERs, and even then it was not clear to me that some operations, like for instance "list _devices", can only work after setting a _verb in the same _execution_, for instance this sequence doesn't work: # alsaucm -c bytcr-rt5640 set _verb HiFi # alsaucm -c bytcr-rt5640 list _devices But this command does: # alsaucm -c bytcr-rt5640 -b - <<EOM set _verb HiFi list _devces EOM Now that I know something more it makes sense: UCM just operates on mixer settings, it does not have its own external state. However, my point is that a man page explaining these things can make the life easier to new users. It would be better if alsa/UCM developers wrote the man page, but if no one steps up I guess I could draft a first version myself. Thanks, Antonio [1] http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

3 9

[alsa-devel] [PATCH v5 1/2] ASoC: samsung: Add DT bindings documentation for TM2 sound subsystem
by Sylwester Nawrocki 01 Dec '16

01 Dec '16

This patch adds DT binding documentation for Exnos5433 based TM2 and TM2E boards sound subsystem. Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> Acked-by: Rob Herring <robh(a)kernel.org> --- Changes since v4: - indentation changes. Changes since v2: - none. Changes since initial version: - dropped clocks, clock-names properties, instead properties from the CODEC node will be used, - property renames: 'samsung,model' -> 'model', 'samsung,i2s-controller' -> 'i2s-controller', 'samsung,speaker-amplifier' -> 'audio-amplifier', - added 'audio-codec' property. --- .../bindings/sound/samsung,tm2-audio.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt new file mode 100644 index 0000000..94442e5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt @@ -0,0 +1,38 @@ +Samsung Exynos5433 TM2(E) audio complex with WM5110 codec + +Required properties: + + - compatible : "samsung,tm2-audio" + - model : the user-visible name of this sound complex + - audio-codec : the phandle of the wm5110 audio codec node, + as described in ../mfd/arizona.txt + - i2s-controller : the phandle of the I2S controller + - audio-amplifier : the phandle of the MAX98504 amplifier + - samsung,audio-routing : a list of the connections between audio components; + each entry is a pair of strings, the first being the + connection's sink, the second being the connection's + source; valid names for sources and sinks are the + WM5110's and MAX98504's pins and the jacks on the + board: HP, SPK, Main Mic, Sub Mic, Third Mic, + Headset Mic + - mic-bias-gpios : GPIO pin that enables the Main Mic bias regulator + + +Example: + +sound { + compatible = "samsung,tm2-audio"; + audio-codec = <&wm5110>; + i2s-controller = <&i2s0>; + audio-amplifier = <&max98504>; + mic-bias-gpios = <&gpr3 2 0>; + model = "wm5110"; + samsung,audio-routing = + "HP", "HPOUT1L", + "HP", "HPOUT1R", + "SPK", "SPKOUT", + "SPKOUT", "HPOUT2L", + "SPKOUT", "HPOUT2R", + "Main Mic", "MICBIAS2", + "IN1R", "Main Mic"; +}; -- 1.9.1

4 8

[alsa-devel] [PATCH v3 0/3][RFC] ASoC: Component has suspend/resume support
by Kuninori Morimoto 01 Dec '16

01 Dec '16

Hi Mark, Lars-Peter These patches are v3+RFC of Component level suspend/resume support. I'm waiting Vinod's cleanup patch which will remove "codec_dev_list" from Intel drivers. But until then, I would like to get review about v3 patch. This v3 patch-set is still modifing Intel's driver at this point, but final/official v3 patchset will doesn't have it, because it will be based on Vinod's cleanup patch. Kuninori Morimoto (3): ASoC: core: replace codec_dev_list to component_dev_list on Card ASoC: core: replace aux_comp_list to component_dev_list ASoC: add Component level suspend/resume include/sound/soc.h | 16 +++--- sound/soc/intel/boards/broadwell.c | 16 +++--- sound/soc/intel/boards/cht_bsw_rt5672.c | 16 +++--- sound/soc/soc-core.c | 90 ++++++++++++++++++++------------- 4 files changed, 85 insertions(+), 53 deletions(-) -- 1.9.1

2 7

[alsa-devel] [PATCH v4 0/4] ASoC: intel: atom: Add FW version information
by Sebastien Guiriec 01 Dec '16

01 Dec '16

This patch series is adding FW version information of SST. Version is both log as dev_info and sysfs entry. Update since V1: - sysfs entry is set to "FW not yet loaded" in case we do not have loaded the FW once Update since V2: - Add Vinod ack. https://www.spinics.net/lists/alsa-devel/msg56521.html Update since V3: - Add sysfs entry description. Sebastien Guiriec (4): ASoC: intel: atom: Add debug information related to FW version ASoC: Intel: atom: save FW version ASoC: Intel: atom: Add sysfs entry in order to store FW version Documentation: ABI: Add ASoC Intel SST Atom sysfs description Documentation/ABI/testing/sysfs-platform-sst-atom | 18 +++++++++++ sound/soc/intel/atom/sst/sst.c | 39 +++++++++++++++++++++++ sound/soc/intel/atom/sst/sst.h | 1 + sound/soc/intel/atom/sst/sst_ipc.c | 10 +++++- 4 files changed, 67 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-sst-atom -- 2.9.3 --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 8

[alsa-devel] [PATCH v3 0/2] ALSA controls management using index/device/sub-devices fields
by Arnaud Pouliquen 01 Dec '16

01 Dec '16

V3: I changed "RFC" prefix to "PATCH", hoping that patchset is enough mature in term of code and discussions, to be considered as a potential patch... Previous discussions summary: - topic of the patchset: Patch concerns ASoc DAI drivers. Aim is to be able to instantiate PCM control using device field according to the associated PCM char device. For this, a relationship between DAIs PCM control and PCM char device needs to be establish. => Proposal is to add field in DAI driver struct to declare PCM controls that need to be linked to PCM character device on DAI link probing. - Limitation of the patchset: This patchset seems only a first step as 2 concerns are been highlighted: - Patch is limited to "static" DAI-link. This not responds to backend (no_pcm dai links) and some none-DAI codecs, that could register PCm controls. In theses cases it is not possible to establish relationship during probe. => No solution proposed for time beeing. - This patchset does not fix conflict of 2 "identical" PCM controls declared by 2 drivers. For instance, a conflict can exist between a PCM control created in DAI driver and the same control declared in a codec driver. As index field is forced to 0, prefix should be used in codec. => To discuss solution in a separate thread as issue already present without this patchset several approaches seem possible like using index field ( control auto indexation in ASoC) or prefix in Naming. Changes: - [PATCH v3 1/2] ASoC: core: allow DAI PCM controls bound to PCM device Code optimization based on Takashi Sakamoto suggestion - [RFC V2 3/3] ASoC: hdmi-codec: Example of PCM control bound to PCM device for multi patch suppressed as it was send as example in previous version. Patch is valid but can have impact on existing drivers as control device field value is updated - [PATCH v3 2/2] ASoC: sti: bind pcm controls to pcm device. No change vs V2 V2: http://www.spinics.net/lists/alsa-devel/msg57045.html Aim of this version is to continue discussion on DAI PCM control focused on ASoC drivers. In this V2 implementation in Soc-core is simplified to limit impact on existing code. Update of the RFC V1 based on discussions: - [RFC 4/4] iecset: allow to select control with device and sub-device numbers no more part of the RFC V2, will be discussed in a separate thread - [RFC 2/4] ALSA: control: increment index field for duplicated control. no more part of the RFC V2, no more need as RFC subject is PCM controls - [RFC V2 1/3] ASoC: core: allow DAI PCM controls bound to PCM device Patch reworked from V1 to simplify implementation - Binding is not done for Dai links tagged with no_pcm (DPCM). - no more possibility to add the controls after the DAI link probing. - [RFC V2 2/3] ASoC: sti: bind PCM controls to PCM device. - [RFC V2 3/3] ASoC: hdmi-codec: Example of PCM control bound to PCM device for multi Example of implementation in STI DAI driver and HDMI-codec drivers V1: http://www.spinics.net/lists/alsa-devel/msg56479.html 1) Alsa-utils patch - iecset: allow to select control with device and sub-device numbers This patch allows to access to 2 iec controls differentiated by device/sub-devices numbers => For me, this patch is mandatory to be able to address the ASoC IEC controls, in case of no fix is implemented to allows index field update in ASoC. 2) Alsa driver patches - ASoC: core: allow PCM control binding to PCM device Add relationship between DAIs PCM controls and PCM device. - ALSA: control: increment index field for duplicated control. Generic implementation of the patch proposed in HDA driver (http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b…) - ASoC: sti: use bind_pcm_ctl implementation of bind_pcm_ctl for sti driver. Arnaud Pouliquen (2): ASoC: core: allow DAI PCM controls bound to PCM device ASoC: sti: bind pcm controls to pcm device. include/sound/soc-dai.h | 4 ++++ sound/soc/soc-core.c | 28 ++++++++++++++++++++++++++++ sound/soc/sti/sti_uniperif.c | 33 ++++----------------------------- 3 files changed, 36 insertions(+), 29 deletions(-) -- 1.9.1

4 11

[alsa-devel] [PATCH] ASoC: rt5670: Enable Braswell platform workaround for Dell Wyse 3040
by Takashi Iwai 01 Dec '16

01 Dec '16

Dell Wyse 3040 requires the platform workaround for enabling dmic and jack detection as defined for Braswell CRB. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- I guess the platform data should be applied generically to all CHT machines instead of DMI matching? DMI matching doesn't scale, obviously. sound/soc/codecs/rt5670.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/codecs/rt5670.c b/sound/soc/codecs/rt5670.c index 98c7efbc6ee0..97bafac3bc15 100644 --- a/sound/soc/codecs/rt5670.c +++ b/sound/soc/codecs/rt5670.c @@ -2827,6 +2827,13 @@ static const struct dmi_system_id dmi_platform_intel_braswell[] = { DMI_MATCH(DMI_BOARD_NAME, "Braswell CRB"), }, }, + { + .ident = "Dell Wyse 3040", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Wyse 3040"), + }, + }, {} }; -- 2.10.2

3 5