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

[alsa-devel] [PATCH v2] mfd: wm8994: declare dc servo register for wm8958 as volatile
by Nikesh Oswal 14 Aug '14

14 Aug '14

DC Servo register 57h holds the DC offset value after the hardware has completed the DC Servo Correction, so declare this register as volatile because it is changed by the hardware. Signed-off-by: Nikesh Oswal <nikesh(a)opensource.wolfsonmicro.com> --- drivers/mfd/wm8994-regmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/wm8994-regmap.c b/drivers/mfd/wm8994-regmap.c index 2fbce9c..fa1630d 100644 --- a/drivers/mfd/wm8994-regmap.c +++ b/drivers/mfd/wm8994-regmap.c @@ -1169,6 +1169,7 @@ static bool wm8958_volatile_register(struct device *dev, unsigned int reg) case WM8958_FW_MINOR_0: case WM8958_FW_PATCH_1: case WM8958_FW_PATCH_0: + case WM8994_DC_SERVO_4: return true; default: return wm8994_volatile_register(dev, reg); -- 1.7.9.5

2 1

[alsa-devel] ASoC: of_parse_phandle techniques newbie question
by Matt Flax 14 Aug '14

14 Aug '14

Hi there, In implementing a codec/driver combination, I found that I have to re-write some of the snd_soc_dai_link with device tree related entries : http://mailman.alsa-project.org/pipermail/alsa-devel/2014-August/080034.html Can anyone explain to me why we have to do this, a little confused here ? For example : driver_dai.codec_name = NULL; driver_dai.codec_of_node = of_parse_phandle(np, ..... Why can't the codec be found from the codec_name which matches the previously probed codec ? thanks Matt

1 0

[alsa-devel] ASoC: CPU DAI samsung-i2s.0 not registered
by Matt Flax 14 Aug '14

14 Aug '14

Hi there, Any ideas why this problem is coming up when I try to load a driver ? Here is the device tree : i2s0: i2s@03830000 { compatible = "samsung,i2s-v5"; reg = <0x03830000 0x100>; dmas = <&pdma0 10 &pdma0 9 &pdma0 8>; dma-names = "tx", "rx", "tx-sec"; clocks = <&clock_audss EXYNOS_I2S_BUS>, <&clock_audss EXYNOS_I2S_BUS>, <&clock_audss EXYNOS_SCLK_I2S>; clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; samsung,supports-6ch; samsung,supports-rstclr; samsung,supports-secdai; samsung,idma-addr = <0x03000000>; pinctrl-names = "default"; pinctrl-0 = <&i2s0_bus>; }; implant: implant@0 { compatible = "bva,implant"; }; sound { compatible = "bva,implant-bva"; samsung,i2s-controller = <&i2s0>; samsung,audio-codec = <&implant>; };

3 6

Re: [alsa-devel] [v4 02/12] ASoC: Intel: mrfld: set private data for cpu-dai
by Lars-Peter Clausen 14 Aug '14

14 Aug '14

On 08/14/2014 07:36 AM, Subhransu S. Prusty wrote: > On Wed, Aug 13, 2014 at 09:50:43PM +0200, Lars-Peter Clausen wrote: >> [...] >>> +static int sst_media_dai_probe(struct snd_soc_dai *cpu_dai) >>> +{ >>> + struct sst_data *sst = dev_get_drvdata(cpu_dai->dev); >>> + >>> + snd_soc_dai_set_drvdata(cpu_dai, sst); >> >> snd_soc_dai_set_drvdata does dev_set_drvdata(dai->dev, data) >> internally, so this function does: >> >> dev_set_drvdata(cpu_dai->dev, dev_get_drvdata(cpu_dai->dev)); >> >> That's pretty much a noop. >> > > Agree. Intention was to use snd_soc_dai_* API. Anyway will remove and use > dev_get_drvdata(dai->dev) directly. > It's totally fine to use snd_soc_dai_get_drvdata() through the driver. It's just that this probe function does nothing and can be removed.

1 0

[alsa-devel] What is the command line commands to use UAC2 at USB client side?
by Xuebing Wang 14 Aug '14

14 Aug '14

Hi Community, Based on Freescale platform , I am trying to use USB Audio Class version 2.0. Host can detect this UAC2 device. At device side (after modprobe g_audio): root@imx6slevk:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM Playback dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] Subdevices: 1/1 Subdevice #0: subdevice #0 At device side, in driver/usb/gadget/Kconfig, it says before for CONFIG_USB_AUDIO ------------------------- This driver doesn't expect any real Audio codec to be present on the device - the audio streams are simply sinked to and sourced from a virtual ALSA sound card created. The user-space application may choose to do whatever it wants with the data received from the USB Host and choose to provide whatever it wants as audio data to the USB Host. ------------------------- My question is: at device side, how to configure sink/source for UAC2 virtual ALSA sound card (hw:2,0, UAC2_Gadget)? Thank you very much. Xuebing Wang

