April 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team
by Li, Jocelyn 03 May '13

03 May '13

Hi Guys, I apologize that I may have misunderstood on the agreement we have made on power well work. I assumed that audio team is expected to create private gfx driver API to control the power well between gfx and audio for internal releases. That's why I asked Xingchao work on that. So the correct implementation approach between gfx and audio should be, #1, Daniel will work on the existing private API in gfx driver for power well control that can be used by the audio driver to enable/disable the power well. #2, Once #1 is done, Audio team will integrate Daniel's patch into audio driver and add/improve on anything that is missing Please correct me if my understanding is not correct. Thanks, Jocelyn -----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] Sent: Thursday, April 25, 2013 3:52 PM To: Wang, Xingchao Cc: Zanoni, Paulo R; ville.syrjala(a)linux.intel.com; Lin, Mengdong; Girdwood, Liam R; Li, Jocelyn; intel-gfx(a)lists.freedesktop.org; alsa-devel(a)alsa-project.org; Wang Xingchao; Takashi Iwai; Barnes, Jesse; Wysocki, Rafael J Subject: Re: [PATCH] drm/i915: Add private api for power well usage On Thu, Apr 25, 2013 at 4:36 AM, Wang, Xingchao <xingchao.wang(a)intel.com> wrote: > Hi Daniel/Paulo, > > Any comments on this? > Add Jesse and Rafael in loop. Well I've figured we want to get the power well integration working before we waste time reviewing an interface which might or might not quite work. But if you want, I can drop two quick comments: - I think the functions needs some prefix like i915_ - Imo the power well should just be reference counted (the current interface name suggests it's generally useable, but actually can only cope with one request from the audio driver). - Is the spin_lock (irq-disabling even) really required for the audio driver to work? power well enabling can take up to 20ms, so this won't work as-is. Can't we just use a mutex? - I'd need to see the audio driver side of this to check how this works for coping with arbitrary module load ordering. Cheers, Daniel > > thanks > --xingchao > > >> -----Original Message----- >> From: Wang, Xingchao >> Sent: Wednesday, April 24, 2013 3:29 PM >> To: daniel.vetter(a)ffwll.ch; Zanoni, Paulo R; 'Takashi Iwai' >> Cc: ville.syrjala(a)linux.intel.com; Lin, Mengdong; Girdwood, Liam R; >> Li, Jocelyn; intel-gfx(a)lists.freedesktop.org; alsa-devel(a)alsa-project.org; 'Wang Xingchao' >> Subject: RE: [PATCH] drm/i915: Add private api for power well usage >> >> Hi Guys, >> >> Sorry I should Add Takashi and alsa maillist in loop. >> >> I tested this patch against Daniel's "drm-intel-next-queued" Branch, >> on Haswell Mobile C3 stepping machines. >> >> Test steps: >> 1. only connect one monitor through HDMI cable 2. echo 1 > >> /sys/module/i915/parameters/disable_power_well ==> I think this could >> be set as 1 by default if applied my patch. >> 3. plug out HDMI cable >> 4. cat /proc/asound/card0/codec#0 >> >> At step 3, i915 will try to disable power well but rejected as >> display audio is using power well. >> Without the patch, display audio would crash at step 4. >> >> I did not list suspend/resume test here, as during suspend sequence, >> i915 will _ENABLE_ power well, that's a BUG? >> >> For me above test case is the only one to reproduce the issue, if you >> have more ideas and need more test, please let me know. >> >> I'm afraid there's some risk because the dependency between alsa >> driver and drm driver. For example, if i915 module was not loaded, >> display audio Will call >> request_power_well() and meet symbol error. Even if i915 module >> loaded after snd-hda-intel module, there's such risk too. Any comment on this? >> >> Another risk is the pointer "power_well_device", it should be set >> NULL when >> i915 module unloaded, I added the caller but have no idea where to >> call it, if anyone has suggestion, that would be fine. >> >> thanks >> --xingchao >> >> >> > -----Original Message----- >> > From: Wang Xingchao [mailto:xingchao.wang@linux.intel.com] >> > Sent: Thursday, April 24, 2014 10:20 PM >> > To: daniel.vetter(a)ffwll.ch; Zanoni, Paulo R >> > Cc: ville.syrjala(a)linux.intel.com; Lin, Mengdong; Girdwood, Liam R; >> > Li, Jocelyn; intel-gfx(a)lists.freedesktop.org; Wang, Xingchao; Wang >> > Xingchao >> > Subject: [PATCH] drm/i915: Add private api for power well usage >> > >> > Display audio depends on power well in graphic side, it should >> > request power well before use it and release power well after use. >> > I915 will not shutdown power well if it detects audio is using. >> > This patch protects display audio crash for Intel Haswell mobile >> > C3 stepping board. >> > >> > Signed-off-by: Wang Xingchao <xingchao.wang(a)linux.intel.com> >> > --- >> > drivers/gpu/drm/i915/intel_pm.c | 73 >> > +++++++++++++++++++++++++++++++++++---- >> > include/drm/audio_drm.h | 39 +++++++++++++++++++++ >> > sound/pci/hda/hda_intel.c | 8 +++++ >> > 3 files changed, 113 insertions(+), 7 deletions(-) create mode >> > 100644 include/drm/audio_drm.h >> > >> > diff --git a/drivers/gpu/drm/i915/intel_pm.c >> > b/drivers/gpu/drm/i915/intel_pm.c index 2557926..9983f56 100644 >> > --- a/drivers/gpu/drm/i915/intel_pm.c >> > +++ b/drivers/gpu/drm/i915/intel_pm.c >> > @@ -4298,18 +4298,12 @@ bool intel_using_power_well(struct >> > drm_device >> > *dev) >> > return true; >> > } >> > >> > -void intel_set_power_well(struct drm_device *dev, bool enable) >> > +void set_power_well(struct drm_device *dev, bool enable) >> > { >> > struct drm_i915_private *dev_priv = dev->dev_private; >> > bool is_enabled, enable_requested; >> > uint32_t tmp; >> > >> > - if (!HAS_POWER_WELL(dev)) >> > - return; >> > - >> > - if (!i915_disable_power_well && !enable) >> > - return; >> > - >> > tmp = I915_READ(HSW_PWR_WELL_DRIVER); >> > is_enabled = tmp & HSW_PWR_WELL_STATE; >> > enable_requested = tmp & HSW_PWR_WELL_ENABLE; @@ -4332,6 >> > +4326,71 @@ void intel_set_power_well(struct drm_device *dev, bool >> > +enable) >> > } >> > } >> > >> > +/* Global drm_device for display audio drvier usage */ static >> > +struct drm_device *power_well_device; static bool >> > +audio_power_well_using, i915_power_well_using; >> > +/* Lock protecting power well setting */ >> > +DEFINE_SPINLOCK(powerwell_lock); >> > + >> > +void request_power_well(void) >> > +{ >> > + DRM_DEBUG_KMS("Display audio requesting power well\n"); >> > + spin_lock_irq(&powerwell_lock); >> > + if (!power_well_device) >> > + goto out; >> > + if (i915_power_well_using == false) >> > + set_power_well(power_well_device, true); >> > + audio_power_well_using = true; >> > +out: >> > + spin_unlock_irq(&powerwell_lock); >> > + return; >> > +} >> > +EXPORT_SYMBOL_GPL(request_power_well); >> > + >> > +void release_power_well(void) >> > +{ >> > + DRM_DEBUG_KMS("Display audio releasing power well\n"); >> > + spin_lock_irq(&powerwell_lock); >> > + if (!power_well_device) >> > + goto out; >> > + if (i915_power_well_using == false) >> > + set_power_well(power_well_device, false); >> > + audio_power_well_using = false; >> > +out: >> > + spin_unlock_irq(&powerwell_lock); >> > + return; >> > +} >> > +EXPORT_SYMBOL_GPL(release_power_well); >> > + >> > +/* TODO: Call this when i915 module unload */ void >> > +remove_power_well(void) { >> > + spin_lock_irq(&powerwell_lock); >> > + audio_power_well_using = false; >> > + i915_power_well_using = false; >> > + power_well_device = NULL; >> > + spin_unlock_irq(&powerwell_lock); } >> > + >> > +void intel_set_power_well(struct drm_device *dev, bool enable) { >> > + if (!HAS_POWER_WELL(dev)) >> > + return; >> > + >> > + spin_lock_irq(&powerwell_lock); >> > + power_well_device = dev; >> > + i915_power_well_using = enable; >> > + if (!enable && audio_power_well_using) >> > + goto out; >> > + >> > + if (!i915_disable_power_well && !enable) >> > + goto out; >> > + set_power_well(dev, enable); >> > +out: >> > + spin_unlock_irq(&powerwell_lock); >> > + return; >> > +} >> > + >> > /* >> > * Starting with Haswell, we have a "Power Down Well" that can be >> > turned >> off >> > * when not needed anymore. We have 4 registers that can request >> > the power well diff --git a/include/drm/audio_drm.h >> > b/include/drm/audio_drm.h new file mode 100644 index >> > 0000000..4412b36 >> > --- /dev/null >> > +++ b/include/drm/audio_drm.h >> > @@ -0,0 +1,39 @@ >> > >> +/************************************************************** >> > ******** >> > +**** >> > + * >> > + * Copyright 2013 Intel Inc. >> > + * All Rights Reserved. >> > + * >> > + * Permission is hereby granted, free of charge, to any person >> > +obtaining a >> > + * copy of this software and associated documentation files (the >> > + * "Software"), to deal in the Software without restriction, >> > +including >> > + * without limitation the rights to use, copy, modify, merge, >> > +publish, >> > + * distribute, sub license, and/or sell copies of the Software, >> > +and to >> > + * permit persons to whom the Software is furnished to do so, >> > +subject to >> > + * the following conditions: >> > + * >> > + * The above copyright notice and this permission notice >> > +(including the >> > + * next paragraph) shall be included in all copies or substantial >> > +portions >> > + * of the Software. >> > + * >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY >> KIND, >> > +EXPRESS OR >> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF >> > +MERCHANTABILITY, >> > + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO >> > EVENT >> > +SHALL >> > + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE >> > FOR >> > +ANY CLAIM, >> > + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, >> > TORT >> > +OR >> > + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE >> > SOFTWARE >> > +OR THE >> > + * USE OR OTHER DEALINGS IN THE SOFTWARE. >> > + * >> > + * >> > + >> > >> +*************************************************************** >> > ******** >> > +***/ >> > +/* >> > + * Authors: >> > + * Wang Xingchao <xingchao.wang(a)intel.com> */ >> > + >> > +#ifndef _AUDIO_DRM_H_ >> > +#define _AUDIO_DRM_H_ >> > + >> > +extern void request_power_well(void); extern void >> > +release_power_well(void); >> > + >> > +#endif /* _AUDIO_DRM_H_ */ >> > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c >> > index 418bfc0..59a85de 100644 >> > --- a/sound/pci/hda/hda_intel.c >> > +++ b/sound/pci/hda/hda_intel.c >> > @@ -50,6 +50,7 @@ >> > #include <linux/clocksource.h> >> > #include <linux/time.h> >> > #include <linux/completion.h> >> > +#include <drm/audio_drm.h> >> > >> > #ifdef CONFIG_X86 >> > /* for snoop control */ >> > @@ -2869,6 +2870,7 @@ static int azx_suspend(struct device *dev) >> > pci_disable_device(pci); >> > pci_save_state(pci); >> > pci_set_power_state(pci, PCI_D3hot); >> > + release_power_well(); >> > return 0; >> > } >> > >> > @@ -2881,6 +2883,7 @@ static int azx_resume(struct device *dev) >> > if (chip->disabled) >> > return 0; >> > >> > + request_power_well(); >> > pci_set_power_state(pci, PCI_D0); >> > pci_restore_state(pci); >> > if (pci_enable_device(pci) < 0) { @@ -2913,6 +2916,7 @@ static >> > int azx_runtime_suspend(struct device >> > *dev) >> > >> > azx_stop_chip(chip); >> > azx_clear_irq_pending(chip); >> > + release_power_well(); >> > return 0; >> > } >> > >> > @@ -2921,6 +2925,7 @@ static int azx_runtime_resume(struct device *dev) >> > struct snd_card *card = dev_get_drvdata(dev); >> > struct azx *chip = card->private_data; >> > >> > + request_power_well(); >> > azx_init_pci(chip); >> > azx_init_chip(chip, 1); >> > return 0; >> > @@ -3671,6 +3676,8 @@ static int azx_probe(struct pci_dev *pci, >> > return -ENOENT; >> > } >> > >> > + request_power_well(); >> > + >> > err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); >> > if (err < 0) { >> > snd_printk(KERN_ERR "hda-intel: Error creating >> > card!\n"); @@ >> > -3806,6 +3813,7 @@ static void azx_remove(struct pci_dev *pci) >> > if (card) >> > snd_card_free(card); >> > pci_set_drvdata(pci, NULL); >> > + release_power_well(); >> > } >> > >> > /* PCI IDs */ >> > -- >> > 1.7.9.5 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

