August 2014 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [v4 05/12] ASoC: Intel: mrfld: add bytes control for modules
by Subhransu S. Prusty 18 Aug '14

18 Aug '14

On Mon, Aug 18, 2014 at 11:06:09AM +0530, Subhransu S. Prusty wrote: > On Wed, Aug 13, 2014 at 09:00:12PM +0100, Mark Brown wrote: > > On Mon, Aug 04, 2014 at 03:15:56PM +0530, Subhransu S. Prusty wrote: > > > > > From: Vinod Koul <vinod.koul(a)intel.com> > > > > > +static int sst_algo_bytes_ctl_info(struct snd_kcontrol *kcontrol, > > > + struct snd_ctl_elem_info *uinfo) > > > +{ > > > + struct sst_algo_control *bc = (void *)kcontrol->private_value; > > > + struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); > > > + > > > + uinfo->type = SNDRV_CTL_ELEM_TYPE_BYTES; > > > + uinfo->count = bc->max; > > > + > > > + /* allocate space to cache the algo parameters in the driver */ > > > + if (bc->params == NULL) { > > > + bc->params = devm_kzalloc(component->dev, bc->max, GFP_KERNEL); > > > + if (bc->params == NULL) > > > + return -ENOMEM; > > > + } > > > + return 0; > > > +} > > > > I wouldn't expect an info call to be allocating anything - why is it > > doing that? It's not looking at the alocated data except to see if the > > allocation succeeded. What happens if someone manages to do a get or > > set without having first done an info and why aren't we doing any > > allocation on initialisation? > > Will move after control initialization. As I have to initialize the params, and if it's done in probe after control creation, it's required to iterate over the controls list and match certain pattern to find the control and then initialize. This doesn't look elegant. Instead I would prefer adding an init callback in the control to do this operation. What do you recommend? --

1 0

[alsa-devel] [PATCH] ALSA: hda - restore the gpio led after resume
by Hui Wang 18 Aug '14

18 Aug '14

On some HP laptops, the mute led is controlled by codec gpio. When some machine resume from s3/s4, the codec gpio data will be cleared to 0 by BIOS: Before suspend: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 After resume: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 To skip the AFG node to enter S3 can't fix this problem. A workaround is to restore the gpio data when the system resume back from s3/s4. It is safe even on the machines without this problem. BugLink: https://bugs.launchpad.net/bugs/1358116 Tested-by: Franz Hsieh <franz.hsieh(a)canonical.com> Cc: stable(a)vger.kernel.org Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index b32ce08..9c49bf5 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3432,6 +3432,12 @@ static unsigned int led_power_filter(struct hda_codec *codec, (nid != spec->mute_led_nid && nid != spec->cap_mute_led_nid)) return power_state; + if (nid == codec->afg && power_state == AC_PWRST_D0 && spec->gpio_led) { + snd_hda_codec_write(codec, codec->afg, 0, AC_VERB_SET_GPIO_DATA, + spec->gpio_led); + return power_state; + } + /* Set pin ctl again, it might have just been set to 0 */ snd_hda_set_pin_ctl(codec, nid, snd_hda_codec_get_pin_target(codec, nid)); -- 1.9.1

3 2

[alsa-devel] [PATCH 0/4] Convert to use regmap framework's endianness method.
by Xiubo Li 18 Aug '14

18 Aug '14

Xiubo Li (4): ASoC: fsl-spdif: Convert to use regmap framework's endianness method. ASoC: fsl-esai: Convert to use regmap framework's endianness method. ASoC: fsl-sai: Convert to use regmap framework's endianness method. ASoC: fsl-sai: rename big_endian_data to is_msb_first. Documentation/devicetree/bindings/sound/fsl-sai.txt | 16 ++++++++-------- sound/soc/fsl/fsl_esai.c | 3 --- sound/soc/fsl/fsl_sai.c | 10 +++------- sound/soc/fsl/fsl_sai.h | 3 +-- sound/soc/fsl/fsl_spdif.c | 3 --- 5 files changed, 12 insertions(+), 23 deletions(-) -- 1.8.5

