- 28 3月, 2016 8 次提交
-
-
由 Takashi Iwai 提交于
Since we have the fixed pin-port mapping for Intel IronLake (IbexPeak) and Baytrail (ValleyView) platforms in the code side, now it's time to add the support in the codec driver side. This patch simply enables the i915 ELD notifier for these in addition with the fix of the mapping from the port to NID in the callback. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Intel IronLake and ValleyView platforms have different HDMI widget pin and digital port mapping from other newer ones. The recent ones (HSW+) have NID 0x05 to 0x07 for port B to port D, while these chips have NID 0x04 to 0x06. For adapting this mapping, pass the codec object instead of the bus object to snd_hdac_sync_audio_rate() and snd_hdac_acomp_get_eld() so that they can check the codec ID and calculate the mapping properly. The changes in the HDMI codec driver side will follow in the later patch. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Intel SandyBridge and IvyBridge (CougarPoint and PantherPoint platforms) have also the same digital port vs audio widget mapping (from port B = NID 0x05 to port D = NID 0x07) as Haswell & co. So, we can reuse the existing functions for HSW+ for these platforms without changing there, but just by re-adding the on-demand i915 binding in HDMI codec driver. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
For reducing the splat of is_haswell_plus() or such macros, this patch introduces pin_cvt_fixup() ops to hdmi_spec. For HSW+ and VLV+ codecs, set this ops so that the driver can call the Intel-specific workarounds appropriately. A gratis bonus that we can remove the mux_id argument from hdmi_choose_cvt(), too, since the fixup function always refers the mux_idx from the given per_pin object. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Instead of checking at each time with is_haswell_plus() macro, override the setup_stream ops itself for HSW+ chips. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
The need for reprogramming the AMP mute bit at each audio info frame setup isn't always specific to Intel chips. It's safer to set it generically for all codecs with the amp bit, as this verb execution itself isn't too much load. This eliminates one usage of is_haswell_plus() macro, after all. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
We have too many Intel-specific codes in patch_hdmi_generic() despite its function name. And this makes it difficult to adjust per chipset, e.g. for allowing the audio notifier on an old chipset, one would need to add an explicit if() check. This patch attempts some code refactoring and cleanups in this regard; the Intel-specific codes are moved out of patch_generic_hdmi() into the new functions, patch_i915_hsw_hdmi() and patch_i915_byt_hdmi(), depending on the chipset. The other old Intel chipsets keep using patch_generic_hdmi() without Intel hacks. The existing patch_generic_hdmi() is also split to a few components so that they can be called from the Intel codec parsers. There are still many is_haswell*() and is_valleyview*() macro usages in the code. They will be cleaned up later. For the time being, only the entry are concerned. Along with this change, the i915_bound flag and the on-demand i915 component binding have been removed as a cleanup, since there is no user at this moment. This will be added back later once when Cougar Point and else start using the i915 eld notifier. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Sakamoto 提交于
When sound card is going to be released, dice private data is also released. Then all of data should be released. However, stream data is not released. This causes memory leak when unplugging dice unit. This commit fixes the bug. Fixes: 4bdc495c('ALSA: dice: handle several PCM substreams when any isochronous streams are available') Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 23 3月, 2016 4 次提交
-
-
由 Bobi Mihalca 提交于
Apply the new fixup that is used for ASUS N750JV to another similar model, N500JV, too, for reducing the headphone noise. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: NBobi Mihalca <bobbymihalca@touchtech.ro> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Bobi Mihalca 提交于
For reducing the noise from the headphone output on ASUS N750JV, call the existing fixup, alc_fixup_auto_mute_via_amp(), additionally. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: NBobi Mihalca <bobbymihalca@touchtech.ro> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Bobi Mihalca 提交于
ASUS N750JV needs the same fixup as N550 for enabling its subwoofer. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: NBobi Mihalca <bobbymihalca@touchtech.ro> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Sakamoto 提交于
'struct snd_timer_gparams' includes some members with 'unsigned long', therefore its size differs depending on data models of architecture. As a result, x86/x32 applications fail to execute ioctl(2) with SNDRV_TIMER_GPARAMS command on x86_64 machine. This commit fixes this bug by adding a pair of structure and ioctl command for the compatibility. Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 21 3月, 2016 1 次提交
-
-
由 Takashi Iwai 提交于
i915 get_eld ops may return an error when no encoder is connected, and currently we regard the error as fatal and skip the whole ELD handling. This ended up with the missing ELD update at unplugging. This patch fixes the issue by treating the error as the unplugged state, instead of skipping the rest. Reported-by: NLibin Yang <libin.yang@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.5 Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 20 3月, 2016 2 次提交
-
-
由 Victor Clément 提交于
The Microsoft HD-5001 webcam microphone does not support sample rate reading as the HD-5000 one. This results in dmesg errors and sound hanging with pulseaudio. Signed-off-by: NVictor Clément <victor.clement@openmailbox.org> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
The recent addition of on-demand i915 audio component binding in the codec driver seems leading to the unbalanced i915 power refcount, according to Intel CI tests. Typically, it gets a kernel WARNING like: WARNING: CPU: 3 PID: 173 at sound/hda/hdac_i915.c:91 snd_hdac_display_power+0xf1/0x110 [snd_hda_core]() Call Trace: [<ffffffff813fef15>] dump_stack+0x67/0x92 [<ffffffff81078a21>] warn_slowpath_common+0x81/0xc0 [<ffffffff81078b15>] warn_slowpath_null+0x15/0x20 [<ffffffffa00f77e1>] snd_hdac_display_power+0xf1/0x110 [snd_hda_core] [<ffffffffa015039d>] azx_intel_link_power+0xd/0x10 [snd_hda_intel] [<ffffffffa011e32a>] azx_link_power+0x1a/0x30 [snd_hda_codec] [<ffffffffa00f21f9>] snd_hdac_link_power+0x29/0x40 [snd_hda_core] [<ffffffffa01192a6>] hda_codec_runtime_suspend+0x76/0xa0 [snd_hda_codec] ..... The scenario is like below: - HD-audio driver and i915 driver are probed concurrently at the (almost) same time; HDA bus tries to bind with i915, but it fails because i915 initialization is still being processed. - Later on, HD-audio probes the HDMI codec, where it again tries to bind with i915. At this time, it succeeds. - At finishing the probe of HDA, it decreases the refcount as if it were already bound at the bus probe, since the component is bound now. This triggers a kernel WARNING due to the unbalance. As a workaround, in this patch, we just disable the on-demand i915 component binding in the codec driver. This essentially reverts back to the state of 4.4 kernel. We know that this is no real solution, but it's a minimalistic simple change that can be applied to 4.5.x kernel as stable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94566Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.5 Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 19 3月, 2016 2 次提交
-
-
由 Takashi Iwai 提交于
snd_hdac_sync_audio_rate() call is mandatory only for HSW and later models, but we call the function unconditionally blindly assuming that the function doesn't do anything harmful. But since recently, the function checks the validity of the passed pin NID, and eventually spews the warning if an unexpected pin is passed. This is seen on old chips like Baytrail. The fix is to limit the call of this function again only for the chips with the proper binding. This can be identified by the same flag as the eld notifier. Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.5 Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
We forgot to copy monitor_present value when updating the ELD information. This won't change the ELD retrieval and the jack notification behavior, but appears only in the proc output. In that sense, it's no fatal error, but a bug is a bug is a bug. Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 18 3月, 2016 2 次提交
-
-
由 Takashi Iwai 提交于
The commit [b62232d4: ALSA: hda - Limit i915 HDMI binding only for HSW and later] tried to limit the usage of i915 audio notifier to the recent Intel models and switch to the old method on pre-Haswell models. However, it assumed that the i915 component binding hasn't been done on such models, and the assumption was wrong: namely, Baytrail had already the i915 component binding due to powerwell control. Thus, the workaround wasn't applied to Baytrail. For fixing this properly, this patch introduces a new flag indicating the usage of audio notifier and codec_has_acomp() refers to this flag instead of checking the existence of audio component. Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.5 Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Joonsoo Kim 提交于
We can disable debug_pagealloc processing even if the code is compiled with CONFIG_DEBUG_PAGEALLOC. This patch changes the code to query whether it is enabled or not in runtime. [akpm@linux-foundation.org: export _debug_pagealloc_enabled to modules] Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com> Acked-by: NDavid Rientjes <rientjes@google.com> Acked-by: NTakashi Iwai <tiwai@suse.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Chris Metcalf <cmetcalf@ezchip.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 3月, 2016 2 次提交
-
-
由 Takashi Iwai 提交于
The recent change in HD-audio HDMI/DP codec driver for allowing the dynamic PCM binding introduced a new spec->pcm_mutex. One of the protected area by this mutex is hdmi_present_sense(). As reported by Intel CI tests, unfortunately, the new mutex causes a deadlock when the hotplug/unplug is triggered during the codec is in runtime suspend. The buggy code path is like the following: hdmi_unsol_event() -> ... -> hdmi_present_sense() ==> ** here taking pcm_mutex -> hdmi_present_sense_via_verbs() -> snd_hda_power_up_pm() -> ... (runtime resume calls) -> generic_hdmi_resume() -> hdmi_present_sense() ==> ** here taking pcm_mutex again! As we can see here, the problem is that the mutex is taken before snd_hda_power_up_pm() call that triggers the runtime resume. That is, the obvious solution is to move the power up/down call outside the mutex; it is exactly what this patch provides. The patch also clarifies why this bug wasn't caught beforehand. We used to have the i915 audio component for hotplug for all Intel chips, and in that code path, there is no power up required but the information is taken directly from the graphics side. However, we recently switched back to the old method for some old Intel chips due to regressions, and now the deadlock issue is surfaced. Fixes: a76056f2 ('ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug') Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Sakamoto 提交于
ALSA: ctl: change return value in compatibility layer so that it's the same value in core implementation In control compatibility layer, when no elements are found by ELEM_READ/ELEM_WRITE ioctl commands, ENXIO is returned. On the other hand, in core implementation, ENOENT is returned. This is not good for ALSA ctl applications. This commit changes the return value from the compatibility layer so that the same value is returned. Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 16 3月, 2016 5 次提交
-
-
由 Dan Carpenter 提交于
We could print the uninitialized value of "stat" in the error message. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Add some sanity check codes before actually accessing the endpoint via get_endpoint() in order to avoid the invalid access through a malformed USB descriptor. Mostly just checking bNumEndpoints, but in one place (snd_microii_spdif_default_get()), the validity of iface and altsetting index is checked as well. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Just a minor code cleanup: unify the error paths. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
create_fixed_stream_quirk() may cause a NULL-pointer dereference by accessing the non-existing endpoint when a USB device with a malformed USB descriptor is used. This patch avoids it simply by adding a sanity check of bNumEndpoints before the accesses. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
It turned out that the pre-HSW Intel chips are incompatible with the naive assumption we had -- the fixed mapping between the port and the HD-audio widget. This may result in the bad access, as captured by the recent patch to add a WARN_ON() for the port mapping check. As a quick workaround, disable the i915 audio component binding for all pre-Haswell models. Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.5 Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 15 3月, 2016 2 次提交
-
-
由 Takashi Iwai 提交于
Cirrus HD-audio driver may adjust GPIO pins for EAPD dynamically depending on the jack plug state. This works fine for the auto-mute mode where the speaker gets muted upon the HP jack plug. OTOH, when the auto-mute mode is off, this turns off the EAPD unexpectedly depending on the jack state, which results in the silent speaker output. This patch fixes the silent speaker output issue by setting GPIO bits constantly when the auto-mute mode is off. Reported-and-tested-by: moosotc@gmail.com Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Dan Carpenter 提交于
We print can print the uninitialized memory on error. Which is an info leak, I suppose but it's basically harmless. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 14 3月, 2016 3 次提交
-
-
由 Subhransu S. Prusty 提交于
nvhdmi_chmap_cea_alloc_validate_get_type calls itself recursively using chmap ops causing the double fault. Fixed by adding the default validate_get_type handling inside nvdia validate_get_type handler. Link: https://bugzilla.kernel.org/show_bug.cgi?id=114311 Fixes: 67b90cb8 ("ALSA: hda - Create common chmap object") Reported-by: NAndreas Reis <andreas.reis@gmail.com> Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com> Tested-by: NAndreas Reis <andreas.reis@gmail.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41 will often fail, so add a quirk entry to fix it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087 Cc: <stable@vger.kernel.org> Signed-off-by: NVittorio Gambaletta <linuxbugs@vittgam.net> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Aaron Plattner 提交于
Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip. This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is appropriate here. Signed-off-by: NAaron Plattner <aplattner@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 12 3月, 2016 9 次提交
-
-
由 Kuninori Morimoto 提交于
Renesas sound driver user needs to read its datasheet when create DT. But it is difficult to understand, because it has many modules (SRC/CTU/MIX/DVC/SSIU/SSI/AudioDMAC/AudioDMACperiperi), and many features (Asynchronous/Synchronous mode on SRC, CTU matrix, DVC volume settings feature, Multi-SSI/TDM-SSI, etc). This patch adds simplified explanation to help setting/understanding. Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Jeeja KP 提交于
Broxton HDMI codec is similar to Skylake so add the device ID Signed-off-by: NJeeja KP <jeeja.kp@intel.com> Signed-off-by: NGuruprasadX Pawse <guruprasadx.pawse@intel.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Senthilnathan Veppur 提交于
Broxton is an Intel SoC which sports a DSP and system is quite like Skylake. So add this ID in Skylake driver Signed-off-by: NSenthilnathan Veppur <senthilnathanx.veppur@intel.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Jeeja KP 提交于
The code loading for Skylake and other platforms is different, so add a dsp_ops and a loader_ops which can be defined for each platform. Move the dsp init, cleanup and loader ops (alloc and free dma) to these ops Signed-off-by: NJeeja KP <jeeja.kp@intel.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Jeeja KP 提交于
Broxton uses HDA DMA so needs to keep dmab in the driver context so add it Signed-off-by: NGuruprasadX Pawse <guruprasadx.pawse@intel.com> Signed-off-by: NJeeja KP <jeeja.kp@intel.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Jayachandran B 提交于
The function skl_dsp_enable_core will be called by other parts of driver so this can no longer be a static function. Signed-off-by: NJayachandran B <jayachandran.b@intel.com> Signed-off-by: NGuruprasadX Pawse <guruprasadx.pawse@intel.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Vinod Koul 提交于
Some double whitespaces issues existed in driver, so fix them up. Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Vinod Koul 提交于
The module ID defines are common to other platforms so can be reused if moved to a common driver header so move it Signed-off-by: NJeeja KP <jeeja.kp@intel.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Peter Ujfalusi 提交于
DRA7xx family is compatible with the OMAP5 HDMI. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-