- 21 3月, 2015 2 次提交
-
-
由 Takashi Iwai 提交于
David suggested that the name "power_mgmt" is too ambiguous. Rename the flag with a bit clearer one "power_save_node". Also, add the corresponding description to HD-Audio.txt, too. Reported-by: NDavid Henningsson <david.henningsson@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Some pins are used for controlling the LED with the VREF value. This patch changes the power behavior of such pins to be constantly up. A new state, pin_fixed, is introduced to nid_path to indicate that the path contains the fixed pin. This improves also the readability a bit for other static routes, too. Then a helper function snd_hda_gen_fix_pin_power() is called from the codec driver for such fixed pins, and it will create fake paths containing only these pins with pin_fixed=1 flag. Reported-by: NDavid Henningsson <david.henningsson@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 19 3月, 2015 1 次提交
-
-
由 Fabian Frederick 提交于
of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Signed-off-by: NFabian Frederick <fabf@skynet.be> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 18 3月, 2015 10 次提交
-
-
由 Takashi Iwai 提交于
As the widget PM may turn off the pins, this might lead to the silent output for beep when no explicit paths are given. This patch adds fake output paths for the beep widget so that the output pins are dynamically powered upon beep on/off. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
VIA codecs used to have the own power controls but they were disabled at transition to the generic parser due to the coding assuming the fixed routes. Now we get the proper support of equivalently fine power management in the generic parser, and the old kludges can be replaced with it. This results in the reduction of lots of dead codes. The advanced PM feature is disabled as default like before for keeping the compatible behavior. It's enabled via "Dynamic Power-Control" mixer element. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
This patch enables the finer power state control of each widget depending on the jack plug state and streaming state in addition to the existing power_down_unused power optimization. The new feature is enabled only when codec->power_mgmt flag is set. Two new flags, pin_enabled and stream_enabled, are introduced in nid_path struct for marking the two individual power states: the pin plug/unplug and DAC/ADC stream, respectively. They can be set statically in case they are static routes (e.g. some mixer paths), too. The power up and down events for each pin are triggered via the standard hda_jack table. The call order is hard-coded, relying on the current implementation of jack event chain (a la FILO/stack order). One point to be dealt carefully is that DAC/ADC cannot be powered on/off while streaming. They are pinned as long as the stream is running. For controlling the power of DAC/ADC, a new patch_ops is added. The generic parser provides the default callback for that. As of this patch, only IDT/Sigmatel codec driver enables the flag. The support on other codecs will follow. An assumption we made in this code is that the widget state (e.g. amp, pinctl, connections) remains after the widget power transition (not about FG power transition). This is true for IDT codecs, at least. But if the widget state is lost at widget power transition, we'd need to implement additional code to sync the cached amp/verbs for the specific NID. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Clément Guedez 提交于
Add sampling rate control for ADC/DAC for ESI W192M. Allow to switch between 48K/96K/192K sampling rate. All DAC need to be mute when changing samplerate. Signed-off-by: NClément Guedez <klem.dev@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Clément Guedez 提交于
Add text Line in/Mic for selecting input gain state in mixer for ESI W192M. Signed-off-by: NClément Guedez <klem.dev@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Clément Guedez 提交于
Add TLV support to control volume using dB scale for input and ouput on ESI W192M. Signed-off-by: NClément Guedez <klem.dev@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Clément Guedez 提交于
Enable midi i/o port of envy24 chip as their are available on ESI W192M soundcard. Signed-off-by: NClément Guedez <klem.dev@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Clément Guedez 提交于
Update eeprom structure to C99 standard to be compliant with change in alsa. It's just a notation change, no configuration change. Signed-off-by: NClément Guedez <klem.dev@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Clément Guedez 提交于
Correct copy/paste name from prodigy driver, no behaviour change, only name. Signed-off-by: NClément Guedez <klem.dev@gmail.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
This patch does two things: - code refactoring with a local helper function, - allow codec drivers to provide the specific PCM stream info pointers only for overriding the non-NULL entries, instead of copying the whole. This simplifies the codec driver side (currently the only user is alc269's 44kHz fixed rate). Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 16 3月, 2015 1 次提交
-
-
由 Takashi Iwai 提交于
The commit [ef403edb: ALSA: hda - Don't access stereo amps for mono channel widgets] fixed the handling of mono widgets in general, but it still misses an exceptional case: namely, a mono mixer widget taking a single stereo input. In this case, it has stereo volumes although it's a mono widget, and thus we have to take care of both left and right input channels, as stated in HD-audio spec ("7.1.3 Widget Interconnection Rules"). This patch covers this missing piece by adding proper checks of stereo amps in both the generic parser and the proc output codes. Reported-by: NRaymond Yau <superquad.vortex2@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 13 3月, 2015 5 次提交
-
-
由 Takashi Iwai 提交于
The driver shutdown ops is simpler than registering reboot notifier manually. There should be no functional change by this -- the codec driver calls its own callback while the bus driver just calls azx_stop() like before. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
The current HDA generic parser initializes / modifies the amp values always in stereo, but this seems causing the problem on ALC3229 codec that has a few mono channel widgets: namely, these mono widgets react to actions for both channels equally. In the driver code, we do care the mono channel and create a control only for the left channel (as defined in HD-audio spec) for such a node. When the control is updated, only the left channel value is changed. However, in the resume, the right channel value is also restored from the initial value we took as stereo, and this overwrites the left channel value. This ends up being the silent output as the right channel has been never touched and remains muted. This patch covers the places where unconditional stereo amp accesses are done and converts to the conditional accesses. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94581 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
In the commit [2225e79b: 'ALSA: core: reduce stack usage related to snd_ctl_new()'], the id field of the newly added kctl is untouched, thus all attribute like name string remain empty. The fix is just to add the forgotten memcpy of the id field. Fixes: 2225e79b ('ALSA: core: reduce stack usage related to snd_ctl_new()') Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the built-in mic records only the right channel. Apply the same workaround as MBP8,1 to spread the mono channel via a Cirrus codec vendor-specific COEF setup. Reported-and-tested-by: NVasil Zlatanov <vasil.zlatanov@gmail.com> Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
CS420x codecs seem to deal only the single amps of ADC nodes even though the nodes receive multiple inputs. This leads to the inconsistent amp value after S3/S4 resume, for example. The fix is just to set codec->single_adc_amp flag. Then the driver handles these ADC amps as if single connections. Reported-and-tested-by: NVasil Zlatanov <vasil.zlatanov@gmail.com> Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 12 3月, 2015 4 次提交
-
-
由 Daniel Mack 提交于
The device complies to the UAC1 standard but hides that fact with proprietary descriptors. The autodetect quirk for Roland devices catches the audio interface but misses the MIDI part, so a specific quirk is needed. Signed-off-by: NDaniel Mack <daniel@zonque.org> Reported-by: NRafa Lafuente <rafalafuente@gmail.com> Tested-by: NRaphaël Doursenaud <raphael@doursenaud.fr> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
There was no check about the id string of user control elements, so we accepted even a control element with an empty string, which is obviously bogus. This patch adds more sanity checks of id strings. Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Shawn Guo 提交于
Since commit 035a61c3 ("clk: Make clk API return per-user struct clk instances"), clk API users can no longer check if two struct clk pointers are pointing to the same hardware clock, i.e. struct clk_hw, by simply comparing two pointers. That's because with the per-user clk change, a brand new struct clk is created whenever clients try to look up the clock by calling clk_get() or sister functions like clk_get_sys() and of_clk_get(). This changes the original behavior where the struct clk is only created for once when clock driver registers the clock to CCF in the first place. The net change here is before commit 035a61c3 the struct clk pointer is unique for given hardware clock, while after the commit the pointers returned by clk lookup calls become different for the same hardware clock. That said, the struct clk pointer comparing in the code doesn't work any more. Call helper function clk_is_match() instead to fix the problem. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NMichael Turquette <mturquette@linaro.org> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
-
由 Shawn Guo 提交于
Since commit 035a61c3 ("clk: Make clk API return per-user struct clk instances"), clk API users can no longer check if two struct clk pointers are pointing to the same hardware clock, i.e. struct clk_hw, by simply comparing two pointers. That's because with the per-user clk change, a brand new struct clk is created whenever clients try to look up the clock by calling clk_get() or sister functions like clk_get_sys() and of_clk_get(). This changes the original behavior where the struct clk is only created for once when clock driver registers the clock to CCF in the first place. The net change here is before commit 035a61c3 the struct clk pointer is unique for given hardware clock, while after the commit the pointers returned by clk lookup calls become different for the same hardware clock. That said, the struct clk pointer comparing in the code doesn't work any more. Call helper function clk_is_match() instead to fix the problem. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NMichael Turquette <mturquette@linaro.org> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
-
- 11 3月, 2015 16 次提交
-
-
由 Takashi Iwai 提交于
Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the built-in mic NID 0x17 instead of NID 0x1d, and it results in the non-working mic. This patch just remaps the pin correctly via fixup. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=920604 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
When the sequencer driver is built in kernel, it may panic at boot because of the uninitialized snd_seq_bus_type. Initialize it properly via subsys_initcall() instead of module_init() to assure that the bus is registered beforehand. Reported-by: NFengguang Wu <fengguang.wu@intel.com> Fixes: 7c37ae5c ('ALSA: seq: Rewrite sequencer device binding with standard bus') Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NPaul Handrigan <Paul.Handrigan@cirrus.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
由 Takashi Iwai 提交于
The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Acked-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org>
-
- 10 3月, 2015 1 次提交
-
-
由 Takashi Iwai 提交于
The kernel memory allocators already report the errors when the requested allocation fails, thus we don't need to warn it again in each caller side. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-