1 4

[alsa-devel] [v4 00/12] Add mrfld DSP topology and widgets
by Subhransu S. Prusty 18 Aug '14

18 Aug '14

This patch series adds DPCM and DAPM widgets to handle DSP topology in the SST platform driver for merrifield. Changes in v4: Removed print messages for kzalloc failure as per review comments from Takashi. Subhransu S. Prusty (2): ASoC: Intel: mrfld: set private data for cpu-dai ASoC: Export dapm_kcontrol_get_value Vinod Koul (10): ASoC: Intel: mfld-pcm: add FE and BE ops ASoC: intel: mfld-pcm: don't call trigger ops to DSP for internal streams ASoC: Intel: add mrfld DSP defines ASoC: Intel: mrfld: add bytes control for modules ASoC: Intel: mrfld: add the gain controls ASoC: Intel: mfld-pcm: add control for powering up/down dsp ASoC: Intel: mrfld: add DSP core controls ASoC: Intel: mrfld: add the DSP DAPM widgets ASoC: Intel: mfld-pcm: add the fe & be dai ops ASoC: Intel: mrfld: add the DSP mixers include/sound/soc-dapm.h | 1 + sound/soc/intel/Makefile | 3 +- sound/soc/intel/sst-atom-controls.c | 1256 +++++++++++++++++++++++++++++++ sound/soc/intel/sst-atom-controls.h | 844 ++++++++++++++++++++- sound/soc/intel/sst-mfld-platform-pcm.c | 192 ++++- sound/soc/intel/sst-mfld-platform.h | 8 + sound/soc/soc-dapm.c | 3 +- 7 files changed, 2269 insertions(+), 38 deletions(-) create mode 100644 sound/soc/intel/sst-atom-controls.c -- 1.9.0

3 27

Re: [alsa-devel] [v4 10/12] ASoC: Intel: mrfld: add the DSP DAPM widgets
by Mark Brown 18 Aug '14

18 Aug '14

On Thu, Aug 14, 2014 at 03:51:56PM +0530, Subhransu S. Prusty wrote: > On Wed, Aug 13, 2014 at 09:14:54PM +0100, Mark Brown wrote: > > On Mon, Aug 04, 2014 at 03:16:01PM +0530, Subhransu S. Prusty wrote: > > > + pr_debug("%s: widget = %s\n", __func__, w->name); > > > + for (i = 0; i < w->num_kcontrols; i++) { > > > + if (dapm_kcontrol_get_value(w->kcontrols[i])) { > > > + mc = (struct soc_mixer_control *)(w->kcontrols[i])->private_value; > > > + val |= 1 << mc->shift; > > > + } > > > + } > > All my concerns about this still stand - using something called > > _get_value() to do something other than read the control value (which > > this does - it uses it as a boolean then does something else to read the > > value) which doesn't seem good. > I think this can be optimized. This need a bit of rework in the code, but > need to check. But this would need an assumption that the controls are > created in order. > for (i = 0; i < w->num_kcontrols; i++) { > if (dapm_kcontrol_get_value(w->kcontrols[i])) { > val |= 1 << i; > } > Is this ok? No, that doesn't seem safe. Why not read the data from the control - if we were calling a function which returned the value that'd be much clearer.

2 1

Re: [alsa-devel] [PATCH] ASoC: Intel: Add merrifield machine driver
by Mark Brown 18 Aug '14

18 Aug '14

On Sun, Aug 17, 2014 at 07:50:28PM +0530, Subhransu S. Prusty wrote: > On Tue, Aug 12, 2014 at 10:48:22PM +0100, Mark Brown wrote: > > Look at what wm8994_vmid_mode() does... > If I understand correctly need to move this enabling/disabling of VMID > to wm8994_vmid_mode(). No, it's exactly what wm8994_vmid_mode() is there to do already - putting the device into WM8994_VMID_FORCE forces VMID on.

2 1

[alsa-devel] [PATCH 0/6] Fix `sparse` warnings
by Lars-Peter Clausen 17 Aug '14

