July 2011 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/3] [RME - HDSPM/MADI] Speed mode selector
by Adrian Knoth 29 Jul '11

29 Jul '11

Hi! Here's another small series of patches for the RME MADI cards. Most prominently, we now provide a control element to the user to explicitly select a frequency multiplier for the MADI link. This way, one can run applications at 64kHz and above (up to 192kHz) even when the card is not the clock master (read: is in slave mode). Cheers Adrian Knoth (3): ALSA: hdspm - Provide MADI speed mode selector on RME MADI and MADIface ALSA: hdspm - Fix reported external sample rate on RME MADI and MADIface ALSA: hdspm - Add firmware revision 0xcc for RME MADI sound/pci/rme9652/hdspm.c | 109 ++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 107 insertions(+), 2 deletions(-) -- 1.7.5.4

2 4

[alsa-devel] [PATCH alsa-lib 1/1] Add RME RPM to HDSP_IO_Type.
by Adrian Knoth 29 Jul '11

29 Jul '11

The hdsp.c driver supports the RME RPM devices, but we also need this information in alsa-lib for tools like hdsploader and hdspmixer. Signed-off-by: Adrian Knoth <adi(a)drcomp.erfurt.thur.de> diff --git a/include/sound/hdsp.h b/include/sound/hdsp.h index 0fc9e98..5adaf7b 100644 --- a/include/sound/hdsp.h +++ b/include/sound/hdsp.h @@ -28,6 +28,7 @@ typedef enum { Multiface, H9652, H9632, + RPM, Undefined, } HDSP_IO_Type; -- 1.7.5.4

2 1

Re: [alsa-devel] [PATCH] Sound: AudioScience HPI: Don't leak firmware if mem alloc fails
by Takashi Iwai 29 Jul '11

29 Jul '11

