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

Re: [alsa-devel] sound/pci/hda/hda_codec.c:1435:46: error: 'AC_VERB_GET_CON' undeclared
by Takashi Iwai 15 Oct '12

15 Oct '12

At Sat, 13 Oct 2012 01:01:09 +0800, Fengguang Wu wrote: > > Hi Takashi, > > FYI, kernel build failed on > > commit: 645cf3b5656e47fa9a46e2fbc8d212ab572ab05b Merge branch 'topic/3.8' > config: x86_64-allyesdebian (attached as .config) > > > All error/warnings: > > sound/pci/hda/hda_codec.c: In function 'update_pcm_stream_id': > sound/pci/hda/hda_codec.c:1435:46: error: 'AC_VERB_GET_CON' undeclared (first use in this function) > sound/pci/hda/hda_codec.c:1435:46: note: each undeclared identifier is reported only once for each function it appears in Thanks, this must be already fixed. It was a temporary merge error. (One shouldn't work during updating the system....) Takashi

3 4

[alsa-devel] Support for Roland VG-99
by Pete Leigh 14 Oct '12

14 Oct '12

Hi, The VG-99 is a guitar processor with a usb interface which offers 2x16bit 44100 pcm in and out streams in its basic usb mode, and 2x24bit 44100 in/out + midi in the advanced mode connection mode. Basic mode works fine with usb snd driver, but the device isn't recognised when set to advanced mode (this is done under USB on page 2 of the "system" config menu) I've used the lsusb -v output (below) to guess at an addition to sound/usb/quirks-table.h to try and get this working. On initial (brief) testing, audio in/out at 24bits (as shown by jackd output) and midi (out, at least) are all working. I'll attach the quirk, and would be pleased if someone could look at it, and the lsusb output, and fix up any deficiencies (it's purely voodoo here :-D) and maybe get it or something like it into the official source... please let me know if changes need to be tested. Cheers, - Pete. Here's the lsusb output: Bus 001 Device 007: ID 0582:00b2 Roland Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 8 idVendor 0x0582 Roland Corp. idProduct 0x00b2 bcdDevice 1.00 iManufacturer 1 Roland iProduct 2 VG-99 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 167 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 02 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Device Status: 0x0001 Self Powered

1 0

[alsa-devel] snd-usb-audio probe problem (Teac UD-H01)
by bEN 13 Oct '12

13 Oct '12

Hi all, the new USB DAC from Teac seems detected as 'Human Interface Device' instead of 'Audio'. Despite the fact it is based on a standard USB Audio class v2 controller (Tenor 8802). Below is dmesg and lsusb outputs. Does it need to apply a patch in /sound/usb/quirks-table.h ? If yes, someone could help me to write this patch, please? Your help would be very much appreciated, Thanks in advance. bEN (from Ubuntu 11.04 with Linux 2.6.38-13-generic + Alsa driver 1.0.23) $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.23. $ dmesg (...) [34035.000078] usb 2-4: new high speed USB device using ehci_hcd and address 3 [34035.151753] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151763] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151770] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151777] usb 2-4: config 1 has no interface number 1 [34035.155108] input: TEAC TEAC USB AUDIO DEVICE as /devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/input/input13 [34035.155328] generic-usb 0003:0644:8038.0002: input,hidraw1: USB HID v1.00 Device [TEAC TEAC USB AUDIO DEVICE] on usb-0000:00:1d.7-4/input0 [34035.202368] Audio class v2 interfaces need an interface association [34035.202387] snd-usb-audio: probe of 2-4:1.2 failed with error -5 [34035.202426] usbcore: registered new interface driver snd-usb-audio $ lsusb -v --> see attachment.

5 6

[alsa-devel] bit depth issue for Scarlett 2i4
by Dan MacDonald 13 Oct '12

13 Oct '12

