December 2010 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ASoC: sh: fsi-da7210: remove unnecessary format settings
by Kuninori Morimoto 02 Jan '11

02 Jan '11

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- it is not supported now sound/soc/sh/fsi-da7210.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/sh/fsi-da7210.c b/sound/soc/sh/fsi-da7210.c index a6adb6e..e8df9da 100644 --- a/sound/soc/sh/fsi-da7210.c +++ b/sound/soc/sh/fsi-da7210.c @@ -18,7 +18,7 @@ static int fsi_da7210_init(struct snd_soc_pcm_runtime *rtd) struct snd_soc_dai *dai = rtd->codec_dai; return snd_soc_dai_set_fmt(dai, - SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBM_CFM); } -- 1.7.1

2 1

[alsa-devel] [patch 0/6] sound azt3328: fix bugs, improve codec layering, speedup
by andi＠lisas.de 02 Jan '11

02 Jan '11

This azt3328 PCI sound driver patch series contains some remaining cleanup, several fixes and some nice improvements. Tested and checkpatch.pl'ed on 2.6.37-rc6. Despite improved functionality the compiled binary is now some 300 bytes smaller (dito for source). Will be one of the last updates to azt3328, I promise ;) (I've got some other interesting work for more widespread cards) Thanks! Andreas Mohr

3 2

[alsa-devel] [PATCH] ALSA: hda: Use LPIB quirk for Dell Inspiron m101z/1120
by Daniel Chen 02 Jan '11

02 Jan '11

Hi, Attached is a patch against master HEAD resolving capture anomalies on Sjoerd's Dell Inspiron m101z. Thanks, -Dan

2 1

[alsa-devel] ASoC updates for 2.6.37
by Mark Brown 02 Jan '11

02 Jan '11