9 23

[alsa-devel] [PATCH -next 0/3] mop500_ab8500 fixes
by Fabio Baltieri 03 May '13

03 May '13

Hi, these are small fixes to the mop500_ab8500 asoc driver, developed on top of today's ASoC-next. The first patch is actually non ab8500 specific, but as ab8500 seems to be the only codec to use the SND_SOC_DAPM_CLOCK_SUPPLY widget I'm posting it here anyway. The other two patches sort out a mixup of card and codec controls in mop500_ab8500. Thanks, Fabio Fabio Baltieri (3): ASoC: dapm: use clk_prepare_enable and clk_disable_unprepare ASoC: ux500: move clock controls to ab8500-codec ASoC: ux500: register controls to card instead of codec sound/soc/codecs/ab8500-codec.c | 10 ++++++++++ sound/soc/soc-dapm.c | 4 ++-- sound/soc/ux500/mop500_ab8500.c | 20 +++++--------------- 3 files changed, 17 insertions(+), 17 deletions(-) -- 1.8.2

3 11

[alsa-devel] [PATCH] ASoC: Added the condition for the channels_min of cpu_dai
by JongHo Kim 02 May '13

02 May '13

Only playback device, the pcm substream for capture does not need to be generated. If codec dai driver has both playback.channels_min and capture.channels_min, and cpu dai driver has only playback.channels_min, soc_new_pcm() will make the pcm substream for capture although DataIN is not connected. So added the condition for the channels_min of cpu_dai in soc_new_pcm(). Signed-off-by: JongHo Kim <furmuwon(a)gmail.com> --- sound/soc/soc-pcm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index cf191e6..c405e39 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -2018,9 +2018,11 @@ int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num) if (cpu_dai->driver->capture.channels_min) capture = 1; } else { - if (codec_dai->driver->playback.channels_min) + if (codec_dai->driver->playback.channels_min && + cpu_dai->driver->playback.channels_min) playback = 1; - if (codec_dai->driver->capture.channels_min) + if (codec_dai->driver->capture.channels_min && + cpu_dai->driver->capture.channels_min) capture = 1; } -- 1.8.1.1

