summaryrefslogtreecommitdiff
path: root/sound
AgeCommit message (Collapse)AuthorFilesLines
2013-10-25Merge tag 'asoc-v3.13' of ↵Takashi Iwai111-2848/+3240
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Updates for v3.13 - Further work on the dmaengine helpers, including support for configuring the parameters for DMA by reading the capabilities of the DMA controller which removes some guesswork and magic numbers fromm drivers. - A refresh of the documentation. - Conversions of many drivers to direct regmap API usage in order to allow the ASoC level register I/O code to be removed, this will hopefully be completed by v3.14. - Support for using async register I/O in DAPM, reducing the time taken to implement power transitions on systems that support it.
2013-10-25ALSA: hda - hdmi: Re-setup pin and infoframe on plug-in on all codecsAnssi Hannula1-4/+5
hdmi_setup_audio_infoframe() does not set up pin and infoframe if there is no connected sink. If a sink is connected while audio playback is already in progress, the pin and infoframe will not be properly set up, causing no audio or wrongly mapped audio. On Intel Haswell codecs the hdmi_setup_audio_infoframe() is already called again from hdmi_present_sense() when an ELD appears because transcoder:port mapping may have changed. Make the call non-Haswell-specific so that audio will be properly set up if the playback was started before a sink was connected. Tested on non-Haswell Intel HDMI codec by plugging sink in during playback. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-25ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecsAnssi Hannula1-0/+22
Recent AMD HDMI codecs (revision ID 3 and later, 0x100300 as reported by procfs codec#0) have a configurable ramp-up/down functionality. The documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf ) specifies that 180 ("180/256 =~ 0.7") is recommended for PCM and 0 for non-PCM. Apply the recommended values according to provided S/PDIF AES0 settings since ramp-up/down does not make sense for non-PCM. v2: adapted to hdmi_ops infrastructure * More note from Anssi: actually, re-reading mails reveals that Olivier didn't find the expected difference with this setting, except for "maybe slightly slower startup with AES0=6" (i.e. value 0, which is unexpected). So maybe a) it makes too unnoticiable a difference, or b) only affects certain hardware (card and/or sink), or c) ramp-up/down is only triggered with the MUTE bit of ATI_VERB_SET_MULTICHANNEL_xx which is also rev3+ specific, but is not presently used by the driver, or something else. So there's a significant chance setting ramp rate is useless for us ATM, but probably does not do actual harm either. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: Olivier Langlois <olivier@trillion01.com> # v1 Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-25ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecsAnssi Hannula1-0/+35
ATI/AMD HDMI codecs do not include standard HDA HDMI HBR support (which is required for bitstreaming DTS-HD and Dolby TrueHD), instead they have custom verbs for checking and enabling it. Add support for the ATI/AMD HDMI HBR verbs. The specification is available at: http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf v2: adapted to hdmi_ops infrastructure Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: Peter Frühberger <fritsch@xbmc.org> # v1 Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-25ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecsAnssi Hannula3-0/+164
ATI/AMD HDMI/DP codecs do not include standard HDA ELD (EDID-like data) support. In place of providing access to an ELD buffer, various vendor-specific verbs are provided to provide the relevant information. Revision ID 3 and later (0x100300 as reported by procfs codec#X) have support for providing more information than the previous revisions (but only if supported by the display driver). Generate ELD from the information provided by the vendor-specific verbs on ATI/AMD codecs. The specification is available at: http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf v2: moved code to hda_eld.c and cleaned it up v3: adapted to hdmi_ops infrastructure Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2 Tested-by: Olivier Langlois <olivier@trillion01.com> # v2 Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-25ALSA: hda - hdmi: Add ATI/AMD multi-channel audio supportAnssi Hannula1-29/+273
ATI/AMD codecs do not support all the standard HDA HDMI/DP functions, instead various vendor-specific verbs are provided. This commit addresses these missing functions: - standard channel mapping support - standard infoframe configuration support ATI/AMD provides their own verbs that allow the following: - setting CA for infoframe - setting down-mix information for infoframe - channel pair remapping - individual channel remapping (revision ID 3+, 0x100300+) The documentation for the verbs has now been released by AMD: http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf Add support for the ATI/AMD specific verbs and use them instead of the generic methods on ATI/AMD codecs. This allows multi-channel PCM audio to work. Channel remapping is restricted to pairwise mapping on codecs with revision ID 2 (0x100200 as reported by procfs codec#X) or lower. This means cards up to Radeon HD7670 as far as I know. This will not affect standard multi-channel modes since these codecs support automatic FC-LFE swapping for HDMI. ATI/AMD codecs do not advertise all of their supported rates, formats and channel counts, therefore that information is forced accordingly so that all HDMI 1.x PCM parameters are marked as supported. Support for multiple ports is also added to patch_atihdmi so that 0x1002aa01 codecs with multiple ports will work properly when switched back to that patch. v2: splitted ELD emulation to a separate patch, tlv fixes v3: adapted to the new hdmi_ops infrastructure, fixed rev3+ vendor id Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2 Tested-by: Olivier Langlois <olivier@trillion01.com> # v2+rev3fix Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-25ALSA: hda - hdmi: Allow HDA patches to customize more operationsAnssi Hannula1-80/+195
Upcoming AMD multichannel support requires many customized operations (channel mapping, ELD, HBR) but can otherwise share most of its code with the generic patch. Add a local struct hdmi_ops containing customizable HDMI-specific callbacks and move the current code to those callbacks. Functionality is unaltered. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-24ALSA: hda/realtek - Raise the delay for alc283_shutupKailang Yang1-2/+2
Some machine with 85ms delay might be happen pop noise when codec enter to D3. Raise up to 100ms delay will be match for more machine. Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-24ALSA: compress: fix drain calls blocking other compress functionsVinod Koul1-3/+38
The drain and drain_notify callback were blocked by low level driver untill the draining was complete. Due to this being invoked with big fat mutex held, others ops like reading timestamp, calling pause, drop were blocked. So to fix this we add a new snd_compr_drain_notify() API. This would be required to be invoked by low level driver when drain or partial drain has been completed by the DSP. Thus we make the drain and partial_drain callback as non blocking and driver returns immediately after notifying DSP. The waiting is done while relasing the lock so that other ops can go ahead. Signed-off-by: Vinod Koul <vinod.koul@intel.com> CC: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-24ALSA: Add ifdef CONFIG_GENERIC_ALLOCATOR for SNDRV_DMA_TYPE_IRAM codeTakashi Iwai2-0/+6
It turned out that we can't use gen_pool_*() functions on archs without CONFIG_GENERIC_ALLOCATOR (resulting in missing symbols), since linux/genalloc.h doesn't provide dummy functions for all. We'd be able to fix linux/genalloc.h size, but I take an easier path for now... Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-10-24Merge remote-tracking branch 'asoc/topic/wm8962' into asoc-nextMark Brown1-110/+108
2013-10-24Merge remote-tracking branch 'asoc/topic/wm8400' into asoc-nextMark Brown1-75/+20
2013-10-24Merge remote-tracking branch 'asoc/topic/twl6040' into asoc-nextMark Brown1-19/+7
2013-10-24Merge remote-tracking branch 'asoc/topic/twl4030' into asoc-nextMark Brown1-44/+36
2013-10-24Merge remote-tracking branch 'asoc/topic/tpa6130a2' into asoc-nextMark Brown1-9/+23
2013-10-24Merge remote-tracking branch 'asoc/topic/tlv320aic3x' into asoc-nextMark Brown1-121/+113
2013-10-24Merge remote-tracking branch 'asoc/topic/tlv320aic32x4' into asoc-nextMark Brown1-71/+30
2013-10-24Merge remote-tracking branch 'asoc/topic/tlv320aic26' into asoc-nextMark Brown2-116/+28
2013-10-24Merge remote-tracking branch 'asoc/topic/tlv320aic23' into asoc-nextMark Brown1-50/+34
2013-10-24Merge remote-tracking branch 'asoc/topic/tegra' into asoc-nextMark Brown6-28/+186
2013-10-24Merge remote-tracking branch 'asoc/topic/tas5086' into asoc-nextMark Brown1-62/+109
2013-10-24Merge remote-tracking branch 'asoc/topic/spear' into asoc-nextMark Brown2-22/+4
2013-10-24Merge remote-tracking branch 'asoc/topic/sn95031' into asoc-nextMark Brown1-15/+20
2013-10-24Merge remote-tracking branch 'asoc/topic/simple' into asoc-nextMark Brown1-0/+5
2013-10-24Merge remote-tracking branch 'asoc/topic/si476x' into asoc-nextMark Brown1-48/+16
2013-10-24Merge remote-tracking branch 'asoc/topic/samsung' into asoc-nextMark Brown3-18/+11
2013-10-24Merge remote-tracking branch 'asoc/topic/rt5640' into asoc-nextMark Brown1-3/+21
2013-10-24Merge remote-tracking branch 'asoc/topic/rcar' into asoc-nextMark Brown6-184/+207
2013-10-24Merge remote-tracking branch 'asoc/topic/pxa' into asoc-nextMark Brown13-48/+46
2013-10-24Merge remote-tracking branch 'asoc/topic/pcm1792a' into asoc-nextMark Brown1-0/+1
2013-10-24Merge remote-tracking branch 'asoc/topic/pcm1681' into asoc-nextMark Brown1-0/+1
2013-10-24Merge remote-tracking branch 'asoc/topic/mxs' into asoc-nextMark Brown3-22/+33
2013-10-24Merge remote-tracking branch 'asoc/topic/mc13783' into asoc-nextMark Brown1-56/+79
2013-10-24Merge remote-tracking branch 'asoc/topic/max9850' into asoc-nextMark Brown1-10/+29
2013-10-24Merge remote-tracking branch 'asoc/topic/max98095' into asoc-nextMark Brown1-296/+170
2013-10-24Merge remote-tracking branch 'asoc/topic/max98088' into asoc-nextMark Brown1-351/+273
2013-10-24Merge remote-tracking branch 'asoc/topic/kirkwood' into asoc-nextMark Brown5-27/+93
2013-10-24Merge remote-tracking branch 'asoc/topic/fsl' into asoc-nextMark Brown7-24/+17
2013-10-24Merge remote-tracking branch 'asoc/topic/ep93xx' into asoc-nextMark Brown1-1/+1
2013-10-24Merge remote-tracking branch 'asoc/topic/dma' into asoc-nextMark Brown5-28/+100
2013-10-24Merge remote-tracking branch 'asoc/topic/devm' into asoc-nextMark Brown11-52/+104
2013-10-24Merge remote-tracking branch 'asoc/topic/davinci' into asoc-nextMark Brown5-77/+311
2013-10-24Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown2-46/+81
2013-10-24Merge remote-tracking branch 'asoc/topic/cs42l73' into asoc-nextMark Brown2-90/+129
2013-10-24Merge remote-tracking branch 'asoc/topic/cs4271' into asoc-nextMark Brown1-0/+1
2013-10-24Merge remote-tracking branch 'asoc/topic/cq93vc' into asoc-nextMark Brown1-32/+14
2013-10-24Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown5-300/+96
2013-10-24Merge remote-tracking branch 'asoc/topic/component' into asoc-nextMark Brown1-90/+147
2013-10-24Merge remote-tracking branch 'asoc/topic/bclk' into asoc-nextMark Brown1-0/+16
2013-10-24Merge remote-tracking branch 'asoc/topic/atmel' into asoc-nextMark Brown3-9/+2