The following changes since commit 862af8adbe6b9ccb7c00c13717b1f92465f79aa2: ASoC: Fix bias power down of non-DAPM codec (2010-12-13 16:47:48 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.37 This is very late for such a big set of changes, but unfortunately Lars-Peter only reported them just before Christmas. Most of the changes are small and easy to verify by hand, the big one is the WM8753 which has had the benefit of testing from Lars-Peter and which consists mostly of replacing the custom wm8753 write function with the generic snd_soc_write() and so can be relatively easily verified by eye. In case you don't want to send these on to Linus I've also marked them as CC to stable so they'll go into the stable release when that goes out. Lars-Peter Clausen (9): ASoC: codecs: Add missing control_type initialization ASoC: codecs: max98088: Fix register cache incoherency ASoC: codecs: wm8523: Fix register cache incoherency ASoC: codecs: wm8741: Fix register cache incoherency ASoC: codecs: wm8904: Fix register cache incoherency ASoC: codecs: wm8955: Fix register cache incoherency ASoC: codecs: wm8962: Fix register cache incoherency ASoC: codecs: wm9090: Fix register cache incoherency ASoC: codecs: wm8753: Fix register cache incoherency sound/soc/codecs/max98088.c | 10 +- sound/soc/codecs/wm8523.c | 9 +- sound/soc/codecs/wm8741.c | 10 +- sound/soc/codecs/wm8753.c | 226 ++++++++++++++++--------------------------- sound/soc/codecs/wm8904.c | 37 ++++---- sound/soc/codecs/wm8940.c | 1 + sound/soc/codecs/wm8955.c | 31 +++--- sound/soc/codecs/wm8960.c | 1 + sound/soc/codecs/wm8962.c | 45 ++++----- sound/soc/codecs/wm8971.c | 1 + sound/soc/codecs/wm9081.c | 1 + sound/soc/codecs/wm9090.c | 18 ++-- 12 files changed, 164 insertions(+), 226 deletions(-)

2 1

[alsa-devel] CONFIG_SND_HDA_INTEL regression on 2.6.37-rc3 - no audio
by Luis R. Rodriguez 02 Jan '11

02 Jan '11

I just booted 2.6.37-rc3 and noticed my sound with CONFIG_SND_HDA_INTEL stopped working, I get no audio at all. Is this a known regression? I can bisect if not. $ lsmod| grep snd snd_hda_codec_analog 79955 1 snd_hda_intel 25446 3 snd_hda_codec 101539 2 snd_hda_codec_analog,snd_hda_intel snd_hwdep 6546 1 snd_hda_codec snd_pcm 88139 3 snd_hda_intel,snd_hda_codec snd_seq_midi 5900 0 snd_rawmidi 21916 1 snd_seq_midi snd_seq_midi_event 7291 1 snd_seq_midi snd_seq 56979 2 snd_seq_midi,snd_seq_midi_event snd_timer 23148 2 snd_pcm,snd_seq snd_seq_device 6912 3 snd_seq_midi,snd_rawmidi,snd_seq snd 63192 15 snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,thinkpad_acpi,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 1240 1 snd snd_page_alloc 8716 2 snd_hda_intel,snd_pcm Luis

6 8

[alsa-devel] [PATCH 4/4] ASoC sst: Add makefiles and kconfigs changes
by Vinod Koul 30 Dec '10

30 Dec '10

This patch adds the makefile and kconfig changes for mid asoc driver platform and machine driver which are introduced in 2 preceeding patches Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Harsha Priya <priya.harsha(a)intel.com> --- sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/mid-x86/Kconfig | 13 +++++++++++++ sound/soc/mid-x86/Makefile | 5 +++++ 4 files changed, 20 insertions(+), 0 deletions(-) create mode 100644 sound/soc/mid-x86/Kconfig create mode 100644 sound/soc/mid-x86/Makefile diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index a3efc52..f28bab4 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -47,6 +47,7 @@ source "sound/soc/ep93xx/Kconfig" source "sound/soc/fsl/Kconfig" source "sound/soc/imx/Kconfig" source "sound/soc/jz4740/Kconfig" +source "sound/soc/mid-x86/Kconfig" source "sound/soc/nuc900/Kconfig" source "sound/soc/omap/Kconfig" source "sound/soc/kirkwood/Kconfig" diff --git a/sound/soc/Makefile b/sound/soc/Makefile index ce913bf..df83d21 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_SND_SOC) += ep93xx/ obj-$(CONFIG_SND_SOC) += fsl/ obj-$(CONFIG_SND_SOC) += imx/ obj-$(CONFIG_SND_SOC) += jz4740/ +obj-$(CONFIG_SND_SOC) += mid-x86/ obj-$(CONFIG_SND_SOC) += nuc900/ obj-$(CONFIG_SND_SOC) += omap/ obj-$(CONFIG_SND_SOC) += kirkwood/ diff --git a/sound/soc/mid-x86/Kconfig b/sound/soc/mid-x86/Kconfig new file mode 100644 index 0000000..0e2ab32 --- /dev/null +++ b/sound/soc/mid-x86/Kconfig @@ -0,0 +1,13 @@ +config SND_MID_MACHINE + tristate "SOC Machine Audio driver for Intel MID chips" + select SND_SOC_MSIC + select SND_MID_PLATFORM + help + This adds support for ASoC machine driver used as alsa device + in audio substem in Intel(R) MID devices + Say Y if you have such a device + If unsure select "N". + +config SND_MID_PLATFORM + tristate + depends on SND_INTEL_SST diff --git a/sound/soc/mid-x86/Makefile b/sound/soc/mid-x86/Makefile new file mode 100644 index 0000000..884241a --- /dev/null +++ b/sound/soc/mid-x86/Makefile @@ -0,0 +1,5 @@ +snd-soc-mid-platform-objs := mid_platform.o mid_platform_lib.o +snd-soc-mid-machine-objs := mid_machine.o mid_machine_lib.o + +obj-$(CONFIG_SND_MID_PLATFORM) += snd-soc-mid-platform.o +obj-$(CONFIG_SND_MID_MACHINE) += snd-soc-mid-machine.o -- 1.7.2.3

1 0

[alsa-devel] [PATCH 0/4]: ASoC SST mid asoc drivers
by Koul, Vinod 30 Dec '10

30 Dec '10

Hi, This patchset adds the asoc drivers for mid devices. These drivers along with sst driver form the audio subsystem in these class of devices. The current asoc driver supports the Intel(R) Medfield platform and msic codec with only playback support. More features and codecs will be added in future. This patchset addresses the comments received in previous RFC patches. This current patch set adds one msic codec driver, the mid platform driver and machine driver. More codec drivers will be added eventually. This misc codec driver adds only playback path. Capture path and jack detection are todo. The Platform driver is currently dependent on the SST driver which is in the staging. Brief description of these patches: 1/4: Codec driver with config changes 2/4: Platform driver 3/4: Machine driver 4/4: Make file and kconfig changes for machine and platform driver Thanks Harsha & Vinod