At Thu, 28 Jul 2011 21:48:27 +0200 (CEST), Jesper Juhl wrote: > > We leak the memory allocated to 'firmware' when we fail to > release_firmware() after a kmalloc() failure in hpi_dsp_code_open(). > This patch should take care of the leak. > > Signed-off-by: Jesper Juhl <jj(a)chaosbits.net> > --- > sound/pci/asihpi/hpidspcd.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > Build tested only. > > diff --git a/sound/pci/asihpi/hpidspcd.c b/sound/pci/asihpi/hpidspcd.c > index 3a7afa3..8d261ef 100644 > --- a/sound/pci/asihpi/hpidspcd.c > +++ b/sound/pci/asihpi/hpidspcd.c > @@ -85,8 +85,10 @@ short hpi_dsp_code_open(u32 adapter, void *os_data, struct dsp_code *dsp_code, > > HPI_DEBUG_LOG(DEBUG, "dsp code %s opened\n", fw_name); > dsp_code->pvt = kmalloc(sizeof(*dsp_code->pvt), GFP_KERNEL); > - if (!dsp_code->pvt) > + if (!dsp_code->pvt) { > + release_firmware(firmware); > return HPI_ERROR_MEMORY_ALLOC; > + } IMO, it's better to use the same error handling like others, i.e. "goto error2". But you want to pass a different error code, so we'd need to introduce an error code variable there... Takashi

1 0

Re: [alsa-devel] [PATCH] ASoC: Add device tree binding for WM8731
by Grant Likely 29 Jul '11

29 Jul '11

On Tue, Jul 26, 2011 at 09:02:11PM +0100, Mark Brown wrote: > Tested with the famous "hey, look! this compiles" test plan. > > Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > --- > Documentation/devicetree/bindings/sound/wm8731.txt | 18 ++++++++++++++++++ > sound/soc/codecs/wm8731.c | 12 ++++++++++++ > 2 files changed, 30 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/sound/wm8731.txt > > diff --git a/Documentation/devicetree/bindings/sound/wm8731.txt b/Documentation/devicetree/bindings/sound/wm8731.txt > new file mode 100644 > index 0000000..15f7004 > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/wm8731.txt > @@ -0,0 +1,18 @@ > +WM8731 audio CODEC > + > +This device supports both I2C and SPI (configured with pin strapping > +on the board). > + > +Required properties: > + > + - compatible : "wlf,wm8731" > + > + - reg : the I2C address of the device for I2C, the chip select > + number for SPI. > + > +Example: > + > +codec: wm8731@1a { > + compatible = "wlf,wm8731"; > + reg = <0x1a>; > +}; Acked by: Grant Likely <grant.likely(a)secretlab.ca> Although I'm sure some actual testing would be valuable before it is actually merged. :-) And there is one comment below. > diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c > index 76b4361..5ecc05a 100644 > --- a/sound/soc/codecs/wm8731.c > +++ b/sound/soc/codecs/wm8731.c > @@ -22,6 +22,7 @@ > #include <linux/platform_device.h> > #include <linux/regulator/consumer.h> > #include <linux/spi/spi.h> > +#include <linux/of_device.h> > #include <sound/core.h> > #include <sound/pcm.h> > #include <sound/pcm_params.h> > @@ -607,6 +608,11 @@ static struct snd_soc_codec_driver soc_codec_dev_wm8731 = { > .num_dapm_routes = ARRAY_SIZE(wm8731_intercon), > }; > > +static const struct of_device_id wm8731_of_match[] = { > + { .compatible = "wlf,wm8731", }, > + { } > +}; > + > #if defined(CONFIG_SPI_MASTER) > static int __devinit wm8731_spi_probe(struct spi_device *spi) > { > @@ -634,10 +640,13 @@ static int __devexit wm8731_spi_remove(struct spi_device *spi) > return 0; > } > > +MODULE_DEVICE_TABLE(spi, wm8731_of_match); MODULE_DEVICE_TABLE(of, wm8731_of_match); > + > static struct spi_driver wm8731_spi_driver = { > .driver = { > .name = "wm8731", > .owner = THIS_MODULE, > + .of_match_table = wm8731_of_match, > }, > .probe = wm8731_spi_probe, > .remove = __devexit_p(wm8731_spi_remove), > @@ -678,10 +687,13 @@ static const struct i2c_device_id wm8731_i2c_id[] = { > }; > MODULE_DEVICE_TABLE(i2c, wm8731_i2c_id); > > +MODULE_DEVICE_TABLE(i2c, wm8731_of_match); > + And this line can be dropped. i2c module info is separate from i2c and spi tables (although there may be some breakage here that need to be looked at. Right now I don't think the OF device ids get exported to udev for non-platform_devices. It needs some investigation.) > static struct i2c_driver wm8731_i2c_driver = { > .driver = { > .name = "wm8731", > .owner = THIS_MODULE, > + .of_match_table = wm8731_of_match, > }, > .probe = wm8731_i2c_probe, > .remove = __devexit_p(wm8731_i2c_remove), > -- > 1.7.5.4 > > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss(a)lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss

1 0

[alsa-devel] [RME - hdsp] Multiface/Digiface/RPM detection
by Adrian Knoth 28 Jul '11

28 Jul '11

Hi! I've recently added support for the RME RPM to hdspmixer. Unfortunately, I don't have one, it's been done blindly with user feedback. This very user now reports that he needs to upload the device firmware from windows. I've checked hdsploader, and of course, it needs patching. I'll take care in a second. More surprisingly, though, the kernel wasn't able to upload the firmware itself, because it fails to detect the RPM and hence tries to upload a multiface firmware. After reading the kernel source, I think the code in hdsp.c is wrong: if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) { hdsp_write(hdsp, HDSP_control2Reg, HDSP_VERSION_BIT); hdsp_write(hdsp, HDSP_control2Reg, HDSP_S_LOAD); if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) hdsp->io_type = RPM; else hdsp->io_type = Multiface; } else { hdsp->io_type = Digiface; } Who here owns a Digiface and can confirm or deny that the kernel correctly detects it as Digiface? Same for Multiface, though I guess since it's more or less the default, users wouldn't notice it. What's wrong with the code above? I think all occurrences of HDSP_control2Reg in hdsp_check_for_iobox need to be changed to HDSP_controlRegister and the second hdsp_fifo_wait needs to be inverted. But this is pure guesswork. If I come up with a patch, who here has a RPM, Digiface or Multiface to test it? TIA

1 0

Re: [alsa-devel] Build regressions/improvements in v3.0-rc7 (sound/isa/)
by Randy Dunlap 28 Jul '11

28 Jul '11

