- 11 Jan, 2012 1 commit
-
-
Takashi Iwai authored
When multiple headphone or other detectable output pins are present, the power-map has to be updated after resume appropriately, but the current driver doesn't check all pins but only the first pin (since it's enough to check it for the mute-behavior). This resulted in the silent output from the secondary outputs after PM resume. This patch fixes the problem by checking all pins at (re-)init time. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740347 Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 10 Jan, 2012 3 commits
-
-
Takashi Iwai authored
Currently the driver checks only the out_mix_path[] for the primary output route for judging whether to create the loopback-mixing control or not. But, there are cases where aamix-routing is available only on headphone or speaker paths but not on the primary output path. So, the driver ignores such cases inappropriately. This patch fixes the check of the loopback-mixing control by testing all mix-routing paths. Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
When an invalid NID is given, get_wcaps() returns zero as the error, but get_wcaps_type() takes it as the normal value and returns a bogus AC_WID_AUD_OUT value. This confuses the parser. With this patch, get_wcaps_type() returns -1 when value 0 is given, i.e. an invalid NID is passed to get_wcaps(). Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118 Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
These laptops can work well with the auto-parser and their BIOS setups, and in addition, the auto-parser fixes the problem with S3/S4 where the unsol event handling is killed after resume due to fallback to the single-cmd mode. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740115 Cc: <stable@kernel.org> [v3.1+] Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 09 Jan, 2012 1 commit
-
-
Jérémy Lal authored
This early 2011 model just need to have headphones on GPI02 instead of GPI01, and use BIOS pincfgs. It is detected by codec SSID. The iMac12,1 model is known to work the same way, although maybe not with the same codec SSID. Signed-off-by: Jérémy Lal <kapouer@melix.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 08 Jan, 2012 6 commits
-
-
David Henningsson authored
Now that we have changed the poulsbo chip to use LPIB position fix, we can remove the individual machine quirks that do the same thing. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Henningsson authored
This fixup is not actually used, so in practice this is just a cosmetic fix. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Henningsson authored
The CS4213 chip is similar to the CS4210, but it does not have SPDIF capabilities. Also, it has fewer pins, and the vendor specific nid is different. With this patch, we have working inputs and outputs (and automute/autoswitch). However, we don't know anything about the vendor specific processing coefficients, so we don't read or write to that node in this patch. BugLink: https://bugs.launchpad.net/bugs/910792Tested-by: Hsin-Yi Chen <hychen@canonical.com> Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Henningsson authored
There was a bug in the automute logic causing speakers not to mute when headphones were plugged in. Cc: stable@kernel.org Tested-by: Hsin-Yi Chen <hychen@canonical.com> Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Henningsson authored
The control name "HP/Speakers" is non-standard, and since there is only one DAC on this chip there is no need for a virtual master anyway. Cc: stable@kernel.org Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Henningsson authored
According to the thread on alsa-devel, the LPIB method is to prefer for Oaktrail controller chip. Reference: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-January/047800.htmlSigned-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 31 Dec, 2011 1 commit
-
-
Li Peng authored
Oaktrail has 0x8086, 0x080a - AZX_DRIVER_SCH Taken from the Meego patches for Oaktrail Signed-off-by: Li Peng <peng.li@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 20 Dec, 2011 3 commits
-
-
Takashi Iwai authored
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Conflicts: sound/pci/hda/patch_hdmi.c sound/pci/hda/patch_via.c
-
Takashi Iwai authored
-
- 15 Dec, 2011 1 commit
-
-
David Henningsson authored
Several people with this chipset have reported inconsistent/sloppy values for position reporting when the DMA position buffer is used, and that setting position_fix=1 have fixed their problems. BugLink: https://bugs.launchpad.net/bugs/825709Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 14 Dec, 2011 3 commits
-
-
Takashi Iwai authored
Merge the checks for VIA and ATI-HDMI into a single place for better code-flow management. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Andiry Xu authored
This patch adds HDMI audio support for new AMD products. As HW default disable snoop, force non-snoop mode in HD audio driver. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Gustavo Maciel Dias Vieira authored
Commit b99a776d removed all effects of the STAC92HD83* model quirk "hp". However, it left the model selection and documentation behind, confusing users with inverted mute leds. Completely remove this quirk and its documentation. Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 13 Dec, 2011 2 commits
-
-
Gustavo Maciel Dias Vieira authored
Some HP laptop models do not have a properly filled OEM string used to set the gpio and polarity of the mute led. Make the mute led configuration work for this case. Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Vitaliy Kulikov authored
This may lead to problems (like loss of sound) as GPIO pin may be used for different function (SPDIF OUT, EAPD etc) on those systems. This patch disables default mute LED GPIO configuration on all new codecs as all new HP systems are expected to provide explicit mute LED configuration in SMBIOS. Signed-off-by: Vitaliy Kulikov <Vitaliy.Kulikov@idt.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 12 Dec, 2011 2 commits
-
-
David Henningsson authored
With the auto-parser we can choose the dac nid for vmaster from the DACs we already know, instead of hard-coding it. This is more future-proof and was actually wrong on one machine. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Henningsson authored
For the Asus 1101HA, reporting position by reading the DMA position buffer map seems unstable and often wrong. The reporter says that position_fix=LPIB works much better (although not 100%, but this is probably due to other issues). The controller chip is an Intel Poulsbo 8086:811b (rev 07) controller, and complete alsa-info is available here: https://launchpadlibrarian.net/86691768/alsa-info.txt.1TNwyE5Ea7 Cc: stable@kernel.org (3.0+) BugLink: http://bugs.launchpad.net/bugs/825709 Tested-by: Stefano Lodi Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 07 Dec, 2011 4 commits
-
-
Takashi Iwai authored
Conflicts: sound/pci/hda/patch_realtek.c
-
Takashi Iwai authored
When there are the same or more number of HP pins are available, HP pins are used as the primary outputs instead of the speaker pins. But, in some cases (especially with ALC663 & co), some DACs are available only with a later pin and it's assigned to a speaker, and since the driver parses the pins from the lower NID, such a DAC was skipped eventually without assignments. This resulted in a regression, the missing speaker volume control in the new parser. As a workaround for this, now the driver retries the pin->DAC mapping again after restoring the speaker-pins as primary. This is still an ad hoc fix, but it works so far for most of Realtek codecs. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
On systems with two speaker pins, the secondary speaker pin is mostly assigned to a bass speaker instead of a surround. Thus it makes more sense to rename the control properly. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The multiple headphone or speaker pins are usually provided to output the same stream unlike line-out jacks (which are supposed to be multi-channel surrounds). Thus giving a mixer name like "Headphone Surround" is rather confusing. Instead, when multiple headphone volumes are available, use index with the same "Headphone" name. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 06 Dec, 2011 5 commits
-
-
Takashi Iwai authored
-
Takashi Iwai authored
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
-
Takashi Iwai authored
Some HP laptops with IDT 92HD75 codecs may use a GPIO > 4 for the mute LED, but currently the driver doesn't check this properly, and confuses the mute LED behavior. This ended up with the silent output on some HP laptops due to having another GPIO used as external amp control. This patch fixes the problem by checking the max GPIO count and comparing with the given value from DMI entry instead of magic fixed value 4 and 8, and adding a new field to indicate the VREF mute-LED behavior. Reported-and-tested-by: Vitaliy Kulikov <Vitaliy.Kulikov@idt.com> Cc: <stable@kernel.org> [v3.1] Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Mark Brown authored
Allow userspace applications to do more parameter setting by providing a more complete stub DMA driver specifying a wildcard set of formats and channels and essentially random values for the DMA parameters. This is required for useful runtime operation of the dummy DMA driver until we are able to figure out how to power up links and do hw_params() from DAPM. Sending to stable as without this the dummy driver is not terribly useful. Reported-by: Kyung-Kwee Ryu <Kyung-Kwee.Ryu@wolfsonmicro.com> Tested-by: Kyung-Kwee Ryu <Kyung-Kwee.Ryu@wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org
-
- 05 Dec, 2011 1 commit
-
-
Mark Brown authored
They're not currently actively worked on, the hardware being rather obsolete by now. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
- 04 Dec, 2011 3 commits
-
-
Axel Lin authored
SND_SOC_MX27VIS_AIC32X4 selects SND_SOC_TLV320AIC32X4, but SND_SOC_TLV320AIC32X4 needs CONFIG_I2C. So we need to make SND_SOC_MX27VIS_AIC32X4 depend on I2C. otherwise I got below build error if CONFIG_I2C is not selected. CC sound/soc/codecs/tlv320aic32x4.o sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_read': sound/soc/codecs/tlv320aic32x4.c:323: error: implicit declaration of function 'i2c_smbus_read_byte_data' sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_probe': sound/soc/codecs/tlv320aic32x4.c:641: error: 'i2c_master_send' undeclared (first use in this function) sound/soc/codecs/tlv320aic32x4.c:641: error: (Each undeclared identifier is reported only once sound/soc/codecs/tlv320aic32x4.c:641: error: for each function it appears in.) sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_modinit': sound/soc/codecs/tlv320aic32x4.c:763: error: implicit declaration of function 'i2c_add_driver' sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_exit': sound/soc/codecs/tlv320aic32x4.c:774: error: implicit declaration of function 'i2c_del_driver' make[3]: *** [sound/soc/codecs/tlv320aic32x4.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
SND_SOC_RAUMFELD selects SND_SOC_CS4270 which needs CONFIG_I2C, and also selects SND_SOC_AK4104 which needs SPI_MASTER. Thus make SND_SOC_RAUMFELD depend on I2C && SPI_MASTER. Add depend on SPI_MASTER to fix below build error if CONFIG_SPI_MASTER is not selected. LD .tmp_vmlinux1 sound/built-in.o: In function `ak4104_spi_write': last.c:(.text+0x290cc): undefined reference to `spi_sync' sound/built-in.o: In function `ak4104_probe': last.c:(.text+0x292a0): undefined reference to `spi_write_then_read' sound/built-in.o: In function `ak4104_spi_probe': last.c:(.text+0x29398): undefined reference to `spi_setup' sound/built-in.o: In function `ak4104_init': last.c:(.init.text+0x4ec): undefined reference to `spi_register_driver' make: *** [.tmp_vmlinux1] Error 1 Add depend on I2C to fix below build error if CONFIG_I2C is not selected: CC sound/soc/codecs/cs4270.o sound/soc/codecs/cs4270.c: In function 'cs4270_i2c_probe': sound/soc/codecs/cs4270.c:657: error: implicit declaration of function 'i2c_smbus_read_byte_data' sound/soc/codecs/cs4270.c: In function 'cs4270_init': sound/soc/codecs/cs4270.c:730: error: implicit declaration of function 'i2c_add_driver' sound/soc/codecs/cs4270.c: In function 'cs4270_exit': sound/soc/codecs/cs4270.c:736: error: implicit declaration of function 'i2c_del_driver' make[3]: *** [sound/soc/codecs/cs4270.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 SND_PXA2XX_SOC_HX4700 selects SND_SOC_AK4641 which needs CONFIG_I2C. Thus make SND_PXA2XX_SOC_HX4700 depend on I2C. Add depend on I2C to fix below build error if CONFIG_I2C is not selected: CC sound/soc/codecs/ak4641.o sound/soc/codecs/ak4641.c: In function 'ak4641_modinit': sound/soc/codecs/ak4641.c:646: error: implicit declaration of function 'i2c_add_driver' sound/soc/codecs/ak4641.c: In function 'ak4641_exit': sound/soc/codecs/ak4641.c:656: error: implicit declaration of function 'i2c_del_driver' make[3]: *** [sound/soc/codecs/ak4641.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Return proper error for uda1380_modinit if i2c_add_driver() fails. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
- 03 Dec, 2011 1 commit
-
-
Axel Lin authored
SND_KIRKWOOD_SOC_T5325 selects SND_SOC_ALC5623, but SND_SOC_ALC5623 needs CONFIG_I2C. So we need to make SND_KIRKWOOD_SOC_T5325 depend on I2C, otherwise I got below build error if CONFIG_I2C is not selected. CC sound/soc/codecs/alc5623.o sound/soc/codecs/alc5623.c: In function 'alc5623_i2c_probe': sound/soc/codecs/alc5623.c:1002: error: implicit declaration of function 'i2c_smbus_read_word_data' sound/soc/codecs/alc5623.c:1009: error: implicit declaration of function 'i2c_smbus_read_byte_data' sound/soc/codecs/alc5623.c: In function 'alc5623_modinit': sound/soc/codecs/alc5623.c:1096: error: implicit declaration of function 'i2c_add_driver' sound/soc/codecs/alc5623.c: In function 'alc5623_modexit': sound/soc/codecs/alc5623.c:1108: error: implicit declaration of function 'i2c_del_driver' make[3]: *** [sound/soc/codecs/alc5623.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Also fix the same issue for SND_KIRKWOOD_SOC_OPENRD. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
- 02 Dec, 2011 3 commits
-
-
Mark Brown authored
Since they don't actually have power bits but do have events associated with them it's important that we bootstrap their state properly which making them virtual does. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Takashi Iwai authored
When no imux is available (e.g. a single capture source), alc_auto_init_input_src() may trigger an Oops due to the access to -1. Add a proper zero-check to avoid it. Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
David Dillow authored
There are some AC97 codec and board combinations that have been observed to take a very long time to respond after the cold reset has completed. In one case, more than 350 ms was required. To allow users to have sound on those platforms, we'll wait up to 500ms for the codec to become ready. As a board may have multiple codecs, with some faster than others to reset, we add a module parameter to inform the driver which codecs should be present. Reported-by: KotCzarny <tjosko@yahoo.com> Signed-off-by: David Dillow <dave@thedillows.org> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-