February 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Crackly playback, Roland AIRA TR-8 USB audio almost works with ALSA . . .
by David W. 10 Feb '15

10 Feb '15

Dear ALSA developers, On 30/12/14 19:39, David W. wrote: > On 15/12/14 23:37, David W. wrote: >> On 07/07/14 07:31, Clemens Ladisch wrote: >>> >>> Apparently, this device needs some vendor-specific magic to enable >>> recording. >>> This AIRA TR-8 USB audio device, which fails with an 'input/output error' after ~10 seconds for 'aplay' and 'arecord', seems to require operation in implicit feedback mode: the following patch suggested by Daniel Mack solves the 'input/output' error for 'aplay', but the playback is noisy and corrupted and the kernel complains of 'rogue URB xfers' (see below). Given this information and the quote below from lsusb etc., I am hoping someone would be able to suggest a further patch to get playback and recording working :-) I can patch, compile and test recent linux kernels (whatever is in: https://www.archlinux.org/packages/?sort=&repo=Testing&q=linux) Here's the patch from Daniel which helped: diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 0d8aba5..e35575b 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -346,6 +346,15 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, alts = &iface->altsetting[1]; goto add_sync_ep; + case USB_ID(0x0582, 0x017c): + ep = 0x85; + iface = usb_ifnum_to_if(dev, 3); + + if (!iface || iface->num_altsetting == 0) + return -EINVAL; + + alts = &iface->altsetting[1]; + goto add_sync_ep; } if (attr == USB_ENDPOINT_SYNC_ASYNC && altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && Here's an example of the kind of complaint that the 3.18.2-2-ARCH kernel, with the above patch applied, reports: Jan 12 23:18:20 dwmobile kernel: WARNING: CPU: 2 PID: 1889 at drivers/usb/core/urb.c:450 usb_submit_urb+0x265/0x5f0 [usbcore]() Jan 12 23:18:20 dwmobile kernel: usb 2-1.1: BOGUS urb xfer, pipe 0 != type 1 Jan 12 23:18:20 dwmobile kernel: Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device ctr ccm sha256_ssse3 sha256_generic d Jan 12 23:18:20 dwmobile kernel: snd_pcm snd_timer video mei_me battery ac snd intel_agp button intel_gtt acpi_cpufreq shpchp mei soundcore proce Jan 12 23:18:20 dwmobile kernel: CPU: 2 PID: 1889 Comm: aplay Not tainted 3.18.2-2-custom #1 Jan 12 23:18:20 dwmobile kernel: Hardware name: System76, Inc. Pangolin Performance /W76x/M77xCUH Jan 12 23:18:20 dwmobile kernel: 0000000000000000 000000005911a000 ffff88022988faf8 ffffffff8154f134 Jan 12 23:18:20 dwmobile kernel: 0000000000000000 ffff88022988fb50 ffff88022988fb38 ffffffff81072bc1 Jan 12 23:18:20 dwmobile kernel: ffff88022988fb28 ffff88022f1aba00 0000000000000020 0000000000000003 Jan 12 23:18:20 dwmobile kernel: Call Trace: Jan 12 23:18:20 dwmobile kernel: [<ffffffff8154f134>] dump_stack+0x4e/0x71 Jan 12 23:18:20 dwmobile kernel: [<ffffffff81072bc1>] warn_slowpath_common+0x81/0xa0 Jan 12 23:18:20 dwmobile kernel: [<ffffffff81072c35>] warn_slowpath_fmt+0x55/0x70 Jan 12 23:18:20 dwmobile kernel: [<ffffffffa009b005>] ? usb_enable_endpoint+0x85/0x90 [usbcore] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa0098e75>] usb_submit_urb+0x265/0x5f0 [usbcore] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa08d2c65>] snd_usb_endpoint_start+0x125/0x350 [snd_usb_audio] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa08dac89>] start_endpoints+0xb9/0x1a0 [snd_usb_audio] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa08dcbad>] snd_usb_pcm_prepare+0x17d/0x560 [snd_usb_audio] Jan 12 23:18:20 dwmobile kernel: [<ffffffff810d7af6>] ? current_fs_time+0x16/0x60 Jan 12 23:18:20 dwmobile kernel: [<ffffffffa028627b>] snd_pcm_do_prepare+0x1b/0x30 [snd_pcm] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa0285e4f>] snd_pcm_action_single+0x2f/0x70 [snd_pcm] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa0285f06>] snd_pcm_action_nonatomic+0x76/0x80 [snd_pcm] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa0288c18>] snd_pcm_common_ioctl1+0x688/0xbc0 [snd_pcm] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa0289268>] snd_pcm_playback_ioctl1+0x118/0x280 [snd_pcm] Jan 12 23:18:20 dwmobile kernel: [<ffffffffa0289404>] snd_pcm_playback_ioctl+0x34/0x40 [snd_pcm] Jan 12 23:18:20 dwmobile kernel: [<ffffffff811e23e0>] do_vfs_ioctl+0x2d0/0x4b0 Jan 12 23:18:20 dwmobile kernel: [<ffffffff811cf2ac>] ? vfs_write+0x18c/0x200 Jan 12 23:18:20 dwmobile kernel: [<ffffffff811e2641>] SyS_ioctl+0x81/0xa0 Jan 12 23:18:20 dwmobile kernel: [<ffffffff81554ca9>] system_call_fastpath+0x12/0x17 Jan 12 23:18:20 dwmobile kernel: ---[ end trace e6531ceb4fd4f2e5 ]--- Jan 12 23:18:20 dwmobile kernel: ------------[ cut here ]------------ >> >> amidi -l >> >> Dir Device Name >> IO hw:0,0,0 USB X-Session MIDI 1 >> I hw:0,0,1 USB X-Session MIDI 2 >> IO hw:2,0,0 TR-8 MIDI 1 # this device >> IO hw:2,0,1 TR-8 MIDI 2 # this device >> >> >> ./alsacap -d hw:2,0 >> >> *** Exploring configuration space of device 'hw:1,0' for playback *** >> 4 channels >> Sampling rate 96000 Hz >> Sample formats: S32_LE >> Significant bits: 32 >> >> >> Bus 002 Device 005: ID 0582:017c Roland Corp. >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 2.00 >> bDeviceClass 255 Vendor Specific Class >> bDeviceSubClass 0 >> bDeviceProtocol 255 >> bMaxPacketSize0 64 >> idVendor 0x0582 Roland Corp. >> idProduct 0x017c >> bcdDevice 1.00 >> iManufacturer 1 Roland >> iProduct 2 TR-8 >> iSerial 0 >> bNumConfigurations 1 >> Configuration Descriptor: >> bLength 9 >> bDescriptorType 2 >> wTotalLength 176 >> bNumInterfaces 4 >> bConfigurationValue 1 >> iConfiguration 0 >> bmAttributes 0xc0 >> Self Powered >> MaxPower 0mA >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 0 >> bAlternateSetting 0 >> bNumEndpoints 0 >> bInterfaceClass 255 Vendor Specific Class >> bInterfaceSubClass 255 Vendor Specific Subclass >> bInterfaceProtocol 0 >> iInterface 0 >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 1 >> bAlternateSetting 0 >> bNumEndpoints 0 >> bInterfaceClass 255 Vendor Specific Class >> bInterfaceSubClass 2 >> bInterfaceProtocol 2 >> iInterface 0 >> # <06 24 F1 02 <inputs> <outputs>> from patch comment by Clemens Ladisch >> ** UNRECOGNIZED: 06 24 f1 01 00 00 >> # Audio OUT 4 channels? >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 1 >> bAlternateSetting 1 >> bNumEndpoints 1 >> bInterfaceClass 255 Vendor Specific Class >> bInterfaceSubClass 2 >> bInterfaceProtocol 2 >> iInterface 0 >> # seen in other Roland devices >> # http://ubuntuforums.org/archive/index.php/t-1905531.html >> ** UNRECOGNIZED: 07 24 01 01 00 01 00 >> ** UNRECOGNIZED: 0b 24 02 01 04 04 18 01 00 77 01 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x0d EP 13 OUT >> bmAttributes 5 >> Transfer Type Isochronous # audio >> Synch Type Asynchronous >> Usage Type Data >> # 4x 24-bit 96kHz == 56 bytes per 4 channels (or 32-bit?) >> wMaxPacketSize 0x00e0 1x 224 bytes >> bInterval 1 >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 2 >> bAlternateSetting 0 >> bNumEndpoints 0 >> bInterfaceClass 255 Vendor Specific Class >> bInterfaceSubClass 2 >> bInterfaceProtocol 1 >> iInterface 0 >> # Audio IN: 14 channels? >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 2 >> 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 0e 04 18 01 00 77 01 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x8e EP 14 IN >> bmAttributes 37 >> Transfer Type Isochronous >> Synch Type Asynchronous >> Usage Type Implicit feedback Data >> # 14 channels x 56 bytes per transfer 96kHz, 24-bit? >> wMaxPacketSize 0x0310 1x 784 bytes >> bInterval 1 >> # MIDI? >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 3 >> bAlternateSetting 0 >> bNumEndpoints 2 >> bInterfaceClass 255 Vendor Specific Class >> bInterfaceSubClass 3 >> bInterfaceProtocol 0 >> iInterface 0 >> # <06 24 F1 02 <inputs> <outputs>> 2 in 2 out >> ** 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 0x0200 1x 512 bytes >> bInterval 1 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x84 EP 4 IN >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0200 1x 512 bytes >> bInterval 0 >> # MIDI: same endpoints needs Bulk AND Interrupt packet types? >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 3 >> 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 3 >> Transfer Type Interrupt >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0200 1x 512 bytes >> bInterval 1 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x85 EP 5 IN >> bmAttributes 3 >> Transfer Type Interrupt >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0200 1x 512 bytes >> bInterval 1 >> Device Qualifier (for other device speed): >> bLength 10 >> bDescriptorType 6 >> bcdUSB 2.00 >> bDeviceClass 255 Vendor Specific Class >> bDeviceSubClass 0 >> bDeviceProtocol 255 >> bMaxPacketSize0 64 >> bNumConfigurations 1 >> can't get debug descriptor: Resource temporarily unavailable >> Device Status: 0x0001 >> Self Powered >> >> >> >> A summary of some USB packets during idle, start playback, stop >> playback, start recording, stop recording. Playback and record was >> probably only using a pair of stereo channels IIRC (maybe even one mono >> channel). I could do the same with all channels if that would be of any use. >> >> >> - at all times, polling seems to be 'Bulk or Interrupt Transfer' to >> Device Object FFFFFA800BBF1C00h (00000094) with I/O Request Packet >> FFFFFA800B97B830h >> >> >> - start playback: 'Select Interface', 'Ifc 1 / Alt 1' and 'Ifc 2 / Alt >> 1', Device Object: FFFFFA800BBF1C00h, I/O Request Packet: FFFFFA800778E780h >> >> 1x 'Create' using I/O Request Packet: FFFFFA800C7A2480h to Device >> Objects: FFFFFA800C060C20h (00000095) and FFFFFA800BE30600h (00000096) >> >> >> - during playback: lots of 'Isoch Transfer' to FFFFFA800BBF1C00h with >> nine different I/O Request Packets >> >> >> - stop playback: 'Select Interface', 'Ifc 1 / Alt 0' and 'Ifc 1 / Alt >> 0', Device Object: FFFFFA800BBF1C00h; I/O Request Packet: >> FFFFFA8007552810h >> >> 1x 'Close' using I/O Request Packet: FFFFFA800C7A2480h to Device >> Objects: FFFFFA800C060C20h and FFFFFA800BE30600h; some 'Cleanups' that >> return 'Invalid Device Request' >> >> >> - start recording: 'Select Interface', 'Ifc 1 / Alt 1' and 'Ifc 2 / Alt >> 1', Device Object: FFFFFA800BBF1C00h, I/O Request Packet: FFFFFA800778E780h >> >> 5x 'Create' using I/O Request Packet: FFFFFA800C0E9C60h to Device >> Objects: FFFFFA800C060C20h and FFFFFA800BE30600h >> 2x 'Create' using I/O Request Packet: FFFFFA800C60A010h to Device >> Objects: FFFFFA800C060C20h and FFFFFA800BE30600h >> 1x 'Create' using I/O Request Packet: FFFFFA800754F010h to Device >> Objects: FFFFFA800C060C20h and FFFFFA800BE30600h >> 2x 'Close' using I/O Request Packet: FFFFFA800C0E9C60h to Device >> Objects: FFFFFA800C060C20h and FFFFFA800BE30600h >> >> >> - during recording: lots of 'Isoch Transfer' to FFFFFA800BBF1C00h with >> nine different I/O Request Packets >> >> >> - stop recording: 'Select Interface', 'Ifc 1 / Alt 0' and 'Ifc 1 / Alt >> 0', Device Object: FFFFFA800BBF1C00h; I/O Request Packet: >> FFFFFA8007552810h >> >> 4x 'Close' using I/O Request Packet: FFFFFA8007543C60h to Device >> Objects: FFFFFA800C060C20h and FFFFFA800BE30600h >> >>

1 3

[alsa-devel] [RFC PATCH 0/3]
by Yakir Yang 10 Feb '15

10 Feb '15

RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz, and single-ended test would failed when display mode is 74.25MHz. - Fix some code style, leave space for next patches. - For hdmi eye-diagram test, we turn on the Transmitter Trailer-B and improve slopeboost to 25%-30% decrease. - For hdmi single-ended test, we set CKLVL & TXLVL to 17 when pixel clock is 74.25MHz, keep CKLVL & TXLVL to 13 when pixel clock is 148.5MHz. Yakir Yang (3): drm: bridge/dw_hdmi: fixed codec style drm: bridge/dw_hdmi_rockchip: improve hdmi eye-diagram test drm: bridge/dw_hdmi: improve hdmi single-end test drivers/gpu/drm/bridge/dw_hdmi.c | 20 ++++++++++---------- drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 ++++++------ drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++++++------- include/drm/bridge/dw_hdmi.h | 5 +++-- 4 files changed, 26 insertions(+), 25 deletions(-) -- 1.7.9.5

1 4

[alsa-devel] [RESEND PATCH 0/6] Add support for the WM8280 and WM8281
by Charles Keepax 10 Feb '15

10 Feb '15

This set of patches adds support for the WM8280 and WM8281 codecs to the Wolfson Arizona drivers. Just another resend on this series, if it would expedite the process I would be happy if we could just merge the MFD patches then I can push the other patches through their respective trees once that hits mainline, but at the moment all the patches are gated by a build dependency on the MFD patches. Thanks, Charles Richard Fitzgerald (6): mfd: arizona: Add support for WM8280/WM8281 Documentation: devicetree: arizona: Add bindings for WM8280 regulator: arizona-micsupp: Add support for WM8280/WM8281 gpio: arizona: Add support for WM8280/WM8281 extcon: arizona: Add support for WM8280/WM8281 ASoC: arizona: Add support for WM8280/WM8281 Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++++++++++---- drivers/extcon/extcon-arizona.c | 1 + drivers/gpio/gpio-arizona.c | 1 + drivers/mfd/Kconfig | 5 +++-- drivers/mfd/arizona-core.c | 15 +++++++++++++-- drivers/mfd/arizona-i2c.c | 2 ++ drivers/mfd/arizona-irq.c | 1 + drivers/mfd/arizona-spi.c | 2 ++ drivers/regulator/arizona-micsupp.c | 1 + include/linux/mfd/arizona/core.h | 1 + sound/soc/codecs/arizona.c | 2 ++ 11 files changed, 38 insertions(+), 8 deletions(-) -- 1.7.2.5

1 6

[alsa-devel] [PATCH] ALSA: hda - Add docking station support for another HP machine
by David Henningsson 10 Feb '15

10 Feb '15

From: TienFu Chen <tienfu.chen(a)canonical.com> BugLink: https://bugs.launchpad.net/bugs/1412800 Signed-off-by: TienFu Chen <tienfu.chen(a)canonical.com> Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0403061..ddb9308 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4950,6 +4950,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x226e, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1), SND_PCI_QUIRK(0x103c, 0x2271, "HP", ALC286_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x2272, "HP", ALC280_FIXUP_HP_DOCK_PINS), + SND_PCI_QUIRK(0x103c, 0x2273, "HP", ALC280_FIXUP_HP_DOCK_PINS), SND_PCI_QUIRK(0x103c, 0x229e, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1), SND_PCI_QUIRK(0x103c, 0x22b2, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1), SND_PCI_QUIRK(0x103c, 0x22b7, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1), -- 1.9.1

2 1

[alsa-devel] [PATCH v3] ASoC: atmel_ssc_dai: Allow more rates
by Peter Rosin 10 Feb '15

10 Feb '15

From: Peter Rosin <peda(a)axentia.se> When the SSC acts as BCK master, use a ratnum rule to limit the rate instead of only doing the standard rates. When the SSC acts as BCK slave, allow any BCK frequency up to the SSC master clock, divided by either of 2, 3 or 6. Put a cap at 384kHz. Who's /ever/ going to need more than that? The divider of 2, 3 or 6 is selected based on the Serial Clock Ratio Considerations section from the SSC documentation: The Transmitter and the Receiver can be programmed to operate with the clock signals provided on either the TK or RK pins. This allows the SSC to support many slave-mode data transfers. In this case, the maximum clock speed allowed on the RK pin is: - Peripheral clock divided by 2 if Receiver Frame Synchro is input - Peripheral clock divided by 3 if Receiver Frame Synchro is output In addition, the maximum clock speed allowed on the TK pin is: - Peripheral clock divided by 6 if Transmit Frame Synchro is input - Peripheral clock divided by 2 if Transmit Frame Synchro is output Signed-off-by: Peter Rosin <peda(a)axentia.se> --- sound/soc/atmel/atmel_ssc_dai.c | 111 +++++++++++++++++++++++++++++++++++++-- sound/soc/atmel/atmel_ssc_dai.h | 1 + 2 files changed, 108 insertions(+), 4 deletions(-) Changes since v2: - Killed the 500ppm reduction. Just trust the nominal clock rates of the given clocks. - Don't multiply the given SSC clk rate by two to get to the SSC master clock rate. That factor was the result of some confusion on my part. The SSC clk *is* the SSC master clock. Changes since v1: - I have checked all Atmel datasheets I could get my hands on (and that seemed relevant), and in every instance where they have described the SSC, the description have the exact rate limitations on the RK and TK pin that I have implemented here. - Improved the comments. - Rebased on top of the latest patches from Bo Chen. diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index 379ac2a6ab16..6b8e64899205 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -187,6 +187,94 @@ static irqreturn_t atmel_ssc_interrupt(int irq, void *dev_id) return IRQ_HANDLED; } +/* + * When the bit clock is input, limit the maximum rate according to the + * Serial Clock Ratio Considerations section from the SSC documentation: + * + * The Transmitter and the Receiver can be programmed to operate + * with the clock signals provided on either the TK or RK pins. + * This allows the SSC to support many slave-mode data transfers. + * In this case, the maximum clock speed allowed on the RK pin is: + * - Peripheral clock divided by 2 if Receiver Frame Synchro is input + * - Peripheral clock divided by 3 if Receiver Frame Synchro is output + * In addition, the maximum clock speed allowed on the TK pin is: + * - Peripheral clock divided by 6 if Transmit Frame Synchro is input + * - Peripheral clock divided by 2 if Transmit Frame Synchro is output + * + * When the bit clock is output, limit the rate according to the + * SSC divider restrictions. + */ +static int atmel_ssc_hw_rule_rate(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct atmel_ssc_info *ssc_p = rule->private; + struct ssc_device *ssc = ssc_p->ssc; + struct snd_interval *i = hw_param_interval(params, rule->var); + struct snd_interval t; + struct snd_ratnum r = { + .den_min = 1, + .den_max = 4095, + .den_step = 1, + }; + unsigned int num = 0, den = 0; + int frame_size; + int mck_div = 2; + int ret; + + frame_size = snd_soc_params_to_frame_size(params); + if (frame_size < 0) + return frame_size; + + switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) { + case SND_SOC_DAIFMT_CBM_CFS: + if ((ssc_p->dir_mask & SSC_DIR_MASK_CAPTURE) + && ssc->clk_from_rk_pin) + /* Receiver Frame Synchro (i.e. capture) + * is output (format is _CFS) and the RK pin + * is used for input (format is _CBM_). + */ + mck_div = 3; + break; + + case SND_SOC_DAIFMT_CBM_CFM: + if ((ssc_p->dir_mask & SSC_DIR_MASK_PLAYBACK) + && !ssc->clk_from_rk_pin) + /* Transmit Frame Synchro (i.e. playback) + * is input (format is _CFM) and the TK pin + * is used for input (format _CBM_ but not + * using the RK pin). + */ + mck_div = 6; + break; + } + + switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) { + case SND_SOC_DAIFMT_CBS_CFS: + r.num = ssc_p->mck_rate / mck_div / frame_size; + + ret = snd_interval_ratnum(i, 1, &r, &num, &den); + if (ret >= 0 && den && rule->var == SNDRV_PCM_HW_PARAM_RATE) { + params->rate_num = num; + params->rate_den = den; + } + break; + + case SND_SOC_DAIFMT_CBM_CFS: + case SND_SOC_DAIFMT_CBM_CFM: + t.min = 8000; + t.max = ssc_p->mck_rate / mck_div / frame_size; + t.openmin = t.openmax = 0; + t.integer = 0; + ret = snd_interval_refine(i, &t); + break; + + default: + ret = -EINVAL; + break; + } + + return ret; +} /*-------------------------------------------------------------------------*\ * DAI functions @@ -200,6 +288,7 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, struct atmel_ssc_info *ssc_p = &ssc_info[dai->id]; struct atmel_pcm_dma_params *dma_params; int dir, dir_mask; + int ret; pr_debug("atmel_ssc_startup: SSC_SR=0x%u\n", ssc_readl(ssc_p->ssc->regs, SR)); @@ -207,6 +296,7 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, /* Enable PMC peripheral clock for this SSC */ pr_debug("atmel_ssc_dai: Starting clock\n"); clk_enable(ssc_p->ssc->clk); + ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk); /* Reset the SSC to keep it at a clean status */ ssc_writel(ssc_p->ssc->regs, CR, SSC_BIT(CR_SWRST)); @@ -219,6 +309,17 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, dir_mask = SSC_DIR_MASK_CAPTURE; } + ret = snd_pcm_hw_rule_add(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_RATE, + atmel_ssc_hw_rule_rate, + ssc_p, + SNDRV_PCM_HW_PARAM_FRAME_BITS, + SNDRV_PCM_HW_PARAM_CHANNELS, -1); + if (ret < 0) { + dev_err(dai->dev, "Failed to specify rate rule: %d\n", ret); + return ret; + } + dma_params = &ssc_dma_params[dai->id][dir]; dma_params->ssc = ssc_p->ssc; dma_params->substream = substream; @@ -783,8 +884,6 @@ static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai) # define atmel_ssc_resume NULL #endif /* CONFIG_PM */ -#define ATMEL_SSC_RATES (SNDRV_PCM_RATE_8000_96000) - #define ATMEL_SSC_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |\ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE) @@ -804,12 +903,16 @@ static struct snd_soc_dai_driver atmel_ssc_dai = { .playback = { .channels_min = 1, .channels_max = 2, - .rates = ATMEL_SSC_RATES, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .rate_min = 8000, + .rate_max = 384000, .formats = ATMEL_SSC_FORMATS,}, .capture = { .channels_min = 1, .channels_max = 2, - .rates = ATMEL_SSC_RATES, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .rate_min = 8000, + .rate_max = 384000, .formats = ATMEL_SSC_FORMATS,}, .ops = &atmel_ssc_dai_ops, }; diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h index b1f08d511495..80b153857a88 100644 --- a/sound/soc/atmel/atmel_ssc_dai.h +++ b/sound/soc/atmel/atmel_ssc_dai.h @@ -115,6 +115,7 @@ struct atmel_ssc_info { unsigned short rcmr_period; struct atmel_pcm_dma_params *dma_params[2]; struct atmel_ssc_state ssc_state; + unsigned long mck_rate; }; int atmel_ssc_set_audio(int ssc_id); -- 1.7.10.4

