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

[alsa-devel] [PATCH] ALSA: usb-audio: Add TASCAM US122 MKII playback
by Oto Petřík 24 Nov '12

24 Nov '12

Added quirk to provide at least playback-only support. Signed-off-by: Oto Petrik <oto.petrik(a)gmail.com> --- sound/usb/quirks-table.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 79780fa..eb03541 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2780,6 +2780,52 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, +{ + /* Tascam US122 MKII - playback-only support */ + .match_flags = USB_DEVICE_ID_MATCH_DEVICE, + .idVendor = 0x0644, + .idProduct = 0x8021, + .bInterfaceClass = USB_CLASS_AUDIO, + .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { + .vendor_name = "TASCAM", + .product_name = "US122 MKII", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_FIXED_ENDPOINT, + .data = &(const struct audioformat) { + .formats = SNDRV_PCM_FMTBIT_S24_3LE, + .channels = 2, + .iface = 1, + .altsetting = 1, + .altset_idx = 1, + .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, + .endpoint = 0x02, + .ep_attr = USB_ENDPOINT_XFER_ISOC, + .rates = SNDRV_PCM_RATE_44100 | + SNDRV_PCM_RATE_48000 | + SNDRV_PCM_RATE_88200 | + SNDRV_PCM_RATE_96000, + .rate_min = 44100, + .rate_max = 96000, + .nr_rates = 4, + .rate_table = (unsigned int[]) { + 44100, 48000, 88200, 96000 + } + } + }, + { + .ifnum = -1 + } + } + } +}, { /* -- 1.7.10.4

3 2

[alsa-devel] Can't connect to MIDI output of Edirol UA-1000
by Colin Fletcher 15 Nov '12

15 Nov '12

Hello all, I hope this is the right place to report this and ask for help: if not, I'd be glad of a pointers to any more appropriate forum. I've just recently noticed that connections to the MIDI output of my Edirol UA-1000 fail when using the snd_ua101 driver in recent kernels. Although the port is listed, connections to it fail from all the software I've tried: qjackctl, a2jmidid and aconnect all fail to connect. aconnect simply reports "Connection failed (Input/output error)"; a2jmidid -e says "ERROR: a2j_port_create: snd_seq_connect_to() for 20:0 failed with error -5"; and qjackctl reports no error but refuses to make the connection. I've observed the problem in stable kernels 3.0.39 and 3.4.11; it works as expected when booted into a 2.6.32 kernel, where the snd_usb_audio driver is used for the UA-1000. Other USB MIDI devices appear to work fine with the newer kernels. Incidentally, I also noticed that the 'Control' MIDI in & out of the UA-1000 no longer appear when using snd_ua101, but I don't think this is related, since changing the values of midi_ep.out_cables and midi_ep.in_cables to 3 in the ua101_probe() function in sound/usb/misc/ua101.c brings the control in & out back, but I'm still unable to connect the outputs. Any help, suggestions, patches or requests for more details gratefully received! Thank you, Colin Fletcher.

3 7

Re: [alsa-devel] Help requested: new HSS1394 MIDI back-end
by Clemens Ladisch 12 Nov '12

12 Nov '12

Sean M. Pappalardo - D.J. Pegasus wrote: > On 05/30/2012 06:51 AM, Clemens Ladisch wrote: >> Sean M. Pappalardo - D.J. Pegasus wrote: >>> four-byte platter messages that start with >>> 0xF9 and the remaining three can range from 0x00 to 0xFF. >> >> This is not MIDI. Into what MIDI messages should >> the driver convert this? > > It shouldn't convert it at all. Just deliver it as-is in a single > four-byte message, if possible. The problem is the communication between the driver and userspace; _that_ must be valid MIDI. > 0xF9 is a valid, if undefined, MIDI status. Undefined means invalid. Furthermore, data bytes must not have the eighth bit set. > I will also need the ability to use the HSS1394 SendUserControl > function to set the device's timers, and that is definitely not MIDI > at all. > I wonder if it would be a good idea to define a special SYSEX message > that the SCS1x driver would interpret and convert to a call to that > function? As it happens, the actual SysEx commands use the wrong manufacturer ID ("00 01 02" is Crystal Semiconductor); I could just use the real ID (Stanton is "00 01 60") to escape non-MIDI HSS1394 messages. Let's add "HSS" to identify this, and to allow the full byte range, each HSS1394 byte is split into two nibbles. So: 00 F9 xx yy zz -> F0 00 01 60 48 53 53 00 00 0F 09 0x 0x 0y 0y 0z 0z F7 13 xx yy zz <- F0 00 01 60 48 53 53 01 03 0x 0x 0y 0y 0z 0z F7 14 xx yy zz <- F0 00 01 60 48 53 53 01 04 0x 0x 0y 0y 0z 0z F7 (0x13 = 0x10 + 3 = kUserTagBase + uUserTag) Regards, Clemens

3 21

[alsa-devel] Linux Kernel-3.5 crashed as dapm is not supported by codec
by Rajeev kumar 09 Nov '12

09 Nov '12

Hello Peter I am working on Linux Kernel-3.5. I have not provided the dapm support in codec. When the system goes in hibernation state it gets crashed. command for putting the system in hibernation: echo disk > /sys/power/state Please find below the crash log Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = bd470000 [00000008] *pgd=3d43b831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 1 Not tainted (3.5.0-lsp-3.3.0-rc1 #5) PC is at snd_soc_dapm_shutdown+0x48/0x11c LR is at snd_soc_poweroff+0x68/0x70 pc : [<80372438>] lr : [<8036ccf4>] psr: 00000013 sp : bd5bbd98 ip : bd5bbdc8 fp : bd5bbdc4 r10: 806a6048 r9 : 8044e200 r8 : bd5bbd98 r7 : 807260c4 r6 : bebceec8 r5 : ffffffec r4 : bebcee08 r3 : 00000000 r2 : bebcec10 r1 : 00000000 r0 : 807260c4 Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 3d47004a DAC: 00000015 Process disk.sh (pid: 1932, stack limit = 0xbd5ba2f0) Stack: (0xbd5bbd98 to 0xbd5bc000) bd80: bd5bbd98 bd5bbd98 bda0: bd5bbdc4 807260c4 000016b0 00000004 00000000 8024397c bd5bbde4 bd5bbdc8 bdc0: 8036ccf4 803723fc 8036cc8c be9b2808 be9b2808 00000000 bd5bbdf4 bd5bbde8 bde0: 802439bc 8036cc98 bd5bbe2c bd5bbdf8 80247a28 80243988 80435b80 8008fc18 be00: 00000000 00000000 bd5bbe2c be9b2808 00000004 be9b283c 8072359c 00000004 be20: bd5bbe54 bd5bbe30 80248564 802479f8 806a5c98 009b2880 be9b2880 00000000 be40: 806a6008 be9b2808 bd5bbe8c bd5bbe58 80248dac 80248450 3a87fb94 00000023 be60: 3a87fb94 00000023 00000004 806f6e58 00000004 00000005 be863e00 bd4a2918 be80: bd5bbea4 bd5bbe90 80249144 80248cfc 00000001 00000000 bd5bbebc bd5bbea8 bea0: 800590a8 802490e4 00000000 806953ac bd5bbed4 bd5bbec0 800592dc 8005906c bec0: bde8b000 be863f00 bd5bbefc bd5bbed8 80057444 80059194 00000005 be863f00 bee0: bd4a2900 bd5bbf70 be863e00 bd4a2918 bd5bbf0c bd5bbf00 801e5e18 80057394 bf00: bd5bbf3c bd5bbf10 80124f18 801e5e08 bd5bbf70 00000005 bdcd9300 76fc6000 bf20: bd5bbf70 00000000 00000000 00000000 bd5bbf6c bd5bbf40 800cf8b0 80124e0c bf40: 00000000 bde7b500 00000003 bdcd9300 76fc6000 00000005 00000004 00000000 bf60: bd5bbfa4 bd5bbf70 800cfb2c 800cf7f8 00000000 00000000 00000005 00000000 bf80: 00000004 76f87628 00000005 76fc6000 8000e088 bd5ba000 00000000 bd5bbfa8 bfa0: 8000dde0 800cfaec 76f87628 00000005 00000001 76fc6000 00000005 00000000 bfc0: 76f87628 00000005 76fc6000 00000004 00000005 76fc74c0 000b0094 0005dae8 bfe0: 00000005 7e8df7c8 76ed713c 76f1fafc 60000010 00000001 3fffe821 3fffec21 [<80372438>] (snd_soc_dapm_shutdown+0x48/0x11c) from [<8036ccf4>] (snd_soc_poweroff+0x68/0x70) [<8036ccf4>] (snd_soc_poweroff+0x68/0x70) from [<802439bc>] (platform_pm_poweroff+0x40/0x58) [<802439bc>] (platform_pm_poweroff+0x40/0x58) from [<80247a28>] (dpm_run_callback.isra.12+0x3c/0x74) [<80247a28>] (dpm_run_callback.isra.12+0x3c/0x74) from [<80248564>] (__device_suspend+0x120/0x194) [<80248564>] (__device_suspend+0x120/0x194) from [<80248dac>] (dpm_suspend+0xbc/0x224) [<80248dac>] (dpm_suspend+0xbc/0x224) from [<80249144>] (dpm_suspend_start+0x6c/0x74) [<80249144>] (dpm_suspend_start+0x6c/0x74) from [<800590a8>] (hibernation_platform_enter+0x48/0x128) [<800590a8>] (hibernation_platform_enter+0x48/0x128) from [<800592dc>] (hibernate+0x154/0x21c) [<800592dc>] (hibernate+0x154/0x21c) from [<80057444>] (state_store+0xbc/0xd0) [<80057444>] (state_store+0xbc/0xd0) from [<801e5e18>] (kobj_attr_store+0x1c/0x28) [<801e5e18>] (kobj_attr_store+0x1c/0x28) from [<80124f18>] (sysfs_write_file+0x118/0x14c) [<80124f18>] (sysfs_write_file+0x118/0x14c) from [<800cf8b0>] (vfs_write+0xc4/0x140) [<800cf8b0>] (vfs_write+0xc4/0x140) from [<800cfb2c>] (sys_write+0x4c/0x78) [<800cfb2c>] (sys_write+0x4c/0x78) from [<8000dde0>] (ret_fast_syscall+0x0/0x48) Code: e59350f8 e3a03000 e2455014 ea00000f (e595201c) Best Regards Rajeev

4 12

[alsa-devel] Status of Zoom R16
by Evan Ta 08 Nov '12

08 Nov '12

Hi, as subj says: can you tell me how the Zoom R16 is doing? The hardware looks nice, but the latest info I can find is a seemingly unresolved failure to work with Alsa as of feb 2010. Thanks, Evan

4 6

[alsa-devel] [PATCH - ALSA: snd-virtuoso 1/1] Xonar DSX support
by sgiurgiu11＠gmail.com 29 Oct '12

29 Oct '12

From: Sergiu Giurgiu <sgiurgiu11(a)gmail.com> Signed-off-by: Sergiu Giurgiu <sgiurgiu11(a)gmail.com> diff --git a/mirror/sound/pci/oxygen/virtuoso.c b/mirror/sound/pci/oxygen/virtuoso.c index 3d71423..8104eab 100644 --- a/mirror/sound/pci/oxygen/virtuoso.c +++ b/mirror/sound/pci/oxygen/virtuoso.c @@ -52,6 +52,7 @@ static DEFINE_PCI_DEVICE_TABLE(xonar_ids) = { { OXYGEN_PCI_SUBID(0x1043, 0x835d) }, { OXYGEN_PCI_SUBID(0x1043, 0x835e) }, { OXYGEN_PCI_SUBID(0x1043, 0x838e) }, + { OXYGEN_PCI_SUBID(0x1043, 0x8522) }, { OXYGEN_PCI_SUBID_BROKEN_EEPROM }, { } }; diff --git a/mirror/sound/pci/oxygen/xonar_wm87x6.c b/mirror/sound/pci/oxygen/xonar_wm87x6.c index 63cff90..af91016 100644 --- a/mirror/sound/pci/oxygen/xonar_wm87x6.c +++ b/mirror/sound/pci/oxygen/xonar_wm87x6.c @@ -1321,6 +1321,40 @@ static const struct oxygen_model model_xonar_hdav_slim = { .adc_i2s_format = OXYGEN_I2S_FORMAT_LJUST, }; +static const struct oxygen_model model_xonar_dsx = { + .shortname = "Xonar DSX", + .longname = "Asus Virtuoso 66", + .chip = "AV200", + .init = xonar_ds_init, + .mixer_init = xonar_ds_mixer_init, + .cleanup = xonar_ds_cleanup, + .suspend = xonar_ds_suspend, + .resume = xonar_ds_resume, + .pcm_hardware_filter = wm8776_adc_hardware_filter, + .set_dac_params = set_wm87x6_dac_params, + .set_adc_params = set_wm8776_adc_params, + .update_dac_volume = update_wm87x6_volume, + .update_dac_mute = update_wm87x6_mute, + .update_center_lfe_mix = update_wm8766_center_lfe_mix, + .gpio_changed = xonar_ds_gpio_changed, + .dump_registers = dump_wm87x6_registers, + .dac_tlv = wm87x6_dac_db_scale, + .model_data_size = sizeof(struct xonar_wm87x6), + .device_config = PLAYBACK_0_TO_I2S | + PLAYBACK_1_TO_SPDIF | + CAPTURE_0_FROM_I2S_1 | + CAPTURE_1_FROM_SPDIF, + .dac_channels_pcm = 8, + .dac_channels_mixer = 8, + .dac_volume_min = 255 - 2*60, + .dac_volume_max = 255, + .function_flags = OXYGEN_FUNCTION_SPI, + .dac_mclks = OXYGEN_MCLKS(256, 256, 128), + .adc_mclks = OXYGEN_MCLKS(256, 256, 128), + .dac_i2s_format = OXYGEN_I2S_FORMAT_LJUST, + .adc_i2s_format = OXYGEN_I2S_FORMAT_LJUST, +}; + int __devinit get_xonar_wm87x6_model(struct oxygen *chip, const struct pci_device_id *id) { @@ -1331,6 +1365,9 @@ int __devinit get_xonar_wm87x6_model(struct oxygen *chip, case 0x835e: chip->model = model_xonar_hdav_slim; break; + case 0x8522: + chip->model = model_xonar_dsx; + break; default: return -EINVAL; } -- 1.7.10.4

5 4

[alsa-devel] HDSPM - Problems with SyncIn
by Andre Schramm 19 Oct '12

19 Oct '12

Hello, I did some tests with the SyncIn-Feature of the HDSPe cards. [root@localhost ~]# lspci |grep Mult 01:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) 02:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) The SyncOut of card 2:00 was plugged to the SyncIn of 1:00 and 1:00 was put to AutoSync-mode automatically upon boot. Problem is that the amixer output seems to be inconsistent and differs from the proc output as well, so I'm not sure which one to trust. [root@localhost ~]# amixer -c0 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=3 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=2 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=1 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=47999 'Preferred Sync Reference' is SyncIn, 'SYNC IN SyncCheck' says 'No Lock', meaning no signal at all, but the 'System Sample Rate' coming from the master card is detected with 1Hz offset. When putting the master to 32000Hz, 31999Hz are shown and so on. [root@localhost ~]# cat /proc/asound/card0/hdspm RME MADI (Card #1) Rev.d2 Status2first3bits: 1 HW Serial: 0x0000019196d4 IRQ: 16 Registers bus: 0xfe9f0000 VM: 0xf8920000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10344ca, ctrl2=0x0, status1=0xc30004, status2=0xc0020361 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: AutoSync Preferred Sync Reference: TCO System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Sync In, Freq=0 (MADI = 3, Word = 3) Input: Coax, Mode=56 channels Now the proc-output reports 'No TCO module detected', which is correct, as no expansion modules where plugged to the cards. But it also says 'Preferred Sync Reference: TCO' and 'Freq=0', where amixer said SyncIn and 47999? Output of the master card is below. Regards, Andre [root@localhost ~]# amixer -c1 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=4 numid=15,iface=MIXER,name='Input Select' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'optical' ; Item #1 'coaxial' : values=0 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=0 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=0 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=48000 [root@localhost ~]# cat /proc/asound/card1/hdspm RME MADI (Card #2) Rev.d2 Status2first3bits: 1 HW Serial: 0x000001b1c606 IRQ: 17 Registers bus: 0xfeaf0000 VM: 0xf9280000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10004da, ctrl2=0x0, status1=0x2800000, status2=0xc0020701 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: Master Preferred Sync Reference: Word Clock System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Input not valid, Freq=0 (MADI = 10, Word = 0) Input: Optical, Mode=56 channels

2 2

[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] [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] [PATCH 2.6.39-rc3] hda_intel: ALSA HD Audio patch for Intel Panther Point DeviceIDs
by Takashi Iwai 09 Oct '12

09 Oct '12

At Wed, 20 Apr 2011 10:59:57 -0700, Seth Heasley wrote: > > This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. > > Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> Applied now. Thanks. Takashi > --- > --- linux-2.6.39-rc3/sound/pci/hda/hda_intel.c.orig 2011-04-11 17:21:51.000000000 -0700 > +++ linux-2.6.39-rc3/sound/pci/hda/hda_intel.c 2011-04-14 11:44:40.000000000 -0700 > @@ -126,6 +126,7 @@ > "{Intel, ICH10}," > "{Intel, PCH}," > "{Intel, CPT}," > + "{Intel, PPT}," > "{Intel, PBG}," > "{Intel, SCH}," > "{ATI, SB450}," > @@ -2759,6 +2760,8 @@ > { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH }, > /* PBG */ > { PCI_DEVICE(0x8086, 0x1d20), .driver_data = AZX_DRIVER_PCH }, > + /* Panther Point */ > + { PCI_DEVICE(0x8086, 0x1e20), .driver_data = AZX_DRIVER_PCH }, > /* SCH */ > { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH }, > /* Generic Intel */ >

3 2