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

Re: [alsa-devel] [PATCH 3/4] ARM: OMAP3: Switch to use the unified audio driver (omap-twl4030) for selected boards
by Peter Ujfalusi 08 Aug '12

08 Aug '12

Hi Igor, On 08/08/2012 03:24 PM, Igor Grinberg wrote: >> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c >> index 97d7190..b73fa5c 100644 >> --- a/arch/arm/mach-omap2/board-cm-t35.c >> +++ b/arch/arm/mach-omap2/board-cm-t35.c >> @@ -731,6 +731,7 @@ static void __init cm_t3x_common_init(void) >> cm_t35_init_ethernet(); >> cm_t35_init_led(); >> cm_t35_init_display(); >> + omap_twl4030_audio_init("overo", 26000000); > > Can the card_name here be "cm-t3x" ? I have used the "overo" as card name here since what I gathered is that cm-t35 used the sound/soc/omap/overo.c machine driver for audio support. If the card name is changing your existing user space might get confused by the card name change. But sure, I can change the card name to "cm-t3x" if it is better for you. -- Péter

1 0

Re: [alsa-devel] [PATCH] ASoC: Samsung: Fix build error
by Kukjin Kim 08 Aug '12

08 Aug '12

Sachin Kamat wrote: > > On 8 August 2012 17:08, Kukjin Kim <kgene.kim(a)samsung.com> wrote: > > Sachin Kamat wrote: > >> > >> Hi Mark, > >> > >> On 8 August 2012 16:39, Mark Brown > <broonie(a)opensource.wolfsonmicro.com> > >> wrote: > >> > On Wed, Aug 08, 2012 at 11:34:43AM +0530, Sachin Kamat wrote: > >> >> Fixes the following build error: > >> >> In file included from arch/arm/mach-exynos/include/mach/dma.h:24:0, > >> >> from arch/arm/plat-samsung/include/plat/dma-ops.h:17, > >> >> from arch/arm/plat-samsung/include/plat/dma.h:128, > >> >> from sound/soc/samsung/pcm.c:23: > >> >> arch/arm/plat-samsung/include/plat/dma-pl330.h:106:8: > >> >> error: redefinition of 'struct > > s3c2410_dma_client' > >> >> arch/arm/plat-samsung/include/plat/dma.h:40:8: note: originally > defined > >> here > >> >> make[3]: *** [sound/soc/samsung/pcm.o] Error 1 > >> > > >> > Shouldn't this be being fixed in the headers? It looks like they > >> > reference and disagree with each other on Exynos (my primary > development > >> > platform is S3C6410 based so I'd notice if it was a generic Samsung > >> > issue. > >> > > >> > Pasting the error message isn't really that useful unless the fix is > >> > obvious, it's better to explain in words what's wrong. > >> > >> I had sent the initial patch trying to fix this in the headers and it > >> worked for exynos4 config. However Kukjin pointed out that the patch > >> created similar errors with 2410 and 6400 configs. Fixing it further > >> in the headers did not look quite straight forward as there are many > >> headers trying to include one another. Hence I felt it is better > >> handled in the current way. I understand i should have added this > >> information in the commit message. Below is the link for your > >> reference that provides the complete discussion. > >> > >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/11274 > >> > >> Please let me know your opinion about this. > >> > >> > > I also agree with Mark's opinion and current Sachin's approach cannot > avoid > > whole similar build error. > > With the current change I did not see any build error with the configs > (2410, 6400, 64x0 and exyno4) i checked with (after enabling audio). > Please let me know if you observed any such build error after adding > this patch. > > Happens following error with s5pv210_defcofnig (after enabling s5p-sss). In file included from arch/arm/mach-s5pv210/include/mach/dma.h:24, from arch/arm/plat-samsung/include/plat/dma-ops.h:17, from arch/arm/plat-samsung/include/plat/dma.h:128, from drivers/crypto/s5p-sss.c:33: arch/arm/plat-samsung/include/plat/dma-pl330.h:106: error: redefinition of 'struct s3c2410_dma_client' make[2]: *** [drivers/crypto/s5p-sss.o] Error 1 make[1]: *** [drivers/crypto] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs.... Actually, <mach/dma.h> is including <plat/dma-pl330.h> for s5p64x0, s5pc100, s5pv210 and exynos or <plat/dma.h> for s3c24xx and s3c64xx. And the cause of build error you reported is duplicated declaration of s3c2410_dma_client. So it can happen when <plat/dma-pl330.h> and <plat/dma.h> are included together at the same time... Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim(a)samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.

1 0

Re: [alsa-devel] [PATCH] ASoC: Samsung: Fix build error
by Kukjin Kim 08 Aug '12

08 Aug '12