3 2

[alsa-devel] [PATCH] ASoC: omap: Kconfig: Support for omap5-uevm analog audio
by Peter Ujfalusi 10 Feb '15

10 Feb '15

The analog audio is supported via omap-abe-twl6040 machine driver on omap5-uevm. Update the Kconfig file to reflect this and select the Palmas clock driver which is providing the 32K clock for audio on omap5-uevm. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/omap/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index a2cd3486ac55..e7c78b0406b5 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -100,17 +100,19 @@ config SND_OMAP_SOC_OMAP_TWL4030 config SND_OMAP_SOC_OMAP_ABE_TWL6040 tristate "SoC Audio support for OMAP boards using ABE and twl6040 codec" - depends on TWL6040_CORE && SND_OMAP_SOC && (ARCH_OMAP4 || COMPILE_TEST) + depends on TWL6040_CORE && SND_OMAP_SOC && (ARCH_OMAP4 || SOC_OMAP5 || COMPILE_TEST) select SND_OMAP_SOC_DMIC select SND_OMAP_SOC_MCPDM select SND_SOC_TWL6040 select SND_SOC_DMIC + select COMMON_CLK_PALMAS if SOC_OMAP5 help Say Y if you want to add support for SoC audio on OMAP boards using ABE and twl6040 codec. This driver currently supports: - SDP4430/Blaze boards - PandaBoard (4430) - PandaBoardES (4460) + - omap5-uevm (5432) config SND_OMAP_SOC_OMAP3_PANDORA tristate "SoC Audio support for OMAP3 Pandora" -- 2.2.2

