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

[alsa-devel] [PATCH 0/1] HDSPM RME RayDAT sync reporting
by Adrian Knoth 07 Nov '12

07 Nov '12

Hi! This patch is supposed to be applied on top of my recent series of patches (60e952bdb537c72dea4484711c9cc00383f78393). Cheers Adrian Knoth (1): ALSA: hdspm - Fix sync check reporting on RME RayDAT sound/pci/rme9652/hdspm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.10.4

2 4

[alsa-devel] Fix for Asus G75 notebook subwoofer
by Massimo Del Fedele 07 Nov '12

07 Nov '12

This code fixes surround path of asus G75; i'll drop here as a function to be called before codec initialization (I did it in static int patch_vt2002P() ) because I don't know how to detect the notebook and apply it only when needed (I'm new to alsa code). /* Fixes for Asus G75 subwoofer pin 24 is marked as speaker by bios -- should mark as line pin 33 has a wrong connection to out-of-range nid #3e */ static int fix_asus_g75_subwoofer(struct hda_codec *codec) { /* right connection to pin widget #33 */ hda_nid_t conn[8] = {0x1c}; unsigned int conf; /* Fix connection of pin widget #33 on VT1802p * reported connection (33-1e) refers to non-existent widget #1e which in turn * reports a connection to #1c; we skip nonexistent 1e widget landing directly * on 1c one */ snd_hda_override_conn_list(codec, 0x33, 1, conn); // pin 24 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX connection to avoid to be taken by autoparser as a speaker conf = snd_hda_codec_get_pincfg(codec, 0x24); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x24, conf); // pin 33 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX, not AC_JACK_PORT_NONE as in bios conf = snd_hda_codec_get_pincfg(codec, 0x33); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x33, conf); return 0; } I guess that the fix on NID #33 should be applied anyways on VT1802p, because by now it connects to a non-existing widget (well, it does exist but is not documented and out of NID range; it should be a stereo-to-mono mixer). BTW, also NID #34, which has 2 connections, has one of them to non-existing nid above; in my case it does no harm : Widget #24 -- ANALOG STEREO PIN COMPLEX Input from widgets : 14 3e <-- widget 3e is out of range, but connects to 1c widget Connection type : JACK Device : LINE OUT Does NOT support unsolicited response Out amp present In amp NOT present Ciao Max

3 23

Re: [alsa-devel] [PATCH -next] ASoC: cs42l52: fix the return value of cs42l52_set_fmt()
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 08:38:35PM +0800, Wei Yongjun wrote: > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > Fix the return value of cs42l52_set_fmt() when clock inversion is > not allowed and also remove the useless variable ret. Applied, but you need to work on your changelogs: What is wrong with the return value? > u8 iface = 0; > > switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { > @@ -822,7 +821,7 @@ static int cs42l52_set_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt) > case SND_SOC_DAIFMT_NB_IF: > break; > default: > - ret = -EINVAL; > + return -EINVAL; > } > cs42l52->config.format = iface; > snd_soc_write(codec, CS42L52_IFACE_CTL1, cs42l52->config.format); > This doesn't look like it changes the return value... the actual issue here is that we don't pay attention to ret later on, we just always return 0.

1 0

[alsa-devel] [PATCH] ASoC: bells: Correct type in sub speaker DAI name for WM5102
by Charles Keepax 07 Nov '12