Sachin Kamat wrote: > > Hi Mark, > > On 8 August 2012 16:39, Mark Brown <broonie(a)opensource.wolfsonmicro.com> > wrote: > > On Wed, Aug 08, 2012 at 11:34:43AM +0530, Sachin Kamat wrote: > >> Fixes the following build error: > >> In file included from arch/arm/mach-exynos/include/mach/dma.h:24:0, > >> from arch/arm/plat-samsung/include/plat/dma-ops.h:17, > >> from arch/arm/plat-samsung/include/plat/dma.h:128, > >> from sound/soc/samsung/pcm.c:23: > >> arch/arm/plat-samsung/include/plat/dma-pl330.h:106:8: > >> error: redefinition of 'struct s3c2410_dma_client' > >> arch/arm/plat-samsung/include/plat/dma.h:40:8: note: originally defined > here > >> make[3]: *** [sound/soc/samsung/pcm.o] Error 1 > > > > Shouldn't this be being fixed in the headers? It looks like they > > reference and disagree with each other on Exynos (my primary development > > platform is S3C6410 based so I'd notice if it was a generic Samsung > > issue. > > > > Pasting the error message isn't really that useful unless the fix is > > obvious, it's better to explain in words what's wrong. > > I had sent the initial patch trying to fix this in the headers and it > worked for exynos4 config. However Kukjin pointed out that the patch > created similar errors with 2410 and 6400 configs. Fixing it further > in the headers did not look quite straight forward as there are many > headers trying to include one another. Hence I felt it is better > handled in the current way. I understand i should have added this > information in the commit message. Below is the link for your > reference that provides the complete discussion. > > http://comments.gmane.org/gmane.linux.kernel.samsung-soc/11274 > > Please let me know your opinion about this. > > I also agree with Mark's opinion and current Sachin's approach cannot avoid whole similar build error. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim(a)samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.

1 0

[alsa-devel] [PATCH] ASoC: mxs: Fix the name of the SoC family
by Fabio Estevam 08 Aug '12

08 Aug '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> SND_SOC_MXS_SGTL5000 is used on MXS boards, so fix the SoC family name. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/mxs/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/mxs/Kconfig b/sound/soc/mxs/Kconfig index 99a997f..b6fa776 100644 --- a/sound/soc/mxs/Kconfig +++ b/sound/soc/mxs/Kconfig @@ -10,7 +10,7 @@ menuconfig SND_MXS_SOC if SND_MXS_SOC config SND_SOC_MXS_SGTL5000 - tristate "SoC Audio support for i.MX boards with sgtl5000" + tristate "SoC Audio support for MXS boards with sgtl5000" depends on I2C select SND_SOC_SGTL5000 help -- 1.7.1

2 1

Re: [alsa-devel] [PATCH] ASoC: Samsung: Fix build error
by Mark Brown 08 Aug '12

08 Aug '12

On Wed, Aug 08, 2012 at 11:34:43AM +0530, Sachin Kamat wrote: > Fixes the following build error: > In file included from arch/arm/mach-exynos/include/mach/dma.h:24:0, > from arch/arm/plat-samsung/include/plat/dma-ops.h:17, > from arch/arm/plat-samsung/include/plat/dma.h:128, > from sound/soc/samsung/pcm.c:23: > arch/arm/plat-samsung/include/plat/dma-pl330.h:106:8: > error: redefinition of ‘struct s3c2410_dma_client’ > arch/arm/plat-samsung/include/plat/dma.h:40:8: note: originally defined here > make[3]: *** [sound/soc/samsung/pcm.o] Error 1 Shouldn't this be being fixed in the headers? It looks like they reference and disagree with each other on Exynos (my primary development platform is S3C6410 based so I'd notice if it was a generic Samsung issue. Pasting the error message isn't really that useful unless the fix is obvious, it's better to explain in words what's wrong.

1 0

Re: [alsa-devel] adding an external dsp under soc-dsp framework
by Mark Brown 08 Aug '12

08 Aug '12

On Wed, Aug 08, 2012 at 11:21:20AM +0300, Ziv Haziz wrote: > >I n that case what you're saying above with a DAI link is exactly what > > you're supposed to do, I don't see any structural problem here? > Creating two dai links will create two separated devices which must be > open for setting configurations, but the dsp-codec dai cannot be started > (or I will get an error). This means changing the codec driver to > enable everything not from trigger callback. > Is it possible to have a dai link without a platform for data transfer? > I saw in the plumbers agenda you are going to talk on codec-codec > interface - do you have any preliminary suggestion? This is already supported in mainline, look at littlemill for one example user. Alternatively for older kernels you can easily support this from userspace by just not starting the DMA, this has been deployed for some considerable time on many systems (OpenMoko is one long standing mainline example).

1 0

[alsa-devel] [PATCH 1/2] hda-emu: Flush output before prompt
by David Henningsson 08 Aug '12

