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

[alsa-devel] "modprobe snd_hda_intel" crashes on my hardware
by Abdelghani Ouchabane 27 Sep '11

27 Sep '11

Description of problem: I have a customized sound hardware, it looks that it doesn't follow the standard 100 %. I had to patch the sound driver under fedora 9 ( 2.6.27.25-78.2.56.fc9.i686 ), exactly I patched ./sound/pci/hda/patch_via.c by forcing the driver to program the codec. It was working fine in Fedora 9. But in Fedora 15, I have tried the patch the ./sound/pci/hda/patch_via.c, but unfortunately the path doesn't work. Please : could you help me to figure out how to patch ./sound/pci/hda/patch_via.c to make sound works in my hardware. Version-Release number of selected component (if applicable): kernel-2.6.40.3-0.fc15.i686.rpm Additional info: **************************************************************************************************************************************************************************** dmesg log : [ 95.366164] HDA Intel 0000:00:1b.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10 [ 95.366209] HDA Intel 0000:00:1b.0: setting latency timer to 64 [ 95.398391] hda_codec: Cannot set up configuration from BIOS. Using genenic mode... [ 95.398470] BUG: unable to handle kernel NULL pointer dereference at (null) [ 95.398477] IP: [<f83740ac>] via_build_pcms+0x60/0xdc [snd_hda_codec_via] [ 95.398494] *pde = 3173f067 *pte = 00000000 [ 95.398501] Oops: 0000 [#1] PREEMPT [ 95.398509] Modules linked in: snd_hda_codec_via snd_hda_intel(+) snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc ipv6 fakephp cgosdrv(P) joydev mcs7830 usbnet mii usbtouchscreen iTCO_wdt i2c_i801 pciehp iTCO_vendor_support serio_raw xfs i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 95.398558] [ 95.398564] Pid: 4208, comm: modprobe Tainted: P 2.6.40.3-0.119.delos.i686 #1 [ 95.398572] EIP: 0060:[<f83740ac>] EFLAGS: 00010246 CPU: 0 [ 95.398581] EIP is at via_build_pcms+0x60/0xdc [snd_hda_codec_via] [ 95.398587] EAX: f174f000 EBX: 00000000 ECX: 00000000 EDX: dd58f400 [ 95.398592] ESI: f837c760 EDI: f174f120 EBP: f17afd28 ESP: f17afd20 [ 95.398597] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 95.398603] Process modprobe (pid: 4208, ti=f17ae000 task=f0e5be30 task.ti=f17ae000) [ 95.398607] Stack: [ 95.398610] dd58f400 00000001 f17afd68 f81ef28a 00000050 f81f6511 f16aa960 f16aa968 [ 95.398622] 00000001 11061708 2d646e73 2d616468 65646f63 64692d63 3031313a dd58f400 [ 95.398634] f578642c 00000001 f17afd78 f81f5aaf f171da00 f5786424 f17afde4 f816e6fd [ 95.398645] Call Trace: [ 95.398665] [<f81ef28a>] snd_hda_codec_build_pcms+0x25/0x230 [snd_hda_codec] [ 95.398685] [<f81f5aaf>] snd_hda_build_pcms+0x17/0x2e [snd_hda_codec] [ 95.398699] [<f816e6fd>] azx_probe+0x9a6/0xa44 [snd_hda_intel] [ 95.398713] [<f816d1cd>] ? azx_pcm_open+0x1c8/0x1c8 [snd_hda_intel] [ 95.398725] [<f816d394>] ? azx_acquire_irq+0x9b/0x9b [snd_hda_intel] [ 95.398737] [<f816dbb9>] ? kzalloc.constprop.5+0x14/0x14 [snd_hda_intel] [ 95.398749] [<f816db45>] ? azx_resume+0xfa/0xfa [snd_hda_intel] [ 95.398761] [<f816d9e7>] ? azx_init_chip+0x1d5/0x1d5 [snd_hda_intel] [ 95.398775] [<c05dfcc1>] pci_device_probe+0x5e/0xa7 [ 95.398787] [<c06616ef>] driver_probe_device+0x121/0x1fc [ 95.398794] [<c05dfc39>] ? pci_match_device+0x5d/0x68 [ 95.398802] [<c0661812>] __driver_attach+0x48/0x64 [ 95.398810] [<c0660931>] bus_for_each_dev+0x42/0x6b [ 95.398817] [<c0661350>] driver_attach+0x1f/0x23 [ 95.398824] [<c06617ca>] ? driver_probe_device+0x1fc/0x1fc [ 95.398832] [<c0660fcb>] bus_add_driver+0xca/0x210 [ 95.398840] [<c0661c2a>] driver_register+0x84/0xe3 [ 95.398848] [<c05e03f7>] __pci_register_driver+0x34/0x91 [ 95.398862] [<f820c017>] alsa_card_azx_init+0x17/0x19 [snd_hda_intel] [ 95.398871] [<c0401173>] do_one_initcall+0x8b/0x138 [ 95.398878] [<f820c000>] ? 0xf820bfff [ 95.398889] [<c045945f>] sys_init_module+0x12bd/0x14dc [ 95.398905] [<c07c0e94>] syscall_call+0x7/0xb [ 95.398909] Code: 00 f3 a5 8d b8 f0 00 00 00 8b 48 50 8b 70 3c 0f b7 09 66 89 88 cc 00 00 00 b9 0c 00 00 00 f3 a5 8b 88 9c 00 00 00 66 83 78 5c 00 <0f> b7 09 66 89 88 fc 00 00 00 8b 48 64 89 88 c8 00 00 00 75 0a [ 95.398972] EIP: [<f83740ac>] via_build_pcms+0x60/0xdc [snd_hda_codec_via] SS:ESP 0068:f17afd20 [ 95.398984] CR2: 0000000000000000 [ 95.488158] ---[ end trace e7a4603bcd7d8946 ]--- **************************************************************************************************************************************************************************** lspci -v : 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at fea38000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [130] Root Complex Link Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel **************************************************************************************************************************************************************************** * Please, I need your great help to make my sound card works as I did for Fedora 9. * Or any workaround. * If you need any information, please don't hesitate. **************************************************************************************************************************************************************************** * I have used the attached patch to force the driver to program the code. **************************************************************************************************************************************************************************** Thanks a lot in advance.

1 1

Re: [alsa-devel] [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails
by Tabi Timur-B04825 27 Sep '11

27 Sep '11

Axel Lin wrote: > Call platform_device_put() instead of platform_device_unregister() if > platform_device_add() fails. What's wrong with calling platform_device_unregister()? -- Timur Tabi Linux kernel developer at Freescale

2 1

[alsa-devel] [PATCH] ASoC: Flush Samsung DMA on free
by Mark Brown 27 Sep '11

27 Sep '11

Ever since it was written the Samsung DMA driver has had a TODO in the hw_free() function wondering if we need to flush the DMA buffers. Up until now the answer has been no but with the recent improvements Boojin has done to the DMA infrastructure for the Samsung port the answer has changed to yes for at least S3C6410 systems. If we don't then when we next prepare() the channel the API will get confused trying to run callbacks on the transfers hanging around from the previous time the stream was open and oops. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Kukjin, this should probably get added to your branch assuming it's OK for other CPUs. sound/soc/samsung/dma.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c index 851346f..2d622b6 100644 --- a/sound/soc/samsung/dma.c +++ b/sound/soc/samsung/dma.c @@ -198,10 +198,10 @@ static int dma_hw_free(struct snd_pcm_substream *substream) pr_debug("Entered %s\n", __func__); - /* TODO - do we need to ensure DMA flushed */ snd_pcm_set_runtime_buffer(substream, NULL); if (prtd->params) { + prtd->params->ops->flush(prtd->params->ch); prtd->params->ops->release(prtd->params->ch, prtd->params->client); prtd->params = NULL; -- 1.7.6.3

2 1

Re: [alsa-devel] Questions for dummy codec driver
by Mark Brown 26 Sep '11

26 Sep '11

On Thu, Sep 22, 2011 at 09:42:14AM +0800, Leo Yan wrote: > On our platform, there have some devices (like hdmi/bt) do not need > config from the CODEC driver, they have their own s/w stack and > interface to configure; for the audio driver, just need to set the > I2S/PCM timing for them. So if there have a common dummy codec > driver, then it can meet our requirement well. Otherwise, there will > have some duplicate codes for these dummy codecs. The general thought here has been that for dumb CODECs the boilerplate is sufficiently small and simple to mean that the discoverability from writing a skeletal driver outweighs the cost of having it kicking around - while there is some boilerplate there it's easier for someone to grab and use this code than it is to work out how exactly to translate the datasheets into code each time they encounter the part. However, a sufficiently well written generic driver would maintain that advantage while reducing the duplication.

1 0

Re: [alsa-devel] Adding ELD control to alsa-lib hdmi device
by David Henningsson 26 Sep '11

26 Sep '11

On 09/23/2011 08:46 PM, Pierre-Louis Bossart wrote: > Hi, > Now that I almost done with exposing a read-only ELD control for HDA/HDMI > outputs, I was wondering how to read it from user-land. PulseAudio and > others rely on the 'hdmi' device, and apparently I can't access this new ELD > control, I have to use the 'hw:x,y' details. The hdmi:x(,y) device is only used for pcm. For opening the mixer, hw:x (never hw:x,y - that's pcm only as well) is used as the device string. > I really don't understand much to alsa-lib... Can I expose this new control > through the ALSA configuration files where the hdmi device is defined? Or is > there a way to infer the card and device number actually used by an alsa-lib > plugin? Or do I have to add code to propagate the information from > hardware-level to higher-level plugins? > Thanks for your feedback! I'm not the expert here, but if I were you, I would run amixer -D hw:x contents amixer -D hw:x scontents To see if your controls show up there. If it shows up in scontents, that would be the "simple" mixer interface that PulseAudio uses. If not, using the control api (as being done by "contents") should work. Anyway, reading the source code to amixer would then be the first step towards understanding how to enumerate and read mixer controls. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[alsa-devel] [PATCH] usb-audio: Check for possible chip NULL pointer before clearing probing flag
by Thomas Pfaff 26 Sep '11

26 Sep '11

Before clearing the probing flag in the error exit path, check that the chip pointer is not NULL. Signed-off-by: Thomas Pfaff <tpfaff(a)gmx.net> --- diff -urp a/sound/usb/card.c b/sound/usb/card.c --- a/sound/usb/card.c 2011-09-26 14:58:02.468672118 +0200 +++ b/sound/usb/card.c 2011-09-26 15:00:30.313110086 +0200 @@ -530,9 +530,11 @@ snd_usb_audio_probe(struct usb_device *d return chip; __error: - if (chip && !chip->num_interfaces) - snd_card_free(chip->card); - chip->probing = 0; + if (chip) { + if (!chip->num_interfaces) + snd_card_free(chip->card); + chip->probing = 0; + } mutex_unlock(&register_mutex); __err_val: return NULL;

2 1

[alsa-devel] [PATCH resend 0/4] ASoC: omap-mcpdm/twl6040: Offset cancellation
by Peter Ujfalusi 26 Sep '11

26 Sep '11

Hello, The following series adds support for the McPDM offset cancellation feature. It provides the needed functionality to: - read the HSTRIM values from the twl6040 codec - configure the offset cancellation registers in OMAP-McPDM Rebased batches on top of: git://opensource.wolfsonmicro.com/linux-2.6-asoc, for-3.2 branch No other changes. Mark: I have not added you acks to the patches, since you will be signing them off anyways. Regards, Peter --- Peter Ujfalusi (4): ASoC: twl6040: Read the TRIM values from the chip ASoC: twl6040: Function to fetch the TRIM values ASoC: omap-mcpdm: API to configure offset cancellation ASoC: sdp4430: Configure McPDM offset cancellation sound/soc/codecs/twl6040.c | 16 ++++++++++++++++ sound/soc/codecs/twl6040.h | 13 +++++++++++++ sound/soc/omap/omap-mcpdm.c | 25 +++++++++++++++++++++++++ sound/soc/omap/omap-mcpdm.h | 12 ++++++++++++ sound/soc/omap/sdp4430.c | 10 +++++++++- 5 files changed, 75 insertions(+), 1 deletions(-) -- 1.7.6.1

1 4

[alsa-devel] [PATCH 0/4] ASoC: omap-mcpdm/twl6040: Offset cancellation
by Peter Ujfalusi 26 Sep '11

26 Sep '11

Hello, The following series adds support for the McPDM offset cancellation feature. It provides the needed functionality to: - read the HSTRIM values from the twl6040 codec - configure the offset cancellation registers in OMAP-McPDM Regards, Peter --- Peter Ujfalusi (4): ASoC: twl6040: Read the TRIM values from the chip ASoC: twl6040: Function to fetch the TRIM values ASoC: omap-mcpdm: API to configure offset cancellation ASoC: sdp4430: Configure McPDM offset cancellation sound/soc/codecs/twl6040.c | 16 ++++++++++++++++ sound/soc/codecs/twl6040.h | 13 +++++++++++++ sound/soc/omap/omap-mcpdm.c | 25 +++++++++++++++++++++++++ sound/soc/omap/omap-mcpdm.h | 12 ++++++++++++ sound/soc/omap/sdp4430.c | 10 +++++++++- 5 files changed, 75 insertions(+), 1 deletions(-) -- 1.7.6.1

2 9

[alsa-devel] ASoC updates for 3.1
by Mark Brown 26 Sep '11

26 Sep '11

The following changes since commit 5013951be88e136d9990ef55303276e2779ce8d8: ASoC: Fix trivial build regression in Kirkwood I2S (2011-09-12 11:48:12 +0100) are available in the git repository at: git://opensource.wolfsonmicro.com/linux-2.6-asoc.git for-3.1 A couple of driver fixes and the driver name issue we discussed. Axel Lin (1): ASoC: bf5xx-ad73311: Fix prototype for bf5xx_probe Mark Brown (2): ASoC: Remove bitrotted wm8962_resume() ASoC: Ensure we generate a driver name sound/soc/blackfin/bf5xx-ad73311.c | 2 +- sound/soc/codecs/wm8962.c | 26 -------------------------- sound/soc/soc-core.c | 18 +++++++++++++++--- 3 files changed, 16 insertions(+), 30 deletions(-)

3 3

Re: [alsa-devel] link between HDMI ELD and PCM devices
by David Henningsson 26 Sep '11

26 Sep '11

On 09/21/2011 03:20 PM, Pierre-Louis Bossart wrote: >> This won't work - in the case of several HDMI codecs (common with >> NVidia) there will be more than one "HDMI 0". > > No, the code doesn't use a constant, It's actually four constants, please see generic_hdmi_pcm_names in patch_hdmi.c. But my point is that this restarts from 0 on every codec. > it's assigned in the same way as the > device name. You would have HDMI 0, HDMI 1..4. I don't have this kind of > hardware, it'd be good if someone could verify that the name is indeed > dynamic. On a 3.0 based kernel, here's part of my aplay -l output: card 3: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 7: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 8: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 9: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 >> The solution is to actually find the device number out, like this: >> >> struct hdmi_spec *spec = codec->spec; >> int pcmdev = spec->pcm_rec[pin_idx].device; > > That's what I wanted initially, but this device field is not > used/initialized, and like I said the device assignment comes after the pin > sensing and all the ELD handling A good place to do this is generic_hdmi_build_controls, both because it is normally used to add controls (which is what you do), and because it is triggered after the pcm device is assigned. (A side note to Takashi: for some reason hda-emu has the calls to build_controls and build_pcms switched, compared to the real implementation.) -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

4 6