On Thu, 28 Jul 2011 14:24:49 -0400 Arnaud Lacombe wrote: > Hi, > > On Thu, Jul 28, 2011 at 2:11 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Thu, 28 Jul 2011 13:06:19 -0400, > > Arnaud Lacombe wrote: > >> > >> Hi, > >> > >> On Thu, Jul 28, 2011 at 12:44 PM, Randy Dunlap <rdunlap(a)xenotime.net> wrote: > >> > On Thu, 28 Jul 2011 12:36:27 -0400 Arnaud Lacombe wrote: > >> > > >> >> Hi, > >> >> > >> >> On Thu, Jul 28, 2011 at 12:21 PM, Randy Dunlap <rdunlap(a)xenotime.net> wrote: > >> >> > On Thu, 28 Jul 2011 11:17:09 +1000 Stephen Rothwell wrote: > >> >> > > >> >> >> Hi Randy, > >> >> >> > >> >> >> On Wed, 27 Jul 2011 12:13:20 -0700 Randy Dunlap <rdunlap(a)xenotime.net> wrote: > >> >> >> > > >> >> >> > On Mon, 25 Jul 2011 09:10:03 -0700 Randy Dunlap wrote: > >> >> >> > > >> >> >> > > On Mon, 25 Jul 2011 09:37:53 +0200 Takashi Iwai wrote: > >> >> >> > > > >> >> >> > > > At Sun, 24 Jul 2011 12:26:24 -0700, > >> >> >> > > > Randy Dunlap wrote: > >> >> >> > > > > > >> >> >> > > > > On Wed, 13 Jul 2011 21:33:30 +0200 Geert Uytterhoeven wrote: > >> >> >> > > > > > >> >> >> > > > > > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_disable': => 544 > >> >> >> > > > > > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 302 > >> >> >> > > > > > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_program': => 244 > >> >> >> > > > > > + src/sound/isa/es1688/es1688_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 509 > >> >> >> > > > > > + src/sound/isa/es1688/es1688_lib.c: error: implicit declaration of function 'snd_dma_program': => 417 > >> >> >> > > > > > + src/sound/isa/gus/gus_dma.c: error: implicit declaration of function 'snd_dma_disable': => 177 > >> >> >> > > > > > + src/sound/isa/gus/gus_dma.c: error: implicit declaration of function 'snd_dma_program': => 79 > >> >> >> > > > > > + src/sound/isa/gus/gus_pcm.c: error: implicit declaration of function 'snd_dma_pointer': => 619 > >> >> >> > > > > > + src/sound/isa/gus/gus_pcm.c: error: implicit declaration of function 'snd_dma_program': => 591 > >> >> >> > > > > > + src/sound/isa/sb/sb16_main.c: error: implicit declaration of function 'snd_dma_pointer': => 456 > >> >> >> > > > > > + src/sound/isa/sb/sb16_main.c: error: implicit declaration of function 'snd_dma_program': => 276 > >> >> >> > > > > > + src/sound/isa/sb/sb8_main.c: error: implicit declaration of function 'snd_dma_pointer': => 425 > >> >> >> > > > > > + src/sound/isa/sb/sb8_main.c: error: implicit declaration of function 'snd_dma_program': => 172 > >> >> >> > > > > > + src/sound/isa/sscape.c: error: implicit declaration of function 'snd_dma_program': => 481 > >> >> >> > > > > > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_disable': => 1695 > >> >> >> > > > > > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 1160 > >> >> >> > > > > > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_program': => 1025 > >> >> >> > > > > > >> >> >> > > > > All of these source files do #include <sound/core.h>, > >> >> >> > > > > but these missing/implicit functions are conditional: > >> >> >> > > > > > >> >> >> > > > > #ifdef CONFIG_ISA_DMA_API > >> >> >> > > > > #define DMA_MODE_NO_ENABLE 0x0100 > >> >> >> > > > > > >> >> >> > > > > void snd_dma_program(unsigned long dma, unsigned long addr, unsigned int size, unsigned short mode); > >> >> >> > > > > void snd_dma_disable(unsigned long dma); > >> >> >> > > > > unsigned int snd_dma_pointer(unsigned long dma, unsigned int size); > >> >> >> > > > > #endif > >> >> >> > > > > > >> >> >> > > > > so should these drivers all depend on ISA_DMA_API ? > >> >> >> > > > > >> >> >> > > > Yes, these are ISA sound cards, so they must have CONFIG_ISA and > >> >> >> > > > CONFIG_ISA_DMA. Although CONFIG_SND_SB8_DSP, CONFIG_SND_SB16_DSP > >> >> >> > > > and CONFIG_SND_WSS_LIB have no direct dependency, but the drivers > >> >> >> > > > selecting these are all in "if SND_ISA" in sound/isa/Kconfig. > >> >> >> > > > >> >> >> > > Hm, yes, they are. > >> >> >> > > > >> >> >> > > > > or should only pieces of each driver depend on ISA_DMA_API ? > >> >> >> > > > > >> >> >> > > > I wonder which configuration makes it possible. > >> >> >> > > > Did you see a similar problem with randconfig? > >> >> >> > > > >> >> >> > > No. This parisc allmodconfig file from linux-next builds has > >> >> >> > > CONFIG_SND_ISA=y but it does not have CONFIG_ISA_DMA_API enabled. Weird. > >> >> >> > > > >> >> >> > > Geert, do you know how this happens? > >> >> >> > > > >> >> >> > > parisc config: http://kisskb.ellerman.id.au/kisskb/buildresult/4323458/config/ > >> >> >> > > from this failed build: http://kisskb.ellerman.id.au/kisskb/buildresult/4323458/ > >> >> >> > > >> >> >> > How is CONFIG_ISA_DMA_API enabled in parisc allmodconfig? > >> >> >> > I don't see how that happens, and it's causing build errors... > >> >> >> > >> >> >> Sorry, but I don't understand the question. The problam is that > >> >> >> CONFIG_ISA_DMA_API is not enabled, right? On parisc, it is just (from > >> >> >> arch/parisc/Kconfig) > >> >> >> > >> >> >> config ISA_DMA_API > >> >> >> bool > >> >> >> > >> >> >> and nothing selects it. However, I would have expected an allmodconfig > >> >> >> to set it to y. Clearly I don't understan how allmodconfig works any > >> >> >> more :-( > >> >> >> > >> >> >> Michal, is my understanding correct? Is this a bug in allmodconfig? > >> >> > > >> >> > When I do: > >> >> > $ make ARCH=parisc O=PAR allmodconfig > >> >> > > >> >> > I don't get CONFIG_ISA_DMA_API enabled, so the question is simply > >> >> > how is the linux-next build system ending up with CONFIG_ISA_DMA_API enabled? > >> >> > > >> >> Where do you see that "linux-next build system ending up with > >> >> CONFIG_ISA_DMA_API enabled" ? > >> >> > >> >> From what I understood of the problem, the issue is that > >> >> CONFIG_ISA_DMA_API does _not_ ends up enabled. > >> > > >> > Thanks for catching me. > >> > > >> > The problem (second try) is that ISA SND drivers are being built (on parisc) > >> > even though ISA_DMA_API is not enabled -- and should not be enabled, > >> > so the ISA SND drivers should not be built. I think I have it right this time. > >> > > >> > From the parisc .config file listed above: > >> > > >> > CONFIG_SND_ISA=y > >> > CONFIG_SND_ADLIB=m > >> > CONFIG_SND_AD1816A=m > >> > CONFIG_SND_AD1848=m > >> > CONFIG_SND_ALS100=m > >> > CONFIG_SND_AZT1605=m > >> > CONFIG_SND_AZT2316=m > >> > CONFIG_SND_AZT2320=m > >> > CONFIG_SND_CMI8330=m > >> > > >> > > >> > etc. But none of these should be enabled. AFAIK. > >> > So how does this happen? > >> > > >> warning: (RADIO_MIROPCM20) selects SND_ISA which has unmet direct > >> dependencies (SOUND && !M68K && SND && ISA && ISA_DMA_API) > > > > Hm, I thought this was fixed by > > commit 4756fc64ecd628efa6f8296711d7dbcefabf25dd > > Author: Ralf Baechle <ralf(a)linux-mips.org> > > Date: Fri Jun 24 10:30:09 2011 -0300 > > > > [media] MEDIA: Fix non-ISA_DMA_API link failure of sound code > > > > OK, it landed after 3.0-rc7, so this problem must be fixed now? > % git checkout v3.0-rc7 > % make ARCH=parisc allmodconfig > [...] > warning: (RADIO_WL128X) selects TI_ST which has unmet direct > dependencies (MISC_DEVICES && NET && GPIOLIB) > warning: (RADIO_MIROPCM20) selects SND_ISA which has unmet direct > dependencies (SOUND && !M68K && SND && ISA && ISA_DMA_API) > warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP > && FUNCTION_TRACER && KMEMCHECK) selects FRAME_POINTER which has unmet > direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || > AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) > # > # configuration written to .config > # > % grep -c SND_ISA .config > 1 > > % git checkout v3.0 > Previous HEAD position was 620917d... Linux 3.0-rc7 > HEAD is now at 02f8c6a... Linux 3.0 > % make ARCH=parisc allmodconfig > [...] > warning: (RADIO_WL128X) selects TI_ST which has unmet direct > dependencies (MISC_DEVICES && NET && GPIOLIB) > warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP > && FUNCTION_TRACER && KMEMCHECK) selects FRAME_POINTER which has unmet > direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || > AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) > # > # configuration written to .config > # > % grep -c SND_ISA .config > 0 > > Look good to me. Great, thanks everyone. Yes, I was working on old data. Sorry about that. Anyway, lots of build errors now fixed by Ralf. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***

