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

[alsa-devel] Suspend/Resume failure of Alsa but OSS emulation still works
by Shane Volpe 05 Aug '11

05 Aug '11

My embedded system's audio is not resuming after the system resumes from suspend to RAM, below is a detailed discription of the problem and what I have done, to date, to identify the source of the problem. I have tested the following scenario with several audio applications such as Alsa aplay and ogg123: If I have an audio player (aplay or ogg123) using Alsa and I suspend my system to RAM when the system wakes up (resumes) there is no sound. If I kill the audio player and start it back up the sound returns so it seems the act of opening and closing Alsa fixes the failure. During the "no sound state" I also opened alsamixer and adjusted (successfully) several alsa settings including volume but the sound still did not resume until I restarted the player. I also configured one player to use the OSS (emulated by Alsa). When I used the emulated OSS audio driver (/dev/dsp) the sound did resume after the system woke up (resumed) from memory so everything WORKED! I then configured the player back to use the native Alsa driver and again there was no sound after resume. Has anyone seen this issue before or does anyone have additional tests or debugging ideas they can recommend to further narrow down the issue. I'm very comfortable with modifying and compiling the Kernel so please do not limit your suggestions to user-space tweaks. Embedded System Information: Processor: ARM/Xscale (PXA270) Audio Codec: AC97 (UCB1400) alsa lib version: 1.0.24.1 Linux Kernel Version: 2.6.39.2 Regards, Shane

1 2

[alsa-devel] memory leak in mmap ops
by Scott Jiang 04 Aug '11

04 Aug '11

Hi all, I found there is a memory leak about 128K every time in linux-2.6.34, but it doesn't exist in linux-3.0. If I use mmap ops in driver the bug will come out, while use copy ops no memory leak. This driver is based on asoc. I tested with aplay to play a wav file. Because there is a lot of changes in ALSA between 2.6.34 and 3.0, so can anyone who familiar with the change history tell me which patch has solved this bug? Thanks in advance. Scott

2 2

[alsa-devel] Timer interface
by Nenad Sljivic 02 Aug '11

02 Aug '11

Hi, I am extending my ALSA driver in order to support software mixing. Driver currently supports both MMAP and RW access modes. However, I am still not able to use dmix since it requires timer interface to be implemented. My hardware does not generate interrupts at the period boundary but issues timer interrupts at a fixed timer rate. Could you please point me to the document or sample driver that can help me to fully understand timer interface concept (especially for High frequency timer interrupts)? Thanks, Nenad

2 4

[alsa-devel] [PATCH] ALSA: asihpi - Clarify adapter index validity check.
by linux＠audioscience.com 01 Aug '11

01 Aug '11