08 Aug '12

When stdout is redirected, there is a risk not all stdout is sent before the prompt is sent on stderr. Thanks to Jeremy Kerr for help with this issue. --- hda-ctlsh.c | 1 + hda-log.c | 5 +++++ include/hda-log.h | 1 + 3 files changed, 7 insertions(+) diff --git a/hda-ctlsh.c b/hda-ctlsh.c index 4c21341..d84cc71 100644 --- a/hda-ctlsh.c +++ b/hda-ctlsh.c @@ -851,6 +851,7 @@ int cmd_loop(FILE *fp) init_completion(); for (;;) { + hda_log_flush(); line = readline("> "); if (!line) break; diff --git a/hda-log.c b/hda-log.c index 65f3044..67ee8e2 100644 --- a/hda-log.c +++ b/hda-log.c @@ -179,6 +179,11 @@ int hda_log_level_set(int level) return saved; } +void hda_log_flush() +{ + fflush(logfp); +} + FILE *hda_get_logfp(void) { return logfp; diff --git a/include/hda-log.h b/include/hda-log.h index 2e2137b..8b0d392 100644 --- a/include/hda-log.h +++ b/include/hda-log.h @@ -18,6 +18,7 @@ int hda_log_init(const char *file, unsigned int flags); void hda_log(int level, const char *fmt, ...); void hda_log_printk(const char *fmt, ...); void hda_log_echo(int level, const char *fmt, ...); +void hda_log_flush(void); extern int hda_log_trap_on_error; -- 1.7.9.5

2 3

Re: [alsa-devel] [PATCHv2 - CA0132 HDA Codec 1/2] ALSA: Update Creative CA0132 codec to add DSP features.
by Takashi Iwai 08 Aug '12

08 Aug '12

At Mon, 30 Jul 2012 15:49:00 -0700, Ian Minett wrote: > > >> One thought we have is to handle the spin_lock_irqxxx() as a special > >> case or quirk for the CA0132 codec. Using an approach similar to > >> 'needs_damn_long_delay' in the CA0110 patch, we could define another > >> flag e.g. 'needs_trigger_irqsave' in hda_codec.h struct hda_bus{}. In > >> the CA0132 patch, we would set this flag, which would then be read in > >> hda_intel.c,azx_pcm_trigger(). Either spin_lock_irqxxx() or the current > >> spin_lock() would then be called depending on the flag condition. > >> What is your opinion on an approach like this? Would this be acceptable? > > >No. The fact that you are calling the PCM functions is already > >wrong. The irqsave() is just a side-effect by that, and we can forget > >about it completely now. > > >The only question is where to implement the DSP loader stuff and how. > > Ok, we understand. Given that the codec cannot call into the controller's > PCM interface to load the DSP image, is there an acceptable way you could > recommend for us to add this functionality to the module, without breaking > the architecture? Well, as mentioned earlier, we need to push it up to the controller layer, i.e. hda_intel.c. For example, add a new op for firmware DMA transfer in hda_bus_ops. Could you describe briefly the procedure for the DMA transfer of CA0132? The code looks too complex to follow. thanks, Takashi

2 6

[alsa-devel] [PATCH] ALSA: hda - Fix double quirk for Quanta FL1
by David Henningsson 08 Aug '12

08 Aug '12

The same ID is twice in the quirk table, so the second one is not used. You probably meant to chain them, like this? Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index daa5103..4f81dd4 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6099,6 +6099,8 @@ static const struct alc_fixup alc269_fixups[] = { [ALC269_FIXUP_PCM_44K] = { .type = ALC_FIXUP_FUNC, .v.func = alc269_fixup_pcm_44k, + .chained = true, + .chain_id = ALC269_FIXUP_QUANTA_MUTE }, [ALC269_FIXUP_STEREO_DMIC] = { .type = ALC_FIXUP_FUNC, @@ -6210,8 +6212,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x21fa, "Thinkpad X230", ALC269_FIXUP_LENOVO_DOCK), SND_PCI_QUIRK(0x17aa, 0x21fb, "Thinkpad T430s", ALC269_FIXUP_LENOVO_DOCK), SND_PCI_QUIRK(0x17aa, 0x2203, "Thinkpad X230 Tablet", ALC269_FIXUP_LENOVO_DOCK), - SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_QUANTA_MUTE), - SND_PCI_QUIRK(0x17aa, 0x3bf8, "Lenovo Ideapd", ALC269_FIXUP_PCM_44K), + SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), #if 0 -- 1.7.9.5

2 1

[alsa-devel] alsa-project.org is down
by Gabriel M. Beddingfield 08 Aug '12

08 Aug '12

Howdy, Several have noticed that alsa-project.org is down. I don't know if this is a planned outage or not. -gabriel

2 2