07 Nov '12

Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/bells.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c index 3d7ace7..b135de0 100644 --- a/sound/soc/samsung/bells.c +++ b/sound/soc/samsung/bells.c @@ -287,7 +287,7 @@ static struct snd_soc_dai_link bells_dai_wm5102[] = { { .name = "Sub", .stream_name = "Sub", - .cpu_dai_name = "wm5110-aif3", + .cpu_dai_name = "wm5102-aif3", .codec_dai_name = "wm9081-hifi", .codec_name = "wm9081.1-006c", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF -- 1.7.2.5

2 1

Re: [alsa-devel] [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 03:30:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > the one via ASoC for the driver with the pinctrl for now but MUST add it later > the arch/arm related via AT91 tree where the pinctrl is mandatory in the dtsi > I'm no going to spend hours to do the pinctrl to test Bo patch that he is > supposed to have deon to test this code > As basically today on DT none of the board will work if BO does no provide the > pinctrl so for me he MUST put in the dtsi > is it ok with you? Or add the pinmux bindings for other IPs over in the pinmux branch and the pinmux binding for SSC here (which will help with bisection as the DT bindings for the audio will then always exist in conjunction with the .dtsi changes for them). Either way is fine with me; I'll leave things as they are until I see some new patches. Though I have to say now that I look in -next it's a bit surprising that there are so many IPs in the file that have no pinmix configuration, based on what you're saying it seems like the entire board will be falling over with the pinmux code anyway - in the case of the sam9g20ek we'd at least need I2C pinmux settings. I may be misunderstanding.

1 0

Re: [alsa-devel] [PATCH] ASoC: wm0010: Split out the firmware file parsing from the boot.
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 12:44:29PM +0000, Scott Ling wrote: > Move the firmware load and record parsing functionality out into > a separate function from the boot function. This still doesn't apply. What are you generating these against? Code for upstream should be generated against the current upstream...

1 0

[alsa-devel] commit: dpcm: Allow FE to be opened without valid BE routes
by anish kumar 07 Nov '12

07 Nov '12

Commit 3ac3f5ca91afc03587b1d2d642f126efc5be37ca ASoC: dpcm: Allow FE to be opened without valid BE routes. if (dpcm_path_get(fe, stream, &list) <= 0) { - dev_warn(fe->dev, "asoc: %s no valid %s route\n", + dev_dbg(fe->dev, "asoc: %s no valid %s route\n", fe->dai_link->name, stream ? "capture" : "playback"); - mutex_unlock(&fe->card->mutex); - return -EINVAL; } As I can see this commit has changed the log level from dev_warn to dev_dbg but this has caused a subtle problem.Right now we rely on this warning to find out issues related to "application not sending UCM commands causing mute issues".Sometimes we have seen that the device becomes mute due to application not sending UCM command properly and these issues are hard to reproduce(all we get is dump).So all we have is this log to find out if the FE(front-end) and BE(back-end) has at-lease matched or not and most of the time it doesn't and we find out that using this very log. With this gone it would be difficult to find out the problem.I don't see any harm in reverting it back to dev_warn as it will warn us that "still we have not received UCM command for turning on Back-end" and in case we receive it then this log hardly matters and just gives us information that "at that time it was not a valid route". If everyone agrees then I would be more than happy to send a patch.

3 4

Re: [alsa-devel] [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 11:41:21AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 10:21 Wed 07 Nov , Mark Brown wrote: > > Like I say it's not an issue right now and it seems like it should be > > trivial to fix. Is anything needed here other than adding the > > pinctrl_get_set_default() call, in which case would it not be less > > effort all round to just send the patch? If there is more involved then > > what is needed? > for the driver point of view I agreee with you for the dtsi I disagree I miss > 100 lignes of pinctrl description > so today if no pinctrl the pin are input gpio and the drivers will not work > if this code was tested this work MUST have been done otherwise we will apply > non tested work > so dor the dtsi part I do NACK it and the pinctrl code is arropund for 2 or 3 > months so no excuse even Joachim who add the rm9200 support to DT handled the > pinctrl so no exeption on at91 when switching to DT the pinctrl is mandatory > If you want to apply the part of the patch that touch only the drivers I'm > fine but for the dtsi no So what the above is saying is that we should have a followup patch to add the pinctrl setup to the DT (probably one that goes along with the pinctrl changes and adds complete pinctrl setup for the affected boards rather than just doing the audio piecemeal) and do the mindless call in the driver. That doesn't seem impossible. So long as we get those things in place prior to the merge window we should be fine. Even if we don't manage that it still seems like having the patch is better than not having it, from the sounds of it the boards are going to be totally broken if they boot with DT but without the pinctrl setup and the ASoC bindings are pretty much an orthogonal issue to that. Having the bindings for the SSC (which depend on this AFAICT) will allow other machines which are doing a better job with pinctrl to work. Does that seem reasonable?

1 0

[alsa-devel] [PATCH 0/3] ASUS G75 fixes
by tiwai＠suse.de 07 Nov '12

07 Nov '12

Hi Massimo, this is a patch series for fixing ASUS G75. Could you check whether these work for you? Once when confirmed, I'll queue these to the upstream. thanks, Takashi

2 4

[alsa-devel] Out of tree driver for hiface
by Grant Diffey 07 Nov '12

07 Nov '12

3 2