1 0

Re: [alsa-devel] Build regressions/improvements in v3.0-rc7 (sound/isa/)
by Takashi Iwai 28 Jul '11

28 Jul '11

At Thu, 28 Jul 2011 13:06:19 -0400, Arnaud Lacombe wrote: > > Hi, > > On Thu, Jul 28, 2011 at 12:44 PM, Randy Dunlap <rdunlap(a)xenotime.net> wrote: > > On Thu, 28 Jul 2011 12:36:27 -0400 Arnaud Lacombe wrote: > > > >> Hi, > >> > >> On Thu, Jul 28, 2011 at 12:21 PM, Randy Dunlap <rdunlap(a)xenotime.net> wrote: > >> > On Thu, 28 Jul 2011 11:17:09 +1000 Stephen Rothwell wrote: > >> > > >> >> Hi Randy, > >> >> > >> >> On Wed, 27 Jul 2011 12:13:20 -0700 Randy Dunlap <rdunlap(a)xenotime.net> wrote: > >> >> > > >> >> > On Mon, 25 Jul 2011 09:10:03 -0700 Randy Dunlap wrote: > >> >> > > >> >> > > On Mon, 25 Jul 2011 09:37:53 +0200 Takashi Iwai wrote: > >> >> > > > >> >> > > > At Sun, 24 Jul 2011 12:26:24 -0700, > >> >> > > > Randy Dunlap wrote: > >> >> > > > > > >> >> > > > > On Wed, 13 Jul 2011 21:33:30 +0200 Geert Uytterhoeven wrote: > >> >> > > > > > >> >> > > > > > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_disable': => 544 > >> >> > > > > > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 302 > >> >> > > > > > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_program': => 244 > >> >> > > > > > + src/sound/isa/es1688/es1688_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 509 > >> >> > > > > > + src/sound/isa/es1688/es1688_lib.c: error: implicit declaration of function 'snd_dma_program': => 417 > >> >> > > > > > + src/sound/isa/gus/gus_dma.c: error: implicit declaration of function 'snd_dma_disable': => 177 > >> >> > > > > > + src/sound/isa/gus/gus_dma.c: error: implicit declaration of function 'snd_dma_program': => 79 > >> >> > > > > > + src/sound/isa/gus/gus_pcm.c: error: implicit declaration of function 'snd_dma_pointer': => 619 > >> >> > > > > > + src/sound/isa/gus/gus_pcm.c: error: implicit declaration of function 'snd_dma_program': => 591 > >> >> > > > > > + src/sound/isa/sb/sb16_main.c: error: implicit declaration of function 'snd_dma_pointer': => 456 > >> >> > > > > > + src/sound/isa/sb/sb16_main.c: error: implicit declaration of function 'snd_dma_program': => 276 > >> >> > > > > > + src/sound/isa/sb/sb8_main.c: error: implicit declaration of function 'snd_dma_pointer': => 425 > >> >> > > > > > + src/sound/isa/sb/sb8_main.c: error: implicit declaration of function 'snd_dma_program': => 172 > >> >> > > > > > + src/sound/isa/sscape.c: error: implicit declaration of function 'snd_dma_program': => 481 > >> >> > > > > > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_disable': => 1695 > >> >> > > > > > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 1160 > >> >> > > > > > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_program': => 1025 > >> >> > > > > > >> >> > > > > All of these source files do #include <sound/core.h>, > >> >> > > > > but these missing/implicit functions are conditional: > >> >> > > > > > >> >> > > > > #ifdef CONFIG_ISA_DMA_API > >> >> > > > > #define DMA_MODE_NO_ENABLE 0x0100 > >> >> > > > > > >> >> > > > > void snd_dma_program(unsigned long dma, unsigned long addr, unsigned int size, unsigned short mode); > >> >> > > > > void snd_dma_disable(unsigned long dma); > >> >> > > > > unsigned int snd_dma_pointer(unsigned long dma, unsigned int size); > >> >> > > > > #endif > >> >> > > > > > >> >> > > > > so should these drivers all depend on ISA_DMA_API ? > >> >> > > > > >> >> > > > Yes, these are ISA sound cards, so they must have CONFIG_ISA and > >> >> > > > CONFIG_ISA_DMA. Although CONFIG_SND_SB8_DSP, CONFIG_SND_SB16_DSP > >> >> > > > and CONFIG_SND_WSS_LIB have no direct dependency, but the drivers > >> >> > > > selecting these are all in "if SND_ISA" in sound/isa/Kconfig. > >> >> > > > >> >> > > Hm, yes, they are. > >> >> > > > >> >> > > > > or should only pieces of each driver depend on ISA_DMA_API ? > >> >> > > > > >> >> > > > I wonder which configuration makes it possible. > >> >> > > > Did you see a similar problem with randconfig? > >> >> > > > >> >> > > No. This parisc allmodconfig file from linux-next builds has > >> >> > > CONFIG_SND_ISA=y but it does not have CONFIG_ISA_DMA_API enabled. Weird. > >> >> > > > >> >> > > Geert, do you know how this happens? > >> >> > > > >> >> > > parisc config: http://kisskb.ellerman.id.au/kisskb/buildresult/4323458/config/ > >> >> > > from this failed build: http://kisskb.ellerman.id.au/kisskb/buildresult/4323458/ > >> >> > > >> >> > How is CONFIG_ISA_DMA_API enabled in parisc allmodconfig? > >> >> > I don't see how that happens, and it's causing build errors... > >> >> > >> >> Sorry, but I don't understand the question. The problam is that > >> >> CONFIG_ISA_DMA_API is not enabled, right? On parisc, it is just (from > >> >> arch/parisc/Kconfig) > >> >> > >> >> config ISA_DMA_API > >> >> bool > >> >> > >> >> and nothing selects it. However, I would have expected an allmodconfig > >> >> to set it to y. Clearly I don't understan how allmodconfig works any > >> >> more :-( > >> >> > >> >> Michal, is my understanding correct? Is this a bug in allmodconfig? > >> > > >> > When I do: > >> > $ make ARCH=parisc O=PAR allmodconfig > >> > > >> > I don't get CONFIG_ISA_DMA_API enabled, so the question is simply > >> > how is the linux-next build system ending up with CONFIG_ISA_DMA_API enabled? > >> > > >> Where do you see that "linux-next build system ending up with > >> CONFIG_ISA_DMA_API enabled" ? > >> > >> From what I understood of the problem, the issue is that > >> CONFIG_ISA_DMA_API does _not_ ends up enabled. > > > > Thanks for catching me. > > > > The problem (second try) is that ISA SND drivers are being built (on parisc) > > even though ISA_DMA_API is not enabled -- and should not be enabled, > > so the ISA SND drivers should not be built. I think I have it right this time. > > > > From the parisc .config file listed above: > > > > CONFIG_SND_ISA=y > > CONFIG_SND_ADLIB=m > > CONFIG_SND_AD1816A=m > > CONFIG_SND_AD1848=m > > CONFIG_SND_ALS100=m > > CONFIG_SND_AZT1605=m > > CONFIG_SND_AZT2316=m > > CONFIG_SND_AZT2320=m > > CONFIG_SND_CMI8330=m > > > > > > etc. But none of these should be enabled. AFAIK. > > So how does this happen? > > > warning: (RADIO_MIROPCM20) selects SND_ISA which has unmet direct > dependencies (SOUND && !M68K && SND && ISA && ISA_DMA_API) Hm, I thought this was fixed by commit 4756fc64ecd628efa6f8296711d7dbcefabf25dd Author: Ralf Baechle <ralf(a)linux-mips.org> Date: Fri Jun 24 10:30:09 2011 -0300 [media] MEDIA: Fix non-ISA_DMA_API link failure of sound code OK, it landed after 3.0-rc7, so this problem must be fixed now? I'm not sure at which point this thread is focused on. Takashi

