- 06 11月, 2013 1 次提交
-
-
由 Takashi Iwai 提交于
Haswell HDMI audio controllers seem to get stuck when unaligned buffer size is used. Let's enable the buffer alignment for the corresponding entries. Since AZX_DCAPS_INTEL_PCH contains AZX_DCAPS_BUFSIZE that disables the buffer alignment forcibly, define AZX_DCAPS_INTEL_HASWELL and put the necessary AZX_DCAPS bits there. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60769Reported-by: NAlexander E. Patrakov <patrakov@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 05 11月, 2013 11 次提交
-
-
由 Linus Walleij 提交于
This include is completely unused since the AT91 sound driver actually uses gpiolib properly. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 David Henningsson 提交于
Same as we already have for Conexant. Right now it's only enabled for one machine. Tested-by: NHui Wang <hui.wang@canonical.com> Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Clemens Ladisch 提交于
The device IDs of the AMD Cypress/Juniper/Redwood/Cedar/Cayman/Antilles/ Barts/Turks/Caicos HDMI HDA controllers weren't added explicitly because the generic entry works, but it made the device appearing as "Generic", and people are confused as if it's no proper HDMI controller. Add them so that the name shows up properly as "ATI HDMI" instead of "Generic". According to Takashi's tests and the lack of complaints, these devices work fine without disabling snooping. Signed-off-by: NClemens Ladisch <clemens@ladisch.de> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Add a bitmask to hda_gen_spec indicating NIDs to exclude from the possible volume controls. That is, when the bit is set, the NID corresponding to the bit won't be picked as an output volume control any longer. Basically this is just a band-aid for working around the issue found with CS4208 codec, where only the headphone pin has a volume AMP with different dB steps. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60811 Cc: <stable@vger.kernel.org> [v3.12+] Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Check whether all vmaster slaves have the same dB steps. Otherwise the behavior would become inconsistent. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Check the TLV db scale result before actually dividing in vmaster slave init code. Also mask TLV_DB_SCALE_MUTE bit so that the right value is obtained even if this bit is set by the codec driver. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 David Henningsson 提交于
In case the channel count of the input terminal is not the same as the channel count of the streaming descriptor, the channel config of the input terminal can not be trusted. Instead fall back to a default (guessed) channel map. This was found on a Logitech USB Headset. Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 David Henningsson 提交于
The channel config from the streaming descriptor is probably a better indicator of the channel map than the input terminal. Use the input terminal's channel map as fallback only. Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 David Henningsson 提交于
If wChannelconfig is given for some formats but not others, userspace might not be able to set the channel map. This is RFC because I'm not sure what the best behaviour is - to guess the channel map from the given number of channels (it's quite likely that one channel is MONO and two channels is FL FR), or just to supply UNKNOWN for all channels. But the complete lack of channel map for a format leads userspace to believe that the format is not available at all. Or am I misunderstanding how this should be used? Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
BIOS on Acer TravelMate 6293 doesn't set up the SPDIF output pin correctly as default, so enable it via a fixup entry. Reported-and-tested-by: NHagen Heiduck <heiduck.suse@fmail.postpro.net> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 James Ralston 提交于
This patch adds the HD Audio Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by: NJames Ralston <james.d.ralston@intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 04 11月, 2013 22 次提交
-
-
由 Mengdong Lin 提交于
The function name not_share_unassigned_cvt() is opposite to what it does. This patch renames it to intel_not_share_assigned_cvt(), and addes comments to explain why some Intel display codecs need this workaround. Signed-off-by: NMengdong Lin <mengdong.lin@intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Anssi Hannula 提交于
NVIDIA HDMI codecs do not seem to follow the Audio Sample Packet (ASP) channel mapping (as set by verb F32h per HDA specification 7.3.3.41) when playing back 2-channel audio (CEA CA 0x00). Basically this means that specifying swapped channels for stereo audio (FR,FL) does not take effect, and e.g. this command plays back on the wrong channel: speaker-test -c2 -Dhdmi:CARD=NVidia,DEV=0 -m FR,FL -s1 Multichannel audio is not affected. This issue has been confirmed to exist on codec 0x10de0015 by me and on 0x10de0040 by Juho Teperi. Disable 2ch FL/FR channel swapping on all NVIDIA HDMI codecs that use the standard HDA channel mapping system. Since this is a very minor functionality loss, we err on the side of disabling it for newer codecs as well until any future testing confirms that this issue has been fixed. Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi> Helped-by: NJuho Teperi <juho.teperi@iki.fi> Cc: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
-
由 Takashi Iwai 提交于
Merge tag 'asoc-v3.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Final updates for v3.13 A few final updates for v3.13, all driver updates apart from some DPCM and Coverity fixes which should have minor impact on practical systems.
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
-
- 02 11月, 2013 6 次提交
-
-
由 Richard Fitzgerald 提交于
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Richard Fitzgerald 提交于
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Dimitris Papastamos 提交于
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Dimitris Papastamos 提交于
Do it in a similar fashion as we do for ADSP2. Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Dimitris Papastamos 提交于
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Dimitris Papastamos 提交于
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-