1 0

[alsa-devel] [PATCH] fbdev: sh_mobile_hdmi: fixup compile error
by Kuninori Morimoto 29 Dec '10

29 Dec '10

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- >> Paul This patch is not needed for now on Paul's tree. But seems to be needed after ALSA tree merge. >> Mark, Liam this patch is needed on current Mark's "for-2.6.38" tree. drivers/video/sh_mobile_hdmi.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c index d7df103..b19941d 100644 --- a/drivers/video/sh_mobile_hdmi.c +++ b/drivers/video/sh_mobile_hdmi.c @@ -22,6 +22,7 @@ #include <linux/slab.h> #include <linux/types.h> #include <linux/workqueue.h> +#include <sound/soc.h> #include <sound/soc-dapm.h> #include <sound/initval.h> -- 1.7.1

3 3

Re: [alsa-devel] [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver
by Liam Girdwood 29 Dec '10

29 Dec '10

On Wed, 2010-12-29 at 14:04 +0200, Felipe Balbi wrote: > Hi, > > On Wed, Dec 29, 2010 at 11:52:51AM +0000, Liam Girdwood wrote: > >I agree that drivers should be arch independent when possible, but in > >this case the OMAP DMIC DAI driver is coupled to the OMAP platform only. > >i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found > >on OMAP silicon. > > Let's imagine this IP is sourced from someone else and not created by > TI, what prevents company XYZ from sourcing the same IP and end up > re-using the driver ? That's fine, but this is not the case atm for this particular DMIC IP and we can only justify effort for OMAP atm. > > >I also agree it would be nice if it builds for PXA, MIPS, SuperH etc but > >what happens when the driver builds fine for OMAP but breaks the PXA, > >MIPS, SuperH build ? Who will spend time to fix and test it ? > > You forgetting about other ARMs. This won't compile on DaVinci either. > > >My main problem here is cost benefit. No one benefits directly by having > >this driver available for the above platforms but it costs me time > >fixing it when it breaks. > > Of course there's people benefitting: OMAP audio driver writers would > know their driver is well written and doesn't break build for anybody. > > Ok, let me put it this way: > > What happens when you want have one kernel image for OMAP and DaVinci ? > Granted, that's not possible today anyway but e.g. Linaro is pushing for > it and IMO should be the way to go for us to be able to have a > distro-like kernel for ARM-based systems too. > Ok, I now think you meant other "ARM architectures" here than other Linux architectures in general. It does make a more sense for ARM distribution deployment, but I still think guaranteeing successful build for this driver on all non ARM architectures atm just to give us satisfaction that the driver is "well written" is unnecessary effort. > >> >It also seems inconsistent with the other OMAP system headers in > >> >plat-omap too. > >> > >> Other than a few drivers which still need converting (and are on their > >> way) I can only see really arch-specific bits and pieces under plat/. > >> > >> Not sure what's your point here. > >> > > > >The point is that David had split the DMIC headers into two files, one > >for plat specific registers and bit definitions and the other for audio > >definitions (for the machine drivers) and is/was consistent with the > >current OMAP platform headers. > > You forgot to mention that plat/ headers are supposed to be used by > plat-* and mach-* code only to setup the correct state for the driver. > Just recently one of the musb glue layers got broken because it was > mistakenly using <plat/control.h> and that got moved. > > That's actually my point and why I think drivers should not touch plat/* > and mach/* headers. > In a lot of cases drivers under drivers/* and sound/* must touch plat/* and mach/* headers for runtime access to hardware IP. I've just grepped and the list is quite long for drivers/* Liam

1 0

Re: [alsa-devel] [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver
by Mark Brown 29 Dec '10

29 Dec '10

On Wed, Dec 29, 2010 at 01:59:24PM +0200, Felipe Balbi wrote: > On Wed, Dec 29, 2010 at 11:56:28AM +0000, Mark Brown wrote: > >The other thing with McBSP is that it's a generic programmable serial > >port and so need not be tied to audio use (though as I understand it > >other uses are very rare). > So why is it still tied to OMAP-only ? There's no abstraction layer > around McBSP so OMAP McBSP driver has to export a whole bunch of symbols > for its users: As far as I know the hardware has not been used on other platforms - all the people who care specifically about the driver are using OMAP and don't see any reason to do the work. There's really no pressure to do this.

1 0