14 May, 2014
8 commits
-
The if condition here was supposed to return on error but the return
statement is missing. The effect is that the ->mixername is set to
"???" instead of "DT019X".Signed-off-by: Dan Carpenter
Signed-off-by: Takashi Iwai -
…t/broonie/sound into for-linus
ASoC: Intel fixes for v3.15
This is a relatively large batch of fixes for the newly added
Haswell/Baytrail drivers from Intel. It's a bit larger than is good for
this point in the cycle but it's all for a newly added driver so not so
worrying as it might otherwise be. Some of it's integration problems,
some of it's the sort of problem usually turned up in stress tests. -
…git/broonie/sound into for-linus
ASoC: Driver fixes for v3.15
A small set of driver fixes, nothing remarkable in itself or of any
relevance outside of the driver. -
…/broonie/sound into for-linus
ASoC: Core fixes for v3.15
A few things here:
- Fix the creation of spurious CODEC<->CODEC links which caused DAPM to
have audio paths which shouldn't be present causing spurious powerups
and potential audible issues for users.
- Ensure the suspend->off transition doesn't have spurious transitions
to prepare added to the sequence.
- Fix incorrect skipping of PCM suspension for active audio streams.
- Remove Timur Tabi from the CS4270 maintainers, Cirrus are now doing
this and Timur no longer has the boards that he was using. -
…fsl-esai', 'asoc/fix/fsl-spdif', 'asoc/fix/rcar', 'asoc/fix/tlv320aic31xx' and 'asoc/fix/wm8962' into asoc-linus
-
The register CLASS_D_CONTROL_1 is marked as volatile because it contains
a bit, DAC_MUTE, which is also mirrored in the ADC_DAC_CONTROL_1
register. This causes problems for the "Speaker Switch" control, which
will report an error if the CODEC is suspended because it relies on a
volatile register.To resolve this issue mark CLASS_D_CONTROL_1 as non-volatile and
manually keep the register cache in sync by updating both bits when
changing the mute status.Reported-by: Shawn Guo
Signed-off-by: Charles Keepax
Tested-by: Shawn Guo
Signed-off-by: Mark Brown
Cc: stable@vger.kernel.org -
Commit 10df350977b1 ("ASoC: Intel: Fix Audio DSP usage when IOMMU is
enabled.") caused following regression in Baytrail SST:baytrail-pcm-audio baytrail-pcm-audio: error: DMA alloc failed
baytrail-pcm-audio baytrail-pcm-audio: error: failed to load firmwareFix this by calling dma_coerce_mask_and_coherent() in sst_byt_init() with
the same dma_dev device what is now used in sst_fw_new() when allocating the
DMA buffer.Signed-off-by: Jarkko Nikula
Signed-off-by: Mark Brown
13 May, 2014
8 commits
-
Broadwell display controller has 3 stream DMA engines. DMA0 cannot update DMA
postion buffer properly while DMA1 and DMA2 can work well. So this patch masks
the buggy DMA0 by keeping it as opened.This is a tentative workaround, so keep the change small as Takashi suggested.
Signed-off-by: Mengdong Lin
Signed-off-by: Takashi Iwai -
Vendor ID 0x10de0071 is used by a yet-to-be-named GPU chip.
Signed-off-by: Aaron Plattner
Signed-off-by: Takashi Iwai -
According to Reference Manual -- ESAI Initialization chapter, as the
standard procedure of ESAI personal reset, the PCRC and PRRC registers
should be remained in its reset value and then configured after T/RCCR
and T/RCR configurations's done but before TE/RE's enabling.So this patch moves PCRC and PRRC settings to the end of hw_params().
Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown -
ESAI can only output EXTAL clock source directly. But for FSYS clock source,
ESAI can not output it without getting through PSR PM dividers.So this patch adds an extra check in the code.
Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown -
The range here from 1 to 16 is confined to FP divider only while the
sck_div indicates if the calculation contains PSR and PM dividers. So
for the case using PSR and PM since the sck_div is true, the range of
ratio would simply become bigger than 16.So this patch fixes the condition here and adds one line comments to
make the purpose here clear.Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown -
Currently when the DAPM context bias level is SUSPEND and the target bias level
is OFF dapm_pre_sequence_async() will first transition to PREPARE and
dapm_post_sequence_async() will then transition back from PREPARE to STANDBY and
then to OFF.This patch makes sure that dapm_pre_sequence_async() only transitions to PREPARE
when either going to ON or away from ON. This avoids the extra unnecessary
transitions.Signed-off-by: Lars-Peter Clausen
Signed-off-by: Mark Brown -
For CODEC to CODEC DAI links the paths are created in snd_soc_dapm_new_pcm().
Also for CODEC to CODEC links the widgets are connected cross-over via a DAI
link widget, meaning that the capture widget of one CODEC will be connected to
the playback widget of the other and vice versa. Whereas
snd_soc_dapm_connect_dai_link_widgets() directly connects the playback widget of
the CPU DAI to the playback widget of the CODEC DAI and the capture widget of
the CPU DAI to the capture widget of the CODEC DAI. So not skipping
CODECCODEC links in snd_soc_dapm_connect_dai_link_widgets() will create
incorrect connections between the two CODECs which will cause DAPM to detect
active paths where there are none and unnecessarily power up widgets.Fixes: b893ea5 ("ASoC: sapm: Automatically connect DAI link widgets in DAPM graph.")
Cc: (for 3.14+)
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Mark Brown -
The regular state before we execute SNDRV_PCM_TRIGGER_SUSPEND should be
SNDRV_PCM_TRIGGER_START, not SNDRV_PCM_TRIGGER_STOP. Thus fix it.Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown
09 May, 2014
1 commit
-
When we plug a 3-ring headset on the Dell machines (VID: 0x10ec0255,
SID: 0x1028065c; VID: 0x10ec0255, SID: 0x10280680; VID: 0x10ec0292,
SID: 0x10280684), the headset mic can't be detected, after apply this
patch, the headset mic can work well.And on the machine with SID 0x10280684, and the Lineout and external
microphone should be routed to docking, this patch also fix this
problem.BugLink: https://bugs.launchpad.net/bugs/1297581
Cc: David Henningsson
Cc: stable@vger.kernel.org
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
07 May, 2014
1 commit
-
Block offset calculations are done in the contiguous allocator so
are not required here.Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown
06 May, 2014
1 commit
-
This patch fixes the following dereference check ordering.
sound/soc/intel/sst-haswell-pcm.c:749 hsw_pcm_probe() warn: variable dereferenced before check 'pdata' (see line 746)
git remote add asoc git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
git remote update asoc
git checkout 0b708c87f66a15190fb43661c2320fd48c4dc6c8
vim +/pdata +749 sound/soc/intel/sst-haswell-pcm.ca4b12990 Mark Brown 2014-03-12 740 };
a4b12990 Mark Brown 2014-03-12 741
a4b12990 Mark Brown 2014-03-12 742 static int hsw_pcm_probe(struct snd_soc_platform *platform)
a4b12990 Mark Brown 2014-03-12 743 {
a4b12990 Mark Brown 2014-03-12 744 struct sst_pdata *pdata = dev_get_platdata(platform->dev);
a4b12990 Mark Brown 2014-03-12 745 struct hsw_priv_data *priv_data;
0b708c87 Liam Girdwood 2014-05-02 @746 struct device *dma_dev = pdata->dma_dev;
0b708c87 Liam Girdwood 2014-05-02 747 int i, ret = 0;
a4b12990 Mark Brown 2014-03-12 748
a4b12990 Mark Brown 2014-03-12 @749 if (!pdata)
a4b12990 Mark Brown 2014-03-12 750 return -ENODEV;
a4b12990 Mark Brown 2014-03-12 751
a4b12990 Mark Brown 2014-03-12 752 priv_data = devm_kzalloc(platform->dev, sizeof(*priv_data), GFP_KERNEL);Reported-by: Dan Carpenter
Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown
05 May, 2014
1 commit
-
Since commit 1df5a06a ("ALSA: hda - hdmi: Fix programmed active channel
count") channel count is no longer being set if monitor_present is 0.
This is because setting the count was moved after the CA value is
determined, which is only after the monitor_present check in
hdmi_setup_audio_infoframe().Unfortunately, in some cases, such as with a non-spec-compliant codec or
with a problematic video driver, monitor_present is always 0. As a
specific example, this seems to happen with gen1 ATV (SiI1390 codec),
causing left-channel-only stereo playback (multi-channel playback has
apparently never worked with this codec despite it reporting 8 channels,
reason unknown).Simply setting converter channel count without setting the pin infoframe
and channel mapping as well does not theoretically make much sense as
this will just mean they are out-of-sync and multichannel playback will
have a wrong channel mapping.However, adding back just setting the converter channel count even in
no-monitor case is the safest change which at least fixes the stereo
playback regression on SiI1390 codec. Do that.Signed-off-by: Anssi Hannula
Reported-by: Stephan Raue
Tested-by: Stephan Raue
Cc: # 3.12+
Signed-off-by: Takashi Iwai
03 May, 2014
10 commits
-
Read the stream offset and presentation position from DSP memory rather
than using the old estimated position. This fixes timing issues with
pulseaudio.Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown -
hw_params() can be called multiple times. Make sure we release the DSP
stream that was allocated on previous hw_params() calls before allocating
a new DSP stream.Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown -
The Intel IOMMU requires that the ACPI device is used to allocate all
DMA memory buffers. This means we need to pass the DMA device pointer into child
component devices that allocate DMA memory.We also only set the DMA mask for the ACPI device now instead of for each
component device.Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown -
Fix page table creation on Haswell and Broadwell to remove unsafe
virt_to_phys mappings and use more portable SG buffer. Use audio buffer
APIs to allocate DMA buffers.Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown -
Make sure we add the allocated blocks to the modules list of blocks.
Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown -
Make sure we dont alloc blocks twice with requests spanning more
than one block.Signed-off-by: Liam Girdwood
Signed-off-by: Mark Brown -
The TEAC UD-H01 firmware sends wrong feedback frequency values, thus
causing the PC to send the samples at a wrong rate, which results in
clicks and crackles in the output.Add a workaround to detect and fix the corruption.
Signed-off-by: Clemens Ladisch
[mick37@gmx.de: use sender->udh01_fb_quirk rather than
ep->udh01_fb_quirk in snd_usb_handle_sync_urb()]
Reported-and-tested-by: Mick
Reported-and-tested-by: Andrea Messa
Cc:
Signed-off-by: Takashi Iwai -
The recent addition of the USB audio mixer suspend/resume may lead to
deadlocks when the driver tries to call usb_autopm_get_interface()
recursively, since the function tries to sync with the finish of the
other calls. For avoiding it, introduce a flag indicating the resume
operation and avoids the recursive usb_autopm_get_interface() calls
during the resume.Reported-and-tested-by: Bryan Quigley
Signed-off-by: Takashi Iwai -
The suspend callback of usb-audio driver may be called multiple times
per suspend when multiple USB interfaces are bound to a single sound
card instance. In such a case, it's superfluous to save the mixer
values multiple times. This patch fixes it by checking the counter.Signed-off-by: Takashi Iwai
-
This (widely used) construction:
if(printk_ratelimit())
dev_dbg()Causes the ratelimiting to spam the kernel log with the "callbacks suppressed"
message below, even while the dev_dbg it is supposed to rate limit wouldn't
print anything because DEBUG is not defined for this device.[ 533.803964] retire_playback_urb: 852 callbacks suppressed
[ 538.807930] retire_playback_urb: 852 callbacks suppressed
[ 543.811897] retire_playback_urb: 852 callbacks suppressed
[ 548.815745] retire_playback_urb: 852 callbacks suppressed
[ 553.819826] retire_playback_urb: 852 callbacks suppressedSo use dev_dbg_ratelimited() instead of this construction.
Signed-off-by: Sander Eikelenboom
Signed-off-by: Takashi Iwai
30 Apr, 2014
2 commits
-
When we plug a 3-ring headset on the Dell machine (VID: 0x10ec0255,
SID: 0x1028067e), the headset mic can't be detected, after apply this
patch, the headset mic can work well.BugLink: https://bugs.launchpad.net/bugs/1297581
Cc: David Henningsson
Cc: stable@vger.kernel.org
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai -
The recent commit (ca460f86521) changed the CORB RP reset procedure to
follow the specification with a couple of sanity checks.
Unfortunately, Nvidia controller chips seem not following this way,
and spew the warning messages like:
snd_hda_intel 0000:00:10.1: CORB reset timeout#1, CORBRP = 0This patch adds the workaround for such chips. It just skips the new
reset procedure for the known broken chips.Signed-off-by: Takashi Iwai
28 Apr, 2014
1 commit
-
When we plug a 3-ring headset on the Dell machine (VID: 0x10ec0255,
SID: 0x10280674), the headset mic can't be detected, after apply this
patch, the headset mic can work well.BugLink: https://bugs.launchpad.net/bugs/1297581
Cc: David Henningsson
Cc: stable@vger.kernel.org
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
25 Apr, 2014
1 commit
-
Use a newline character appropriately.
Signed-off-by: Joe Perches
Signed-off-by: Mark Brown
24 Apr, 2014
2 commits
-
I suppose there is a possibility that hsw_notification_work() may run after
sst_hsw_stream_free() which can lead to a kernel crash since struct
sst_hsw_stream is freed at that point and
stream = container_of(work, struct sst_hsw_stream, notify_work) is not valid
when hsw_notification_work() is run.Reported-by: Derek Basehore
Reported-by: Wenkai Du
Signed-off-by: Jarkko Nikula
Signed-off-by: Mark Brown -
audmux_debugfs_init() is marked as __init, but is called from imx_audmux_probe()
which is not marked as __init. This creates a section mismatch and a potential
runtime crash (if imx_audmux_probe() is called after the .init section was
dropped). This patch removes the __init annotation from audmux_debugfs_init(),
which fixes the following warning:
WARNING: sound/soc/built-in.o(.text+0x86960): Section mismatch in reference
from the function imx_audmux_probe() to the function
.init.text:audmux_debugfs_init()Signed-off-by: Lars-Peter Clausen
Signed-off-by: Mark Brown
23 Apr, 2014
4 commits
-
rsnd_soc_dai_trigger() will be called
after rsnd_dai_pointer_update() function
which is using rsnd_lock().
Thus, it should be called from outside of rsnd_lock().
Kernel will be hangup without this patch.
Special thanks to Kataoka-sanReported-by: Ryo Kataoka
Signed-off-by: Kuninori Morimoto
Signed-off-by: Mark Brown -
There is a race between sst_byt_stream_free() and sst_byt_get_stream()
if sst_byt_get_stream() called from sst_byt_irq_thread() context is
accessing the byt->stream_list while a stream is deleted from the list.A stream is added to byt->stream_list in sst_byt_stream_new() and deleted in
sst_byt_stream_free(). sst_byt_get_stream() is always protected by
sst->spinlock, but the stream addition and deletion are not protected.The patch adds spinlock to both stream addition and deletion.
[Jarkko: Same fix added to sst-haswell-ipc.c too]
Signed-off-by: Wenkai Du
Signed-off-by: Jarkko Nikula
Signed-off-by: Mark Brown -
…ar', 'asoc/fix/tlv320aic31xx' and 'asoc/fix/tlv320aic3x' into asoc-linus
-
…/cs42l73' and 'asoc/fix/fsl-spdif' into asoc-linus