17 Aug '14

This patch series contains a set of fixes for warnings generated by the sparse tool when building the ASoC tree. None of them are critical and the generated code before and after the patch is the same in all cases. The reason for still fixing them is that it makes it easier to recognize new and potentially serious warnings/errors. With this series applied at least on x86 and ARM a allyesconfig on the ASoC tree builds almost without errors or warnings from sparse. The only remaining warnings are the following two: sound/soc/soc-core.c:108:25: warning: Variable length array is used. sound/soc/soc-core.c:109:29: warning: Variable length array is used. These are part of the legacy ASoC IO code that is deprecated and schedulded for removal in the near future so there is not too much motivation for fixing them. - Lars Lars-Peter Clausen (6): ASoC: edma-pcm: Include edma-pcm.h ASoC: odrodix2_max98090: Make non exported symbols static ASoC: rcar: Use && instead of & for boolean expressions ASoC: sh: Fix dma direction type ASoC: samsung idma: Add proper annotation for casting iomem pointers ASoC: ab8500-codec: Drop bank prefix from AB8500_GPIO_DIR4_REG register define sound/soc/codecs/ab8500-codec.c | 11 +++++------ sound/soc/davinci/edma-pcm.c | 2 ++ sound/soc/samsung/idma.c | 4 ++-- sound/soc/samsung/odroidx2_max98090.c | 4 ++-- sound/soc/sh/fsi.c | 7 ++++++- sound/soc/sh/rcar/gen.c | 2 +- 6 files changed, 18 insertions(+), 12 deletions(-) -- 1.8.0

2 12

Re: [alsa-devel] [PATCH] ASoC: Intel: Add merrifield machine driver
by Mark Brown 17 Aug '14

17 Aug '14

On Tue, Aug 12, 2014 at 11:36:09AM +0530, Subhransu S. Prusty wrote: > On Tue, Jul 29, 2014 at 08:50:43PM +0100, Mark Brown wrote: > > On Thu, Jul 17, 2014 at 05:43:45PM +0530, Subhransu S. Prusty wrote: > > > + /* Force enable VMID to avoid cold latency constraints */ > > > + snd_soc_dapm_force_enable_pin(&card->dapm, "VMID"); > > > + snd_soc_dapm_sync(&card->dapm); > > This looks like you're open coding a version of wm8994_vmid_mode(). > > Though that might need some tuning for systems that really have no > > single ended outputs. > VMID has a larget settling time. Keep it ON here to avoid the delay. Any > better way of doing this? Look at what wm8994_vmid_mode() does...

2 1

[alsa-devel] [PATCH] ASoC: dmic: Add to SND_SOC_ALL_CODECS
by Lars-Peter Clausen 17 Aug '14

17 Aug '14

Improve build coverage of the dmic driver. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/codecs/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 8838838e..e514e98 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -56,6 +56,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_DA7213 if I2C select SND_SOC_DA732X if I2C select SND_SOC_DA9055 if I2C + select SND_SOC_DMIC select SND_SOC_BT_SCO select SND_SOC_ISABELLE if I2C select SND_SOC_JZ4740_CODEC -- 1.8.0

2 1

[alsa-devel] [PATCH] ASoC: Use dev_set_name() instead of init_name
by Lars-Peter Clausen 17 Aug '14

17 Aug '14

init_name is basically a hack and should only be used for statically allocated device structs. For dynamically allocated devices dev_set_name() should be used. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/soc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index d4bfd4a..889f4e3 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1325,7 +1325,7 @@ static int soc_post_component_init(struct snd_soc_pcm_runtime *rtd, device_initialize(rtd->dev); rtd->dev->parent = rtd->card->dev; rtd->dev->release = rtd_release; - rtd->dev->init_name = name; + dev_set_name(rtd->dev, "%s", name); dev_set_drvdata(rtd->dev, rtd); mutex_init(&rtd->pcm_mutex); INIT_LIST_HEAD(&rtd->dpcm[SNDRV_PCM_STREAM_PLAYBACK].be_clients); -- 1.8.0

2 1