From: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> Avoids assigning possibly invalid address to pa, even if it is never dereferenced. Signed-off-by: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> --- sound/pci/asihpi/hpioctl.c | 19 ++++++++++++------- 1 files changed, 12 insertions(+), 7 deletions(-) diff --git a/sound/pci/asihpi/hpioctl.c b/sound/pci/asihpi/hpioctl.c index 9683f84..a32502e 100644 --- a/sound/pci/asihpi/hpioctl.c +++ b/sound/pci/asihpi/hpioctl.c @@ -177,16 +177,21 @@ long asihpi_hpi_ioctl(struct file *file, unsigned int cmd, unsigned long arg) } else { u16 __user *ptr = NULL; u32 size = 0; - + u32 adapter_present; /* -1=no data 0=read from user mem, 1=write to user mem */ int wrflag = -1; - u32 adapter = hm->h.adapter_index; - struct hpi_adapter *pa = &adapters[adapter]; + struct hpi_adapter *pa; + + if (hm->h.adapter_index < HPI_MAX_ADAPTERS) { + pa = &adapters[hm->h.adapter_index]; + adapter_present = pa->type; + } else { + adapter_present = 0; + } - if ((adapter >= HPI_MAX_ADAPTERS) || (!pa->type)) { - hpi_init_response(&hr->r0, HPI_OBJ_ADAPTER, - HPI_ADAPTER_OPEN, - HPI_ERROR_BAD_ADAPTER_NUMBER); + if (!adapter_present) { + hpi_init_response(&hr->r0, hm->h.object, + hm->h.function, HPI_ERROR_BAD_ADAPTER_NUMBER); uncopied_bytes = copy_to_user(puhr, hr, sizeof(hr->h)); -- 1.7.0.4

3 4

[alsa-devel] [PATCH -next] sound: rtctimer.c needs module.h
by Randy Dunlap 30 Jul '11

30 Jul '11

From: Randy Dunlap <rdunlap(a)xenotime.net> rtctimer.c uses interfaces from linux/module.h, so it should include that file. This fixes build errors. Signed-off-by: Randy Dunlap <rdunlap(a)xenotime.net> --- sound/core/rtctimer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20110729.orig/sound/core/rtctimer.c +++ linux-next-20110729/sound/core/rtctimer.c @@ -22,7 +22,7 @@ #include <linux/init.h> #include <linux/interrupt.h> -#include <linux/moduleparam.h> +#include <linux/module.h> #include <linux/log2.h> #include <sound/core.h> #include <sound/timer.h>

2 1

Re: [alsa-devel] [RFC PATCH] ARM ASoC: add sound driver for imx27pdk using mc13783 codec
by Jürgen Lambrecht 29 Jul '11

29 Jul '11

2011/7/27 Philippe Rétornaz <philippe.retornaz(a)epfl.ch>: > Hi > > Le vendredi 8 juillet 2011 16:19:22, Lambrecht Jürgen a écrit : >> indeed, doesn't work at all. I know it used to work on 2.6.34. >> We also have a fsl linux 2.6.22 were it works. >> I must say: when i use aplay to play a mono file, then there is no >> error, it just never ends, and no sound also. >> For a stereo file, it gives the error. >> Mark also that when I use madplay (v0.15.2) (or mp3play) to play a mono >> or stereo mp3, it allocates 3 DMA channels, but only frees one after the >> error. >> > > Did you made any progress on this ? Yes. Sascha fixed it, and will commit it. Regards, Jürgen > > Regards, > > Philippe > > >

1 0

[alsa-devel] [PATCH 0/2] hdsploader/hdspmixer: Fix RPM constant
by Adrian Knoth 29 Jul '11

29 Jul '11

As noticed by Takashi, the RPM constant needs to be 4, not 5. For hdspmixer, this doesn't matter, for hdsploader, it's essential. Adrian Knoth (2): hdsploader: Fix temporary RPM constant hdspmixer: Fix temporary RPM constant hdsploader/hdsploader.c | 2 +- hdspmixer/src/HDSPMixerCard.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.5.4

2 3

[alsa-devel] [PATCH] ASoC: sgtl5000: add device tree probe support
by Shawn Guo 29 Jul '11

29 Jul '11

It adds device tree probe support for sgtl5000 driver. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> Cc: Grant Likely <grant.likely(a)secretlab.ca> Cc: Zeng Zhaoming <zhaoming.zeng(a)freescale.com> Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- .../bindings/sound/soc/codecs/fsl-sgtl5000.txt | 11 +++++++++++ sound/soc/codecs/sgtl5000.c | 8 ++++++++ 2 files changed, 19 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt diff --git a/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt b/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt new file mode 100644 index 0000000..2c3cd41 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt @@ -0,0 +1,11 @@ +* Freescale SGTL5000 Stereo Codec + +Required properties: +- compatible : "fsl,sgtl5000". + +Example: + +codec: sgtl5000@0a { + compatible = "fsl,sgtl5000"; + reg = <0x0a>; +}; diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 76258f2..cf6eea8 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -20,6 +20,7 @@ #include <linux/regulator/driver.h> #include <linux/regulator/machine.h> #include <linux/regulator/consumer.h> +#include <linux/of_device.h> #include <sound/core.h> #include <sound/tlv.h> #include <sound/pcm.h> @@ -1494,10 +1495,17 @@ static const struct i2c_device_id sgtl5000_id[] = { MODULE_DEVICE_TABLE(i2c, sgtl5000_id); +static const struct of_device_id sgtl5000_dt_ids[] = { + { .compatible = "fsl,sgtl5000", }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(i2c, sgtl5000_dt_ids); + static struct i2c_driver sgtl5000_i2c_driver = { .driver = { .name = "sgtl5000", .owner = THIS_MODULE, + .of_match_table = sgtl5000_dt_ids, }, .probe = sgtl5000_i2c_probe, .remove = __devexit_p(sgtl5000_i2c_remove), -- 1.7.4.1

4 5

Re: [alsa-devel] Copy ALSA buffer to the buffer allocated in my driver.
by Clemens Ladisch 29 Jul '11

29 Jul '11

`/ET!-i1S!-i wrote: > Actually i need to stream the audio data to other system through kernel > socket. Why aren't you using PulseAudio? Regards, Clemens

1 0

[alsa-devel] [PATCH 0/3] [RME - HDSP] Userlevel support for RPM
by Adrian Knoth 29 Jul '11

29 Jul '11

Hi! Here's a series of recent work on RME RPM support. Confirmed to be working by our one and only user so far. ;) As soon as alsa-lib supports the RPM (it's a single define), I'll drop the temporary define in both, hdsploader and hdspmixer. RPM users: note that the current kernel code seems to be broken and does not correctly detect your RPM box. More magic could be added to hdsploader to provide a temporary workaround. Cheers Adrian Knoth (3): hdspmixer: Add support for RME RPM hdsploader: Add support for RME RPM hdsploader: Temporary define for RPM hdsploader/hdsploader.c | 7 +++++++ hdspmixer/src/HDSPMixerCard.cxx | 11 +++++++++++ hdspmixer/src/HDSPMixerCard.h | 5 +++++ hdspmixer/src/HDSPMixerOutput.cxx | 15 +++++++++++++++ hdspmixer/src/HDSPMixerSelector.cxx | 7 +++++++ hdspmixer/src/HDSPMixerWindow.cxx | 4 ++++ hdspmixer/src/channelmap.cxx | 12 ++++++++++++ hdspmixer/src/channelmap.h | 5 +++++ hdspmixer/src/hdspmixer.cxx | 4 ++++ 9 files changed, 70 insertions(+), 0 deletions(-) -- 1.7.5.4

2 9

[alsa-devel] [PATCH] ASoC: Parse board ID/revision information from WM1250-EV1 board
by Mark Brown 29 Jul '11

29 Jul '11

The WM1250-EV1 board has an ID chip on it, check the board ID and display the board revision during startup. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm1250-ev1.c | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm1250-ev1.c b/sound/soc/codecs/wm1250-ev1.c index bcc2089..bbcf9ec 100644 --- a/sound/soc/codecs/wm1250-ev1.c +++ b/sound/soc/codecs/wm1250-ev1.c @@ -56,8 +56,26 @@ static struct snd_soc_codec_driver soc_codec_dev_wm1250_ev1 = { }; static int __devinit wm1250_ev1_probe(struct i2c_client *i2c, - const struct i2c_device_id *id) + const struct i2c_device_id *i2c_id) { + int ret, id, board, rev; + + board = i2c_smbus_read_byte_data(i2c, 0); + if (board < 0) { + dev_err(&i2c->dev, "Failed to read ID: %d\n", ret); + return ret; + } + + id = (board & 0xfe) >> 2; + rev = board & 0x3; + + if (id != 1) { + dev_err(&i2c->dev, "Unknown board ID %d\n", id); + return -ENODEV; + } + + dev_info(&i2c->dev, "revision %d\n", rev); + return snd_soc_register_codec(&i2c->dev, &soc_codec_dev_wm1250_ev1, &wm1250_ev1_dai, 1); } -- 1.7.5.4

1 0

[alsa-devel] Copy ALSA buffer to the buffer allocated in my driver.
by `/ET!-i1S!-i 29 Jul '11

29 Jul '11

Hi everyone. I'm writing a virtual ALSA driver for a playback device, with the help of dummy driver available at the linux kernel source code. I need to manually copy data from the ALSA buffer to my buffer. I have no idea how to do this, since dummy driver has completely discarded handling of buffers. So can anyone please provide a sample code to copy the audio data to the my buffer allocated in the driver. Is it ok to use the hrtimer interrupts (which is used in dummy driver) or mutex / spinlocks for my driver. Best regards, cherry

2 1

[alsa-devel] mmap ops in snd_pcm_ops
by Scott Jiang 29 Jul '11

29 Jul '11

Hi all, I found there is a memory leak about 128K every time in linux-2.6.34, but it doesn't exist in linux-3.0. If I use mmap ops in driver the bug will come out, while use copy ops no memory leak. I tested with aplay to play a wav file. Because there is a lot of changes in ALSA between 2.6.34 and 3.0, so can anyone familiar with the change history tell me which patch has solved this bug? Thanks in advance. Scott

1 0

[alsa-devel] [PATCH] ASoC: Disable wm_hubs periodic DC servo update
by Mark Brown 29 Jul '11

29 Jul '11

This does not function correctly in all circumstances so disable the periodic updates unconditionally for stable; a future patch will reenable where appropriate. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm_hubs.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c index 4de6794..4416a76 100644 --- a/sound/soc/codecs/wm_hubs.c +++ b/sound/soc/codecs/wm_hubs.c @@ -440,9 +440,8 @@ static int hp_event(struct snd_soc_dapm_widget *w, reg |= WM8993_HPOUT1L_DLY | WM8993_HPOUT1R_DLY; snd_soc_write(codec, WM8993_ANALOGUE_HP_0, reg); - /* Smallest supported update interval */ snd_soc_update_bits(codec, WM8993_DC_SERVO_1, - WM8993_DCS_TIMER_PERIOD_01_MASK, 1); + WM8993_DCS_TIMER_PERIOD_01_MASK, 0); calibrate_dc_servo(codec); -- 1.7.5.4

2 1

[alsa-devel] [PATCH] SOUND: Fix txx9aclc.c build
by Ralf Baechle 29 Jul '11

29 Jul '11

552d1ef6b5a98d7b95959d5b139071e3c90cebf1 [ASoC: core - Optimise and refactor pcm_new() to pass only rtd] breaks compilation of txx9aclc.c: CC [M] sound/soc/txx9/txx9aclc.o /home/ralf/src/linux/linux-mips/sound/soc/txx9/txx9aclc.c: In function 'txx9aclc_pcm_new': /home/ralf/src/linux/linux-mips/sound/soc/txx9/txx9aclc.c:318:3: error: 'card' undeclared (first use in this function) /home/ralf/src/linux/linux-mips/sound/soc/txx9/txx9aclc.c:318:3: note: each undeclared identifier is reported only once for each function it appears in make[5]: *** [sound/soc/txx9/txx9aclc.o] Error 1 Fixed by providing a definition for card. Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> sound/soc/txx9/txx9aclc.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/txx9/txx9aclc.c b/sound/soc/txx9/txx9aclc.c index 34aa972..3de99af 100644 --- a/sound/soc/txx9/txx9aclc.c +++ b/sound/soc/txx9/txx9aclc.c @@ -290,6 +290,7 @@ static void txx9aclc_pcm_free_dma_buffers(struct snd_pcm *pcm) static int txx9aclc_pcm_new(struct snd_soc_pcm_runtime *rtd) { + struct snd_card *card = rtd->card->snd_card; struct snd_soc_dai *dai = rtd->cpu_dai; struct snd_pcm *pcm = rtd->pcm; struct platform_device *pdev = to_platform_device(dai->platform->dev);

2 1

[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