Hi ALSA devs! I recently bought a Focusrite Scarlett 2i4 which is advertised as being capable of recording at a max of 24bit/96Khz but when I run alsacap it reports it as 32bit: ./alsacap -R -d hw:1 *** Exploring configuration space of device `hw:1' for recording *** 2 channels Sampling rate 44100..96000 Hz Sample formats: S32_LE Significant bits: 32 It does seem to record OK but that output seems wrong and I'm slightly concerned about the waste of disk space when multitracking if I end up with 32bit files but only 24 of those bits per sample are actually being used. Thanks for your help! Dan

2 1

[alsa-devel] Question about rawmidi USB Tx buffer size
by Paul D. DeRocco 12 Oct '12

12 Oct '12

Simple question: how big is it? ALSA provides snd_rawmidi_status for reading the status structure from a rawmidi handle, and snd_rawmidi_status_get_avail to extract the number of bytes in the ring buffer from that structure, but what I want to know is how many bytes of space are available in the ring buffer, so that I know how many bytes I can write without blocking. Is the buffer size a fixed number for any particular driver? The only driver I'm concerned with is the USB MIDI driver, so that shouldn't be hardware dependent. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com

1 0

[alsa-devel] [PATCH 0/2] dmaengine: Fix compillation issues in device_prep_dma_cyclic()
by Peter Ujfalusi 12 Oct '12

12 Oct '12

Hello, The reason for the breakage is the patch 1 got lost somewhere in the process. I also greped the whole tree for device_prep_dma_cyclic() and the second patch is the result of that. PS: I did build tested the series on ARM (OMAP), x86_32, x86_64 but not for ppc for sure. Regards, Peter --- Peter Ujfalusi (2): dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic() ARM: SAMSUNG: dma-ops: Fix dmaengine_prep_dma_cyclic() parameter list arch/arm/plat-samsung/dma-ops.c | 3 ++- include/linux/dmaengine.h | 3 ++- sound/soc/soc-dmaengine-pcm.c | 6 +++++- 3 files changed, 9 insertions(+), 3 deletions(-) -- 1.7.12

5 7

Re: [alsa-devel] [3.6-rc7] switcheroo race with Intel HDA...
by Takashi Iwai 12 Oct '12

12 Oct '12

At Fri, 12 Oct 2012 23:08:14 +0800, Daniel J Blueman wrote: > > On 10 October 2012 20:34, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Tue, 9 Oct 2012 22:26:40 +0800, > > Daniel J Blueman wrote: > >> On 9 October 2012 21:04, Takashi Iwai <tiwai(a)suse.de> wrote: > >> > At Tue, 9 Oct 2012 19:23:56 +0800, > >> > Daniel J Blueman wrote: > >> >> On 9 October 2012 18:07, Takashi Iwai <tiwai(a)suse.de> wrote: > >> >> > At Tue, 09 Oct 2012 12:04:08 +0200, > >> >> > Takashi Iwai wrote: > >> >> >> At Tue, 9 Oct 2012 00:34:09 +0800, > >> >> >> Daniel J Blueman wrote: > >> >> >> > On 8 October 2012 20:58, Takashi Iwai <tiwai(a)suse.de> wrote: > >> >> >> > > At Tue, 25 Sep 2012 13:20:05 +0800, > >> >> >> > > Daniel J Blueman wrote: > >> >> >> > >> On my Macbook with a discrete Nvidia GPU, there is a race between > >> >> >> > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], > >> >> >> > >> reliably causing a kernel oops [2]. > >> >> >> > >> > >> >> >> > >> Introducing a delay of ~1s between the calls prevents this. When the > >> >> >> > >> second 'OFF' write path executes, it looks like struct azx at > >> >> >> > >> card->private_data hasn't yet been allocated yet [3], so there is > >> >> >> > >> likely some locking missing. > >> >> >> > > > >> >> >> > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus > >> >> >> > > card->private_data causes Oops). Could you check the patch like below > >> >> >> > > and see whether you get a kernel warning (but no Oops) or the problem > >> >> >> > > gets fixed by shifting the assignment of pci drvdata? > >> >> >> > [...] > >> >> >> > > >> >> >> > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, > >> >> >> > though we see unexpected 0x0 responses in the response ring buffer > >> >> >> > [1], which we don't see when there's a >~1.5s delay between IGD and > >> >> >> > OFF. > >> >> >> > >> >> >> If the previous patch fixed, it means that the switching occurred > >> >> >> during the device was being probed. Maybe a better approach to > >> >> >> register the VGA switcheroo after the proper initialization. > >> >> >> > >> >> >> The patch below is a revised one. Please give it a try. > >> >> > > >> >> > Also, it's not clear which card spews the spurious response. > >> >> > Apply the patch below in addition. > >> >> [...] > >> >> > >> >> hda-intel: 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x1f0004 > >> >> $ lspci -s :1:0.1 > >> >> 01:00.1 Audio device: NVIDIA Corporation Device 0e1b (rev ff) > >> >> > >> >> It's the NVIDIA device which presumably hasn't completed it's > >> >> transition to D3 at the time the OFF is executed. > >> > > >> > OK, then could you try the patch below on the top of previous two > >> > patches? > >> > >> The first IGD switcheroo command fails to switch to the integrated GPU: > >> > >> # cat /sys/kernel/debug/vgaswitcheroo/switch > >> 0:DIS:+:Pwr:0000:01:00.0 > >> 1:IGD: :Pwr:0000:00:02.0 > >> 2:DIS-Audio: :Pwr:0000:01:00.1 > >> # echo IGD >/sys/kernel/debug/vgaswitcheroo/switch > >> vga_switcheroo: client 1 refused switch > >> > >> I also instrumented snd_hda_lock_devices, but none of the failure > >> paths are being taken, which would leave inconsistent state, as the > >> return value isn't checked. > > > > Hm, right, the return value of snd_hda_lock_devices() isn't checked, > > but I don't understand how this results like above. > > Basically switching is protected by mutex in vga_switcheroo.c, so the > > whole operation in the client side should be serialized. > > > > In anyway, try the patch below cleanly, and see the spurious message > > error coming up at which timing. > [...] > > The patch _does_ address the issue. A recent update to my Macbook > firmware misleadingly broke i915 switching, but since I can reproduce > the oops without the IGD switching completing with the stock kernel, > and consistently can't without [1], the patch is good. > > Tested-by: Daniel J Blueman <daniel(a)quora.org> OK, then I'm going to apply the patch to 3.7 tree (with Cc to stable). thanks, Takashi > > Thanks Takashi! > Daniel > > --- [1] > > snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002) > snd_hda_intel 0000:00:1b.0: irq 54 for MSI/MSI-X > XXX 0000:00:1b.0: azx_codec_create entered > vga_switcheroo: enabled > XXX 0000:00:1b.0: azx_codec_create done > input: HDA Intel PCH Headphone as > /devices/pci0000:00/0000:00:1b.0/sound/card0/input9 > snd_hda_intel 0000:01:00.1: enabling device (0000 -> 0002) > hda_intel: Disabling MSI > hda-intel: 0000:01:00.1: Handle VGA-switcheroo audio client > XXX 0000:01:00.1: azx_codec_create entered > XXX 0000:01:00.1: azx_codec_create done > input: HDA NVidia HDMI/DP,pcm=8 as > /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input12 > input: HDA NVidia HDMI/DP,pcm=7 as > /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input13 > input: HDA NVidia HDMI/DP,pcm=3 as > /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input14 > vga_switcheroo: client 1 refused switch > i915: switched off > -- > Daniel J Blueman >

1 0

[alsa-devel] [PATCH 0/2] USB-audio disconnection race fixes
by Takashi Iwai 12 Oct '12

12 Oct '12

Hi, these two patches are for fixing races at disconnection of USB audio devices. The first patch tries to close the race at open/close, and the next is for other PCM and mixer ops in usb-audio driver. It seems working as far as I've tested with Matthieu's test cases. thanks, Takashi

1 2

[alsa-devel] [RFC PATCH] ALSA: hda - Implement a poll loop for jacks as a module parameter
by David Henningsson 12 Oct '12

12 Oct '12

Now that we have a generic unsol mechanism, we can implement a generic poll loop, which can be used for debugging, or if a codec's unsol mechanism is broken. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- I'm also considering activating it by default if we go into single_cmd mode due to codec not responding. What do you think? sound/pci/hda/hda_codec.c | 32 ++++++++++++++++++++++++++++---- sound/pci/hda/hda_codec.h | 2 ++ sound/pci/hda/hda_intel.c | 5 +++++ sound/pci/hda/hda_jack.c | 22 ++++++++++++++++++++++ sound/pci/hda/hda_jack.h | 2 ++ 5 files changed, 59 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index c0ab72c..626e45b 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -1135,6 +1135,19 @@ static void restore_shutup_pins(struct hda_codec *codec) } #endif +static void hda_jackpoll_work(struct work_struct *work) +{ + struct hda_codec *codec = + container_of(work, struct hda_codec, jackpoll_work.work); + if (!codec->jackpoll_interval) + return; + + snd_hda_jack_set_dirty_all(codec); + snd_hda_jack_poll_all(codec); + queue_delayed_work(codec->bus->workq, &codec->jackpoll_work, + codec->jackpoll_interval); +} + static void init_hda_cache(struct hda_cache_rec *cache, unsigned int record_size); static void free_hda_cache(struct hda_cache_rec *cache); @@ -1190,6 +1203,7 @@ static void snd_hda_codec_free(struct hda_codec *codec) { if (!codec) return; + cancel_delayed_work_sync(&codec->jackpoll_work); snd_hda_jack_tbl_clear(codec); restore_init_pincfgs(codec); #ifdef CONFIG_PM @@ -1273,6 +1287,7 @@ int /*__devinit*/ snd_hda_codec_new(struct hda_bus *bus, snd_array_init(&codec->cvt_setups, sizeof(struct hda_cvt_setup), 8); snd_array_init(&codec->conn_lists, sizeof(hda_nid_t), 64); snd_array_init(&codec->spdif_out, sizeof(struct hda_spdif_out), 16); + INIT_DELAYED_WORK(&codec->jackpoll_work, hda_jackpoll_work); #ifdef CONFIG_PM spin_lock_init(&codec->power_lock); @@ -2349,7 +2364,7 @@ int snd_hda_codec_reset(struct hda_codec *codec) return -EBUSY; /* OK, let it free */ - + cancel_delayed_work_sync(&codec->jackpoll_work); #ifdef CONFIG_PM cancel_delayed_work_sync(&codec->power_work); codec->power_on = 0; @@ -3646,7 +3661,6 @@ static void hda_call_codec_resume(struct hda_codec *codec) restore_pincfgs(codec); /* restore all current pin configs */ restore_shutup_pins(codec); hda_exec_init_verbs(codec); - snd_hda_jack_set_dirty_all(codec); if (codec->patch_ops.resume) codec->patch_ops.resume(codec); else { @@ -3655,7 +3669,13 @@ static void hda_call_codec_resume(struct hda_codec *codec) snd_hda_codec_resume_amp(codec); snd_hda_codec_resume_cache(codec); } - snd_hda_jack_report_sync(codec); + + if (codec->jackpoll_interval) + hda_jackpoll_work(&codec->jackpoll_work.work); + else { + snd_hda_jack_set_dirty_all(codec); + snd_hda_jack_report_sync(codec); + } snd_hda_power_down(codec); /* flag down before returning */ } #endif /* CONFIG_PM */ @@ -3737,7 +3757,10 @@ int snd_hda_codec_build_controls(struct hda_codec *codec) if (err < 0) return err; - snd_hda_jack_report_sync(codec); /* call at the last init point */ + if (codec->jackpoll_interval) + hda_jackpoll_work(&codec->jackpoll_work.work); + else + snd_hda_jack_report_sync(codec); /* call at the last init point */ return 0; } @@ -5128,6 +5151,7 @@ int snd_hda_suspend(struct hda_bus *bus) struct hda_codec *codec; list_for_each_entry(codec, &bus->codec_list, list) { + cancel_delayed_work_sync(&codec->jackpoll_work); if (hda_codec_is_power_on(codec)) hda_call_codec_suspend(codec, false); } diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 507fe8a..10a03b0 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -884,6 +884,8 @@ struct hda_codec { /* jack detection */ struct snd_array jacktbl; + unsigned long jackpoll_interval; /* In jiffies. Zero means no poll, rely on unsol events */ + struct delayed_work jackpoll_work; #ifdef CONFIG_SND_HDA_INPUT_JACK /* jack detection */ diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f09ff6c..b4f1ab8 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -68,6 +68,7 @@ static int position_fix[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] = -1}; static int bdl_pos_adj[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] = -1}; static int probe_mask[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] = -1}; static int probe_only[SNDRV_CARDS]; +static int jackpoll_ms[SNDRV_CARDS]; static bool single_cmd; static int enable_msi = -1; #ifdef CONFIG_SND_HDA_PATCH_LOADER @@ -95,6 +96,8 @@ module_param_array(probe_mask, int, NULL, 0444); MODULE_PARM_DESC(probe_mask, "Bitmask to probe codecs (default = -1)."); module_param_array(probe_only, int, NULL, 0444); MODULE_PARM_DESC(probe_only, "Only probing and no codec initialization."); +module_param_array(jackpoll_ms, int, NULL, 0444); +MODULE_PARM_DESC(jackpoll_ms, "Ms between polling for jack events (default = 0, using unsol events only)"); module_param(single_cmd, bool, 0444); MODULE_PARM_DESC(single_cmd, "Use single command to communicate with codecs " "(for debugging only)."); @@ -1666,6 +1669,8 @@ static int DELAYED_INIT_MARK azx_codec_create(struct azx *chip, const char *mode err = snd_hda_codec_new(chip->bus, c, &codec); if (err < 0) continue; + codec->jackpoll_interval = + msecs_to_jiffies(jackpoll_ms[chip->dev_index]); codec->beep_mode = chip->beep_mode; codecs++; } diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index 5c690cb..07d5288 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -439,3 +439,25 @@ void snd_hda_jack_unsol_event(struct hda_codec *codec, unsigned int res) } EXPORT_SYMBOL_HDA(snd_hda_jack_unsol_event); +void snd_hda_jack_poll_all(struct hda_codec *codec) +{ + struct hda_jack_tbl *jack = codec->jacktbl.list; + int i, changes = 0; + + for (i = 0; i < codec->jacktbl.used; i++, jack++) { + unsigned int old_sense; + if (!jack->nid || !jack->jack_dirty || jack->phantom_jack) + continue; + old_sense = get_jack_plug_state(jack->pin_sense); + jack_detect_update(codec, jack); + if (old_sense == get_jack_plug_state(jack->pin_sense)) + continue; + changes = 1; + if (jack->callback) + jack->callback(codec, jack); + } + if (changes) + snd_hda_jack_report_sync(codec); +} +EXPORT_SYMBOL_HDA(snd_hda_jack_poll_all); + diff --git a/sound/pci/hda/hda_jack.h b/sound/pci/hda/hda_jack.h index af8dd47..4487785 100644 --- a/sound/pci/hda/hda_jack.h +++ b/sound/pci/hda/hda_jack.h @@ -84,4 +84,6 @@ void snd_hda_jack_report_sync(struct hda_codec *codec); void snd_hda_jack_unsol_event(struct hda_codec *codec, unsigned int res); +void snd_hda_jack_poll_all(struct hda_codec *codec); + #endif /* __SOUND_HDA_JACK_H */ -- 1.7.9.5

2 9

Re: [alsa-devel] [PATCH 2.6.32.y, 2.6.34.y] ALSA: hda - ALSA HD Audio patch for Intel Panther Point DeviceIDs
by Ben Hutchings 12 Oct '12

12 Oct '12

On Tue, 2012-10-09 at 10:56 -0400, Paul Gortmaker wrote: > On 12-10-08 09:55 PM, Ben Hutchings wrote: > > On Mon, 2012-10-08 at 18:07 -0700, Jonathan Nieder wrote: > >> From: Seth Heasley <seth.heasley(a)intel.com> > >> Date: Wed, 20 Apr 2011 10:59:57 -0700 > >> > >> commit d2edeb7c6f1dada8ca7d5c23e42d604e92ae0c76 upstream. > >> > >> This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. > >> > >> [jn: backported for 2.6.32.y by Ana Guerrero] > >> > >> Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> > >> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > >> Tested-by: Ana Guerrero <ana(a)debian.org> # EliteBook 8570w > >> Signed-off-by: Jonathan Nieder <jrnieder(a)gmail.com> > >> --- > >> Hi Willy and Paul, > >> > >> Please consider > >> > >> d2edeb7c6f1d ALSA: hda - ALSA HD Audio patch for Intel Panther Point > >> DeviceIDs > >> > >> for application to the 2.6.32.y and 2.6.34.y trees. > >> > >> It does what it says on the cover. The patch was merged in the 3.0 > >> cycle, so newer stable kernels don't need it. Backported and > >> tested[1] against Debian's 2.6.32.y-based kernel by Ana (cc-ed) -- > >> thanks! > >> > >> Thoughts of all kinds welcome, as always. > > [...] > > > > I queued up a whole series of device ID updates for Debian stable, as > > they didn't obviously depend on other changes: > > > > cea310e ALSA: hda_intel: ALSA HD Audio patch for Intel Patsburg DeviceIDs > > e35d4b1 ALSA: hda: add Vortex86MX PCI ids > > 0f0714c ALSA: hda - Add support for VMware controller > > d2edeb7 ALSA: hda - ALSA HD Audio patch for Intel Panther Point DeviceIDs > > I found that d2edeb7c6f depends (only trivially, on context) on b686453543f, > which makes a blanket class for intel IDs so that "...the driver will work > with any new control chips in future." In that respect, I guess it too > (b68645) is in the same class as the other "add more IDs" patches? Yes, it seems like this would also be worth adding. (Always assuming that any functional changes it depends on are also small enough for stable.) It's not a clean cherry-pick as the line above has changed. Ben. > Paul. > -- > > > > > (They can be cherry-picked cleanly in the above order.) But if I've > > missed some post-2.6.32 dependencies then I would like to know. > > > > Ben. > > > -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'

1 0