1 0

Re: [alsa-devel] Build regressions/improvements in v3.0-rc7 (sound/isa/)
by Randy Dunlap 28 Jul '11

28 Jul '11

On Thu, 28 Jul 2011 12:36:27 -0400 Arnaud Lacombe wrote: > Hi, >=20 > On Thu, Jul 28, 2011 at 12:21 PM, Randy Dunlap <rdunlap(a)xenotime.net> wro= te: > > On Thu, 28 Jul 2011 11:17:09 +1000 Stephen Rothwell wrote: > > > >> Hi Randy, > >> > >> On Wed, 27 Jul 2011 12:13:20 -0700 Randy Dunlap <rdunlap(a)xenotime.net>= wrote: > >> > > >> > On Mon, 25 Jul 2011 09:10:03 -0700 Randy Dunlap wrote: > >> > > >> > > On Mon, 25 Jul 2011 09:37:53 +0200 Takashi Iwai wrote: > >> > > > >> > > > At Sun, 24 Jul 2011 12:26:24 -0700, > >> > > > Randy Dunlap wrote: > >> > > > > > >> > > > > On Wed, 13 Jul 2011 21:33:30 +0200 Geert Uytterhoeven wrote: > >> > > > > > >> > > > > > =A0 + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit d= eclaration of function 'snd_dma_disable': =A0=3D> 544 > >> > > > > > =A0 + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit d= eclaration of function 'snd_dma_pointer': =A0=3D> 302 > >> > > > > > =A0 + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit d= eclaration of function 'snd_dma_program': =A0=3D> 244 > >> > > > > > =A0 + src/sound/isa/es1688/es1688_lib.c: error: implicit dec= laration of function 'snd_dma_pointer': =A0=3D> 509 > >> > > > > > =A0 + src/sound/isa/es1688/es1688_lib.c: error: implicit dec= laration of function 'snd_dma_program': =A0=3D> 417 > >> > > > > > =A0 + src/sound/isa/gus/gus_dma.c: error: implicit declarati= on of function 'snd_dma_disable': =A0=3D> 177 > >> > > > > > =A0 + src/sound/isa/gus/gus_dma.c: error: implicit declarati= on of function 'snd_dma_program': =A0=3D> 79 > >> > > > > > =A0 + src/sound/isa/gus/gus_pcm.c: error: implicit declarati= on of function 'snd_dma_pointer': =A0=3D> 619 > >> > > > > > =A0 + src/sound/isa/gus/gus_pcm.c: error: implicit declarati= on of function 'snd_dma_program': =A0=3D> 591 > >> > > > > > =A0 + src/sound/isa/sb/sb16_main.c: error: implicit declarat= ion of function 'snd_dma_pointer': =A0=3D> 456 > >> > > > > > =A0 + src/sound/isa/sb/sb16_main.c: error: implicit declarat= ion of function 'snd_dma_program': =A0=3D> 276 > >> > > > > > =A0 + src/sound/isa/sb/sb8_main.c: error: implicit declarati= on of function 'snd_dma_pointer': =A0=3D> 425 > >> > > > > > =A0 + src/sound/isa/sb/sb8_main.c: error: implicit declarati= on of function 'snd_dma_program': =A0=3D> 172 > >> > > > > > =A0 + src/sound/isa/sscape.c: error: implicit declaration of= function 'snd_dma_program': =A0=3D> 481 > >> > > > > > =A0 + src/sound/isa/wss/wss_lib.c: error: implicit declarati= on of function 'snd_dma_disable': =A0=3D> 1695 > >> > > > > > =A0 + src/sound/isa/wss/wss_lib.c: error: implicit declarati= on of function 'snd_dma_pointer': =A0=3D> 1160 > >> > > > > > =A0 + src/sound/isa/wss/wss_lib.c: error: implicit declarati= on of function 'snd_dma_program': =A0=3D> 1025 > >> > > > > > >> > > > > All of these source files do #include <sound/core.h>, > >> > > > > but these missing/implicit functions are conditional: > >> > > > > > >> > > > > #ifdef CONFIG_ISA_DMA_API > >> > > > > #define DMA_MODE_NO_ENABLE =A0 =A00x0100 > >> > > > > > >> > > > > void snd_dma_program(unsigned long dma, unsigned long addr, un= signed int size, unsigned short mode); > >> > > > > void snd_dma_disable(unsigned long dma); > >> > > > > unsigned int snd_dma_pointer(unsigned long dma, unsigned int s= ize); > >> > > > > #endif > >> > > > > > >> > > > > so should these drivers all depend on ISA_DMA_API ? > >> > > > > >> > > > Yes, these are ISA sound cards, so they must have CONFIG_ISA and > >> > > > CONFIG_ISA_DMA. =A0Although CONFIG_SND_SB8_DSP, CONFIG_SND_SB16_= DSP > >> > > > and CONFIG_SND_WSS_LIB have no direct dependency, but the drivers > >> > > > selecting these are all in "if SND_ISA" in sound/isa/Kconfig. > >> > > > >> > > Hm, yes, they are. > >> > > > >> > > > > or should only pieces of each driver depend on ISA_DMA_API ? > >> > > > > >> > > > I wonder which configuration makes it possible. > >> > > > Did you see a similar problem with randconfig? > >> > > > >> > > No. =A0This parisc allmodconfig file from linux-next builds has > >> > > CONFIG_SND_ISA=3Dy but it does not have CONFIG_ISA_DMA_API enabled= . =A0Weird. > >> > > > >> > > Geert, do you know how this happens? > >> > > > >> > > parisc config: =A0http://kisskb.ellerman.id.au/kisskb/buildresult/= 4323458/config/ > >> > > from this failed build: =A0http://kisskb.ellerman.id.au/kisskb/bui= ldresult/4323458/ > >> > > >> > How is CONFIG_ISA_DMA_API enabled in parisc allmodconfig? > >> > I don't see how that happens, and it's causing build errors... > >> > >> Sorry, but I don't understand the question. =A0The problam is that > >> CONFIG_ISA_DMA_API is not enabled, right? =A0On parisc, it is just (fr= om > >> arch/parisc/Kconfig) > >> > >> config ISA_DMA_API > >> =A0 =A0 =A0 bool > >> > >> and nothing selects it. =A0However, I would have expected an allmodcon= fig > >> to set it to y. =A0Clearly I don't understan how allmodconfig works any > >> more :-( > >> > >> Michal, is my understanding correct? =A0Is this a bug in allmodconfig? > > > > When I do: > > $ make ARCH=3Dparisc O=3DPAR allmodconfig > > > > I don't get CONFIG_ISA_DMA_API enabled, so the question is simply > > how is the linux-next build system ending up with CONFIG_ISA_DMA_API en= abled? > > > Where do you see that "linux-next build system ending up with > CONFIG_ISA_DMA_API enabled" ? >=20 > From what I understood of the problem, the issue is that > CONFIG_ISA_DMA_API does _not_ ends up enabled. Thanks for catching me. The problem (second try) is that ISA SND drivers are being built (on parisc) even though ISA_DMA_API is not enabled -- and should not be enabled, so the ISA SND drivers should not be built. I think I have it right this t= ime. _From the parisc .config file listed above: CONFIG_SND_ISA=3Dy CONFIG_SND_ADLIB=3Dm CONFIG_SND_AD1816A=3Dm CONFIG_SND_AD1848=3Dm CONFIG_SND_ALS100=3Dm CONFIG_SND_AZT1605=3Dm CONFIG_SND_AZT2316=3Dm CONFIG_SND_AZT2320=3Dm CONFIG_SND_CMI8330=3Dm etc. But none of these should be enabled. AFAIK. So how does this happen? > - Arnaud >=20 > > What commands are used to cause this? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***

