- 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 3 次提交
-
-
由 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 提交于
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 15 次提交
-
-
由 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 提交于
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 2 次提交
-
-
由 Takashi Sakamoto 提交于
With previous commit, this module managed to leave the counting to each drivers, but the isochronous resources functionality still increment/decrement the count. This commit purge such codes to leave the responsibility to each drivers. Fix: c6f224dc ('ALSA: firewire-lib: remove reference counting') Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Sakamoto 提交于
This reverts commit 8cdebf71. The reverted commit breaks out-stream functionality of Dice driver. Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 09 3月, 2015 2 次提交
-
-
由 Takashi Iwai 提交于
The commit [63e51fd7: ALSA: hda - Don't take unresponsive D3 transition too serious] introduced a conditional fallback behavior to the HD-audio controller depending on the flag set. However, it introduced a silly bug, too, that the flag was evaluated in a reverse way. This resulted in a regression of HD-audio controller driver where it can't go to the fallback mode at communication errors. Unfortunately (or fortunately?) this didn't come up until recently because the affected code path is an error handling that happens only on an unstable hardware chip. Most of recent chips work stably, thus they didn't hit this problem. Now, we've got a regression report with a VIA chip, and this seems indeed requiring the fallback to the polling mode, and finally the bug was revealed. The fix is a oneliner to remove the wrong logical NOT in the check. (Lesson learned - be careful about double negation.) The bug should be backported to stable, but the patch won't be applicable to 3.13 or earlier because of the code splits. The stable fix patches for earlier kernels will be posted later manually. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021 Fixes: 63e51fd7 ('ALSA: hda - Don't take unresponsive D3 transition too serious') Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Lars-Peter Clausen 提交于
Any access to the component_list, codec_list and platform_list needs to be properly locked by the client_mutex. Otherwise undefined behavior can occur if the list is modified in one thread and concurrently accessed from another thread. This patch adds the missing locking to the debugfs file handlers that display the registered components, as well as the various components unregister functions. Furthermore the client_lock is now held for the whole snd_soc_instantiate_card() sequence to make sure that component removal does not race against the card registration. Reported-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 07 3月, 2015 3 次提交
-
-
由 Lu, Han 提交于
Details: 1. Unload all modules on fw_list of dsp when suspend, and reload all modules on fw_list when resume. 2. A DSP expects only one scratch, but hsw_parse_fw_image() allocates scratch blocks for each firmware image it parses. Move the allocate function sst_block_alloc_scratch() out of hsw_parse_fw_image() to make sure a scratch be allocated only after all firmware images be parsed. Signed-off-by: NLu, Han <han.lu@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Bard Liao 提交于
The board ID will be changed between revisions. So, it is better to map it by project name. Signed-off-by: NBard Liao <bardliao@realtek.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Eric Nelson 提交于
The SGTL5000_CHIP_ANA_POWER register is cached. Update the cached value instead of writing it directly. Patch inspired by Russell King's more colorful remarks in this patch: https://github.com/SolidRun/linux-imx6-3.14/commit/dd4bf6aSigned-off-by: NEric Nelson <eric.nelson@boundarydevices.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 06 3月, 2015 2 次提交
-
-
由 Hui Wang 提交于
Cc: <stable@vger.kernel.org> BugLink: https://bugs.launchpad.net/bugs/1428947Signed-off-by: NHui Wang <hui.wang@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Dan Carpenter 提交于
There is a missing lower bound check on "pitchbend" so it means we can read up to 6 elements before the start of the opl3_note_table[] array. Thanks to Clemens Ladisch for his help with this patch. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 05 3月, 2015 8 次提交
-
-
由 Nicolin Chen 提交于
According to i.MX6 Series Reference Manual, the formula to calculate the sys clock is sysclk rate = bclk rate * (div2 + 1) * (7 * psr + 1) * (pm + 1) * 2 Commit aafa85e7 ("ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series") added the divisor calculation which relies on the clk_round_rate(). However, at that time, clk_round_rate() didn't provide closest clock rates for some cases because it might not use a correct rounding policy. So using the original formula (pm + 1) for PM divisor was not able to give us a desired clock rate. And then we used (pm + 2) to do the trick. However, the clk-divider driver has been refined a lot since commit b11d282d ("clk: divider: fix rate calculation for fractional rates") Now using (pm + 2) trick would result an incorrect clock rate. So this patch fixes the problem by removing the useless trick. Reported-by: NStephane Cerveau <scerveau@voxtok.com> Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Takashi Iwai 提交于
The usages of clamp() macro in sound/usb/line6/playback.c are just wrong, the low and high values are swapped. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Dan Carpenter 提交于
There were some curly braces intended here. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Maciej S. Szmigiero 提交于
of_property_read_u32_array returns 0 on success, so the return value shouldn't be inverted twice, first on assignment then in condition expression. Signed-off-by: NMaciej Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Routes without a control must use NULL for the control name. The sn95031 driver uses "NULL" instead in a few places. Previous to commit 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the sn95031 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Acked-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
由 Lars-Peter Clausen 提交于
Routes without a control must use NULL for the control name. The da732x driver uses "NULL" instead in a few places. Previous to commit 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the da732x driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Acked-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
由 Lars-Peter Clausen 提交于
Routes without a control must use NULL for the control name. The ak4671 driver uses "NULL" instead in a few places. Previous to commit 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the ak4671 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
由 Peter Ujfalusi 提交于
DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be set to 32. The 64 was introduced by commit (in 2009): a152ff24 ASoC: OMAP: Make DMA 64 aligned But the dma_mask and coherent_dma_mask can not be used to specify alignment. Fixes: a152ff24 (ASoC: OMAP: Make DMA 64 aligned) Reported-by: NGrygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-