2 4

[alsa-devel] [PATCH v2 1/4] ASoC: imx-sgtl5000: Do not enter the error path on success
by Fabio Estevam 02 May '13

02 May '13

From: Fabio Estevam <fabio.estevam(a)freescale.com> Return on success instead of entering the error path. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v1: - Keep of_node_put in the success path. sound/soc/fsl/imx-sgtl5000.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c index 9584e78..5a6aaa3 100644 --- a/sound/soc/fsl/imx-sgtl5000.c +++ b/sound/soc/fsl/imx-sgtl5000.c @@ -174,6 +174,11 @@ static int imx_sgtl5000_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, data); + of_node_put(ssi_np); + of_node_put(codec_np); + + return 0; + clk_fail: clk_put(data->codec_clk); fail: -- 1.7.9.5

3 12

[alsa-devel] [PATCH] MAINTAINERS: Add linux-samsung-soc list to all related entries
by Tomasz Figa 01 May '13

01 May '13

Several entries in MAINTAINERS file related to Samsung SoCs do not point to linux-samsung-soc mailing list, which is supposed to collect all Samsung SoC-related threads, to ease following of Samsung SoC-related work. This leads to a problem with people skipping this mailing list in their posts, even though they are related to Samsung SoCs. This patch adds pointers to linux-samsung-soc mailing list to affected entries of MAINTAINERS file. Signed-off-by: Tomasz Figa <tomasz.figa(a)gmail.com> --- MAINTAINERS | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6c0d68b..07cb8da 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1139,6 +1139,7 @@ F: arch/arm/mach-exynos*/ ARM/SAMSUNG MOBILE MACHINE SUPPORT M: Kyungmin Park <kyungmin.park(a)samsung.com> L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers) +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/mach-s5pv210/mach-aquila.c F: arch/arm/mach-s5pv210/mach-goni.c @@ -1150,6 +1151,7 @@ M: Kyungmin Park <kyungmin.park(a)samsung.com> M: Kamil Debski <k.debski(a)samsung.com> L: linux-arm-kernel(a)lists.infradead.org L: linux-media(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/media/platform/s5p-g2d/ @@ -1158,6 +1160,7 @@ M: Kyungmin Park <kyungmin.park(a)samsung.com> M: Sylwester Nawrocki <s.nawrocki(a)samsung.com> L: linux-arm-kernel(a)lists.infradead.org L: linux-media(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/plat-samsung/include/plat/*fimc* F: drivers/media/platform/s5p-fimc/ @@ -1168,6 +1171,7 @@ M: Kamil Debski <k.debski(a)samsung.com> M: Jeongtae Park <jtp.park(a)samsung.com> L: linux-arm-kernel(a)lists.infradead.org L: linux-media(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/plat-samsung/s5p-dev-mfc.c F: drivers/media/platform/s5p-mfc/ @@ -1177,6 +1181,7 @@ M: Kyungmin Park <kyungmin.park(a)samsung.com> M: Tomasz Stanislawski <t.stanislaws(a)samsung.com> L: linux-arm-kernel(a)lists.infradead.org L: linux-media(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/media/platform/s5p-tv/ @@ -2679,6 +2684,7 @@ M: Joonyoung Shim <jy0922.shim(a)samsung.com> M: Seung-Woo Kim <sw0312.kim(a)samsung.com> M: Kyungmin Park <kyungmin.park(a)samsung.com> L: dri-devel(a)lists.freedesktop.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git S: Supported F: drivers/gpu/drm/exynos @@ -3142,6 +3148,7 @@ F: Documentation/extcon/ EXYNOS DP DRIVER M: Jingoo Han <jg1.han(a)samsung.com> L: linux-fbdev(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/exynos/exynos_dp* F: include/video/exynos_dp* @@ -3151,6 +3158,7 @@ M: Inki Dae <inki.dae(a)samsung.com> M: Donghwa Lee <dh09.lee(a)samsung.com> M: Kyungmin Park <kyungmin.park(a)samsung.com> L: linux-fbdev(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/exynos/exynos_mipi* F: include/video/exynos_mipi* @@ -6892,12 +6900,14 @@ F: drivers/platform/x86/samsung-laptop.c SAMSUNG AUDIO (ASoC) DRIVERS M: Sangbeom Kim <sbkim73(a)samsung.com> L: alsa-devel(a)alsa-project.org (moderated for non-subscribers) +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Supported F: sound/soc/samsung SAMSUNG FRAMEBUFFER DRIVER M: Jingoo Han <jg1.han(a)samsung.com> L: linux-fbdev(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/s3c-fb.c @@ -7087,6 +7097,7 @@ F: drivers/mmc/host/sdhci-pltfm.[ch] SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) SAMSUNG DRIVER M: Ben Dooks <ben-linux(a)fluff.org> L: linux-mmc(a)vger.kernel.org +L: linux-samsung-soc(a)vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/mmc/host/sdhci-s3c.c -- 1.8.2.1

4 3

[alsa-devel] [PATCH] ASoC: McASP: Add pins output direction for rx clocks when configured in CBS_CFS format.
by Marek Belisko 30 Apr '13

30 Apr '13

When McASP is bit clock and frame clock master enable pin output for rx clocks. Signed-off-by: Marek Belisko <marek.belisko(a)streamunlimited.com> --- sound/soc/davinci/davinci-mcasp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index d54e0d9..2953c55 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -505,7 +505,10 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai, mcasp_set_bits(base + DAVINCI_MCASP_ACLKRCTL_REG, ACLKRE); mcasp_set_bits(base + DAVINCI_MCASP_RXFMCTL_REG, AFSRE); - mcasp_set_bits(base + DAVINCI_MCASP_PDIR_REG, ACLKX | AFSX); + mcasp_set_bits(base + DAVINCI_MCASP_PDIR_REG, + ACLKX | ACLKR); + mcasp_set_bits(base + DAVINCI_MCASP_PDIR_REG, + AFSX | AFSR); break; case SND_SOC_DAIFMT_CBM_CFS: /* codec is clock master and frame slave */ -- 1.7.9.5

2 1

[alsa-devel] [PATCH v2 0/3] ASoC: Add devicetree support for spdif dummy codecs.
by Marek Belisko 30 Apr '13

30 Apr '13

changes from v1 (for patch 2 and 3): - add prefix linux for compatible property (for both tx and rx) - rename spdif_transceiver.c to spdif_transmitter.c - add bindings documentation Marek Belisko (3): ASoC: spdif_transceiver: Change driver filename to spdif_transmitter.c. ASoC: spdif_transmitter: Add DT support. ASoC: spdif_receiver: Add DT support. .../devicetree/bindings/sound/spdif-receiver.txt | 10 ++++++++++ .../bindings/sound/spdif-transmitter.txt | 10 ++++++++++ sound/soc/codecs/Makefile | 2 +- sound/soc/codecs/spdif_receiver.c | 10 ++++++++++ .../{spdif_transciever.c => spdif_transmitter.c} | 10 ++++++++++ 5 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/spdif-receiver.txt create mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt rename sound/soc/codecs/{spdif_transciever.c => spdif_transmitter.c} (88%) -- 1.7.9.5

4 7

Re: [alsa-devel] linux-next: Tree for Apr 30 (sound)
by Randy Dunlap 30 Apr '13

30 Apr '13

On 04/29/13 23:57, Stephen Rothwell wrote: > Hi all, > > Please do not add any v3.11 destined work to your linux-next included > branches until after v3.10-rc1 is released. > > Changes since 20130429: > when CONFIG_PROC_FS is not enabled: sound/core/memalloc.c: In function 'snd_mem_exit': sound/core/memalloc.c:525:20: error: 'SND_MEM_PROC_FILE' undeclared (first use in this function) -- ~Randy

1 0

[alsa-devel] [patch] ASoC: wm8994: missing break in wm8994_aif3_hw_params()
by Dan Carpenter 30 Apr '13

30 Apr '13

The missing break here means that we always return early and the function is a no-op. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 14094f5..1eb152c 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -2882,6 +2882,7 @@ static int wm8994_aif3_hw_params(struct snd_pcm_substream *substream, default: return 0; } + break; default: return 0; }

3 3

Re: [alsa-devel] what is the difference between SNDRV_PCM_FMTBIT_S24_LE and SNDRV_PCM_FMTBIT_S24_3LE
by Clemens Ladisch 30 Apr '13

30 Apr '13

(please do not drop the mailing list from replies.) Zhang wei wrote: > I do not really understand. For example,an codec is wm8985 ... The SNDRV_PCM_* symbols specify the format in which samples are stored in memory. I do not know how ASoC maps these symbols to on-the-wire formats. >>Most devices that support 24 bits use SNDRV_PCM_FORMAT_S32_LE, which >>stores the sample's bits in the upper bits of a 32-bit word. > > But how to distinguish the SNDRV_PCM_FORMAT_S24_LE and the REAL > SNDRV_PCM_FORMAT_S32_LE? If a 24-bit sample with the value 0x123456 is stored in memory, it looks like this: SNDRV_PCM_FORMAT_S24_LE: 56 34 12 00 SNDRV_PCM_FORMAT_S32_LE: 00 56 34 12 Regards, Clemens

3 2