1 0

Re: [alsa-devel] Build regressions/improvements in v3.0-rc7 (sound/isa/)
by Randy Dunlap 28 Jul '11

28 Jul '11

On Wed, 13 Jul 2011 21:33:30 +0200 Geert Uytterhoeven wrote: > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_disable': => 544 > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 302 > + src/sound/isa/ad1816a/ad1816a_lib.c: error: implicit declaration of function 'snd_dma_program': => 244 > + src/sound/isa/es1688/es1688_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 509 > + src/sound/isa/es1688/es1688_lib.c: error: implicit declaration of function 'snd_dma_program': => 417 > + src/sound/isa/gus/gus_dma.c: error: implicit declaration of function 'snd_dma_disable': => 177 > + src/sound/isa/gus/gus_dma.c: error: implicit declaration of function 'snd_dma_program': => 79 > + src/sound/isa/gus/gus_pcm.c: error: implicit declaration of function 'snd_dma_pointer': => 619 > + src/sound/isa/gus/gus_pcm.c: error: implicit declaration of function 'snd_dma_program': => 591 > + src/sound/isa/sb/sb16_main.c: error: implicit declaration of function 'snd_dma_pointer': => 456 > + src/sound/isa/sb/sb16_main.c: error: implicit declaration of function 'snd_dma_program': => 276 > + src/sound/isa/sb/sb8_main.c: error: implicit declaration of function 'snd_dma_pointer': => 425 > + src/sound/isa/sb/sb8_main.c: error: implicit declaration of function 'snd_dma_program': => 172 > + src/sound/isa/sscape.c: error: implicit declaration of function 'snd_dma_program': => 481 > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_disable': => 1695 > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_pointer': => 1160 > + src/sound/isa/wss/wss_lib.c: error: implicit declaration of function 'snd_dma_program': => 1025 All of these source files do #include <sound/core.h>, but these missing/implicit functions are conditional: #ifdef CONFIG_ISA_DMA_API #define DMA_MODE_NO_ENABLE 0x0100 void snd_dma_program(unsigned long dma, unsigned long addr, unsigned int size, unsigned short mode); void snd_dma_disable(unsigned long dma); unsigned int snd_dma_pointer(unsigned long dma, unsigned int size); #endif so should these drivers all depend on ISA_DMA_API ? or should only pieces of each driver depend on ISA_DMA_API ? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***

3 5

[alsa-devel] Hardware audio decoder driver design
by Nikita V. Youshchenko 28 Jul '11

28 Jul '11

Hello. Soon I will work on a linux kernel driver for a custom audio decoder device that is being developed by a company I work for. If not going into details, that devices reads A52-encoded stream from system memory, and writes raw pcm stream to system memory. Simplest thing to do is - implement a character device, where user-space will write encoded stream, and from where user-space will read decoded stream. (driver for similar hardware, located at http://sourceforge.net/projects/vs10xx/, does that). However, perhaps a better architecture (e.g. in-kernel intergation with an audio sink) is possible? I'm looking for any related information - e.g. ideas on what interface to implement, examples of drivers for similar devices, etc. Thanks on any hints. Nikita Youshchenko, embedded linux developer.

3 2