1 0

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

14 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..b8c131e 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 signal. 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 singal. If values less than the + number of input signal, 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] SGTL500 and its external MCLK
by jonsmirl＠gmail.com 13 Aug '14

13 Aug '14

For testing purposes I have a SGTL5000 wired up to I2S on my Allwinner A20. SGTL5000 needs an external MCLK. It attaches to it like this: sgtl5000: sgtl5000@a { compatible = "fsl,sgtl5000"; reg = <0x0a>; clocks = <&iis0>; And in the probe code.... (this should use a name for the clock in the DTS) sgtl5000->mclk = devm_clk_get(&client->dev, NULL); if (IS_ERR(sgtl5000->mclk)) { ret = PTR_ERR(sgtl5000->mclk); dev_err(&client->dev, "Failed to get mclock: %d\n", ret); /* Defer the probe to see if the clk will be provided later */ if (ret == -ENOENT) return -EPROBE_DEFER; return ret; } ret = clk_prepare_enable(sgtl5000->mclk); if (ret) return ret; So the sgtl5000 driver has a handle to the clock. But then the driver implements set_dai_sysclk() to get the rate. And a board specific machine driver like imx-sgtl5000.c is used to set this rate into the sgtl5000 driver. /* set codec sysclk */ static int sgtl5000_set_dai_sysclk(struct snd_soc_dai *codec_dai, int clk_id, unsigned int freq, int dir) { struct snd_soc_codec *codec = codec_dai->codec; struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec); switch (clk_id) { case SGTL5000_SYSCLK: sgtl5000->sysclk = freq; break; default: return -EINVAL; } return 0; } Since the sgtl5000 driver has the handle to the clock, can't it just ask the clock for its rate? If it directly asked the clock for its rate it looks like this codec could be bound with simple-audio-card and not need a machine driver. -- Jon Smirl jonsmirl(a)gmail.com

3 6

[alsa-devel] [PATCH] ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE
by Daniel Mack 13 Aug '14

13 Aug '14

This mode is unsupported, as the DMA controller can't do zero-padding of samples. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Reported-by: Johannes Stezenbach <js(a)sig21.net> Cc: Eric Miao <eric.y.miao(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> --- sound/soc/pxa/pxa-ssp.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c index 199a8b3..2db467f 100644 --- a/sound/soc/pxa/pxa-ssp.c +++ b/sound/soc/pxa/pxa-ssp.c @@ -764,9 +764,7 @@ static int pxa_ssp_remove(struct snd_soc_dai *dai) SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_64000 | \ SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000) -#define PXA_SSP_FORMATS (SNDRV_PCM_FMTBIT_S16_LE |\ - SNDRV_PCM_FMTBIT_S24_LE | \ - SNDRV_PCM_FMTBIT_S32_LE) +#define PXA_SSP_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE) static const struct snd_soc_dai_ops pxa_ssp_dai_ops = { .startup = pxa_ssp_startup, -- 2.0.4

2 1

[alsa-devel] [PATCH V4 0/2] refine esai for tdm support
by Shengjiu Wang 13 Aug '14

13 Aug '14

These patchs is to refine esai for tdm support. Changes for V4 - update the comments for patch 2 Changes for V3 - update the comments for patch 2 Changes for V2 - update the comments according the reviewer's suggestion - add init value for slots and change pin to pins. Shengjiu Wang (2): ASoC: fsl_esai: refine esai for TDM support Revert "ASoC: fsl-esai: Add .xlate_tdm_slot_mask() support." sound/soc/fsl/Kconfig | 1 - sound/soc/fsl/fsl_esai.c | 16 +++++++++++----- sound/soc/fsl/fsl_esai.h | 8 ++++---- 3 files changed, 15 insertions(+), 10 deletions(-) -- 1.7.9.5

3 4

[alsa-devel] Ordering in soc_pcm_hw_params()
by jonsmirl＠gmail.com 13 Aug '14

13 Aug '14

soc_pcm_hw_params() sets the parameters in this order: link, codec, cpu, platform This is tripping me up when switching between the 44100 and 48000 families. If previous song was 44100 then the codec has sysclk set to the 44100 family. Now I play a 48000 family song. codec gets new hardware params and errors out because sysclk is still in the 44100 family. I have code in the cpu set_hw_params which will switch the sysclk, but it never gets to run because the codec set_hw_params() has already errored out. Shouldn't this order be: platform, link, cpu, codec -- Jon Smirl jonsmirl(a)gmail.com

3 23