2 1

[alsa-devel] [PATCH] ALSA: control: confirm to return all identical information in 'activate' event data
by Takashi Sakamoto 10 Feb '15

10 Feb '15

When event originator doesn't set numerical ID in identical information, the event data includes no numerical ID, thus userspace applications cannot identify the control just by unique ID in event data. This commit fix this bug so as the event data includes all of identical information. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/core/control.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/control.c b/sound/core/control.c index 6a72b3e..884fddd 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -587,6 +587,7 @@ int snd_ctl_activate_id(struct snd_card *card, struct snd_ctl_elem_id *id, } ret = 1; unlock: + *id = kctl->id; up_write(&card->controls_rwsem); if (ret > 0) snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_INFO, id); -- 2.1.0

2 5

Re: [alsa-devel] Regression for Lenovo X240 sound in 3.18
by Takashi Iwai 10 Feb '15

10 Feb '15

At Mon, 9 Feb 2015 12:38:00 +0100 (CET), Jan Engelhardt wrote: > > > On Monday 2015-02-09 11:29, Takashi Iwai wrote: > >> > >> On 3.19-rc3+ [eb74926920cfa756087a82e0b081df837177cb95] I confirm > >> all the volume bars/switches that went missing for me are back again. > >> > >> As said, all is fine here. > > > >Sorry, I've forgotten this pending issue. > >Could you confirm that the patch below works for you? Then I'll queue > >up for 3.20-rc1 and backport appropriately. > > I have no problems with 3.19-rc6. > Your patch does not appear to break anything, but it does not appear > to fix something, either. It does change the controls again though. > I suggest not to apply it. > > http://picpaste.de/3_19_rc6-NgtzogKW.png > http://picpaste.de/3_19_rc6_YOURPATCH-y6IcoXpE.png OK, if 3.19 works as is, then there is no reason to change there. Takashi

