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

[alsa-devel] [PATCH v4 0/2] mfd: arizona: add support for INn_MODE register control using platform data
by Inha Song 19 Aug '14

19 Aug '14

This patch series add support for INn_MODE register control using platform data. Each input signal path can be configurated either as a Analogue or Digital using the INn_MODE registers. Changes for v4 - Update document content for more clarity Changes for v3 - Change to use of_property_read_u32_array - Fix a few typos - Update commit message Changes for v2 - Change to support - Update commit message - Update document content for more clarity Inha Song (2): mfd: arizona: Add support for INn_Mode register control mfd: arizona: Update DT binding to support INn_MODE init_data Documentation/devicetree/bindings/mfd/arizona.txt | 7 +++++++ drivers/mfd/arizona-core.c | 8 +++++++- 2 files changed, 14 insertions(+), 1 deletion(-) -- 2.0.0.390.gcb682f8

1 0

[alsa-devel] [PATCH V1 0/3] fix build error/warning in sound/soc/fsl
by Shengjiu Wang 19 Aug '14

19 Aug '14

This series patch is for fixing build error/waring in sound/soc/fsl Shengjiu Wang (3): ASoC: fsl: Kconfig: remove dependence of SND_IMX_SOC for SND_SOC_IMX_PCM_DMA ASoC: fsl-asoc-card: Fix build warning for maybe-uninitialized ASoC: fsl: fsl-asoc-card: Select SND_SOC_IMX_AUDMUX sound/soc/fsl/Kconfig | 9 +++++---- sound/soc/fsl/fsl-asoc-card.c | 9 +++++---- 2 files changed, 10 insertions(+), 8 deletions(-) -- 1.7.9.5

6 17

[alsa-devel] [PATCH 1/2] ALSA: hda/hdmi - set depop_delay for haswell plus
by libin.yang＠intel.com 19 Aug '14

19 Aug '14

From: Libin Yang <libin.yang(a)intel.com> Both Haswell and Broadwell need set depop_delay to 0. So apply this setting to haswell plus. Signed-off-by: Libin Yang <libin.yang(a)intel.com> --- sound/pci/hda/patch_hdmi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 36badba..5e229f7 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2330,9 +2330,8 @@ static int patch_generic_hdmi(struct hda_codec *codec) intel_haswell_fixup_enable_dp12(codec); } - if (is_haswell(codec) || is_valleyview(codec)) { + if (is_haswell_plus(codec) || is_valleyview(codec)) codec->depop_delay = 0; - } if (hdmi_parse_codec(codec) < 0) { codec->spec = NULL; -- 1.9.1

2 2

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

19 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 D3 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> --- V2: move the verb write from led_power_filter to alc269_resume sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index b32ce08..d71270a 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3268,6 +3268,15 @@ static int alc269_resume(struct hda_codec *codec) snd_hda_codec_resume_cache(codec); alc_inv_dmic_sync(codec, true); hda_call_check_power_status(codec, 0x01); + + /* on some machine, the BIOS will clear the codec gpio data when enter + * suspend, and won't restore the data after resume, so we restore it + * in the driver. + */ + if (spec->gpio_led) + snd_hda_codec_write(codec, codec->afg, 0, AC_VERB_SET_GPIO_DATA, + spec->gpio_led); + if (spec->has_alc5505_dsp) alc5505_dsp_resume(codec); -- 1.9.1

2 1

[alsa-devel] [PATCH] ALSA: hda - Set TLV_DB_SCALE_MUTE bit for cx5051 vmaster
by Takashi Iwai 19 Aug '14

19 Aug '14

Conexnat HD-audio driver has a workaround for cx5051 (aka CX20561) chip to add fake mute controls to each amp (commit 3868137e). This implies the minimum-as-mute TLV bit in TLV for each corresponding control. Meanwhile we build the virtual master from these, but the TLV bit is missing, even though the slaves have it. This patch simply adds the missing TLV_DB_SCALE_MUTE bit for vmaster, as already done in patch_sigmatel.c. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_conexant.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 7627a69ca6d7..6f2fa838b635 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -26,6 +26,7 @@ #include <linux/module.h> #include <sound/core.h> #include <sound/jack.h> +#include <sound/tlv.h> #include "hda_codec.h" #include "hda_local.h" @@ -859,6 +860,11 @@ static int patch_conexant_auto(struct hda_codec *codec) if (err < 0) goto error; + if (codec->vendor_id == 0x14f15051) { + /* minimum value is actually mute */ + spec->gen.vmaster_tlv[3] |= TLV_DB_SCALE_MUTE; + } + codec->patch_ops = cx_auto_patch_ops; /* Some laptops with Conexant chips show stalls in S3 resume, -- 2.0.4

2 4

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

19 Aug '14

On Mon, Aug 18, 2014 at 09:58:11AM +0530, Subhransu S. Prusty wrote: > On Thu, Aug 14, 2014 at 02:07:08PM +0100, Mark Brown wrote: > > > 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. > So lets step back and see what is required here. > I get a mixer update for one of the inputs of the mixer. This needs to be > communicated to the DSP via the IPC. But the IPC expects that we send all > the values of all the inputs of a mixer to the DSP. > That is why here we are reading the all mixer inputs to find the values and > send the bitmap of all inputs. > So from the driver if I have to find out what is the value of the inputs in > mixer, how do I do that, is there a simpler way? Or should we push > this/<something else> into framework to query The problem is that it looks like you are reading the value from the control, treating it as a boolean and discarding it.

2 1

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

19 Aug '14

Changes in V2: - Modified the regmap config to const type. - Added ASRC patch. - Followed Rutland's advice. Xiubo Li (5): ASoC: fsl-asrc: Convert to use regmap framework's endianness method. ASoC: fsl-esai: Convert to use regmap framework's endianness method. ASoC: fsl-spdif: 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 | 15 +++++++-------- sound/soc/fsl/fsl_asrc.c | 6 +----- sound/soc/fsl/fsl_esai.c | 5 +---- sound/soc/fsl/fsl_sai.c | 12 ++++-------- sound/soc/fsl/fsl_sai.h | 3 +-- sound/soc/fsl/fsl_spdif.c | 5 +---- 6 files changed, 15 insertions(+), 31 deletions(-) -- 1.8.5

1 5

[alsa-devel] [PATCH v3 2/2] mfd: arizona: Update DT binding to support INn_MODE init_data
by Inha Song 19 Aug '14

19 Aug '14

This patch update DT binding to support INn_MODE init_data. Each input signal path can be configurated either as a Analogue or Digital using the INn_MODE registers. Signed-off-by: Inha Song <ideal.song(a)samsung.com> --- Documentation/devicetree/bindings/mfd/arizona.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 5c7e723..0064b21 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -42,6 +42,14 @@ Optional properties: the chip default will be used. If present exactly five values must be specified. + - wlf,inmode : A list of INn_MODE register values, where n is the number + of input signals. Each input signal path can be configurated either as a + Analogue or Digital using the INn_MODE registers. If absent, INn_MODE + registers set to 0 by default. If present, values must be specified less + than or equal to the number of input singals. If values less than the + number of input signals, elements that has not been specifed are set to 0 + by default. + - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if they are being externally supplied. As covered in Documentation/devicetree/bindings/regulator/regulator.txt -- 2.0.0.390.gcb682f8

2 2

[alsa-devel] [PATCH] ALSA: hda/hdmi - apply Valleyview fix-ups to Cherryview display codec
by libin.yang＠intel.com 19 Aug '14

19 Aug '14

From: Libin Yang <libin.yang(a)intel.com> Valleyview and Cherryview have the same behavior on display audio. So this patch defines is_valleyview_plus() to include codecs for both Valleyview and its successor Cherryview, and apply Valleyview fix-ups to Cherryview. Signed-off-by: Libin Yang <libin.yang(a)intel.com> --- sound/pci/hda/patch_hdmi.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 36badba..99d7d7f 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -50,6 +50,8 @@ MODULE_PARM_DESC(static_hdmi_pcm, "Don't restrict PCM parameters per ELD info"); #define is_haswell_plus(codec) (is_haswell(codec) || is_broadwell(codec)) #define is_valleyview(codec) ((codec)->vendor_id == 0x80862882) +#define is_cherryview(codec) ((codec)->vendor_id == 0x80862883) +#define is_valleyview_plus(codec) (is_valleyview(codec) || is_cherryview(codec)) struct hdmi_spec_per_cvt { hda_nid_t cvt_nid; @@ -1459,7 +1461,7 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo, mux_idx); /* configure unused pins to choose other converters */ - if (is_haswell_plus(codec) || is_valleyview(codec)) + if (is_haswell_plus(codec) || is_valleyview_plus(codec)) intel_not_share_assigned_cvt(codec, per_pin->pin_nid, mux_idx); snd_hda_spdif_ctls_assign(codec, pin_idx, per_cvt->cvt_nid); @@ -1598,7 +1600,8 @@ static bool hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll) * and this can make HW reset converter selection on a pin. */ if (eld->eld_valid && !old_eld_valid && per_pin->setup) { - if (is_haswell_plus(codec) || is_valleyview(codec)) { + if (is_haswell_plus(codec) || + is_valleyview_plus(codec)) { intel_verify_pin_cvt_connect(codec, per_pin); intel_not_share_assigned_cvt(codec, pin_nid, per_pin->mux_idx); @@ -1779,7 +1782,7 @@ static int generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, bool non_pcm; int pinctl; - if (is_haswell_plus(codec) || is_valleyview(codec)) { + if (is_haswell_plus(codec) || is_valleyview_plus(codec)) { /* Verify pin:cvt selections to avoid silent audio after S3. * After S3, the audio driver restores pin:cvt selections * but this can happen before gfx is ready and such selection @@ -2330,9 +2333,8 @@ static int patch_generic_hdmi(struct hda_codec *codec) intel_haswell_fixup_enable_dp12(codec); } - if (is_haswell(codec) || is_valleyview(codec)) { + if (is_haswell_plus(codec) || is_valleyview_plus(codec)) codec->depop_delay = 0; - } if (hdmi_parse_codec(codec) < 0) { codec->spec = NULL; -- 1.9.1

3 2

[alsa-devel] Warning Big Yield
by Joël Krähemann 19 Aug '14

19 Aug '14

I'd really like to know if there's a common way to do syncing applications. What frequencies are required to run a GUI? How does Xorg work and how can I prevent interfering with ALSA output? And what base frequency is recommended to threads? Warning you may experience big yield. please take a look at ags_thread_loop() in: http://sourceforge.net/p/ags/code/HEAD/tree/src/ags/thread/ags_thread-posix…

3 4