2 1

[alsa-devel] [PATCH lib] control: complement comment for subscribe API
by Takashi Sakamoto 09 Feb '15

09 Feb '15

From: Takashi Sakamoto <mocchi(a)Mocchi64.miraclelinux.com> When minus value is given as a parameter, the API returns whether the caller has already subscribed or not. This commit adds a comment about this so as better documentation. Signed-off-by: Takashi Sakamoto <mocchi(a)Mocchi64.miraclelinux.com> --- src/control/control.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/control/control.c b/src/control/control.c index dd428a1..4a28cf6 100644 --- a/src/control/control.c +++ b/src/control/control.c @@ -213,7 +213,7 @@ int snd_ctl_poll_descriptors_revents(snd_ctl_t *ctl, struct pollfd *pfds, unsign /** * \brief Ask to be informed about events (poll, #snd_async_add_ctl_handler, #snd_ctl_read) * \param ctl CTL handle - * \param subscribe 0 = unsubscribe, 1 = subscribe + * \param subscribe 0 = unsubscribe, 1 = subscribe, -1 = check subscribe or not * \return 0 on success otherwise a negative error code */ int snd_ctl_subscribe_events(snd_ctl_t *ctl, int subscribe) -- 2.1.0

2 3

[alsa-devel] [PATCH] ALSA: control: fix failure to return new numerical ID in 'replace' event data
by Takashi Sakamoto 09 Feb '15

09 Feb '15

In 'replace' event data, numerical ID of control is always invalid. This commit fix this bug so as the event data has renewed numerical ID for control. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/core/control.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/control.c b/sound/core/control.c index 884fddd..ab74b7e 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -440,6 +440,7 @@ add: card->controls_count += kcontrol->count; kcontrol->id.numid = card->last_numid + 1; card->last_numid += kcontrol->count; + id = kcontrol->id; count = kcontrol->count; up_write(&card->controls_rwsem); for (idx = 0; idx < count; idx++, id.index++, id.numid++) -- 2.1.0

2 1