- Apr 19, 2016
-
-
Takashi Iwai authored
Although one weird behavior about the input path (inconsistent D0/D3 switch) on Cirrus CS420x codecs was fixed in the previous commit, there is still an issue on some Mac machines: the capture stream stalls when switching the ADCs on the fly. More badly, this keeps stuck until the next reboot. The dynamic ADC switching is already a bit fragile and assuming optimistically that the chip accepts the frequent power changes. On Cirrus codecs, this doesn't seem applicable. As a quick workaround, we pin down the ADCs to keep up in D0 when spec->dyn_adc_switch is set. In this way, the ADCs are kept up only for the system that were confirmed to be broken. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171 Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
- Apr 18, 2016
-
-
Bastien Nocera authored
The Optiplex 9020m with Haswell-DT processor needs a quirk for the headset jack at the front of the machine to be able to use microphones. A quirk for this model was originally added in 31278997, but c77900e6 removed it in favour of a more generic version. Unfortunately, pin configurations can changed based on firmware/BIOS versions, and the generic version doesn't have any effect on newer versions of the machine/firmware anymore. With help from David Henningsson <diwic@ubuntu.com> Signed-off-by:
Bastien Nocera <hadess@hadess.net> Tested-by:
-
Libin Yang authored
Make sure per_pin is not NULL before using it. Fixes: 9b3dc8aa ('ALSA: hda - Register chmap obj as priv data instead of codec') Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
-
- Apr 17, 2016
-
-
Takashi Iwai authored
We've got a regression report that the recording on Mac with a cirrus codec doesn't work any longer. This turned out to be the missing power up to D0 by power_save_node enablement. After analyzing the traces, we found out that the culprit is that the codec advertises the "actual" power state of a few nodes to be D0 while the "target" power state is D3. This inconsistency is usually OK, as it implies the power transition. But in the case of cirrus codec, this seems to be stuck to D3 while it's not actually D0. This patch addresses the issue by checking the power state difference more strictly. It sends the power-state change verb unless both the target and the actual power states show the given value. We may introduce yet another flag indicating the possible broken hardware power state, but it's anyway safer to set the proper power state even in a transition (at least it's harmless as long as the target state is same). So this simpler change was applied now. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171 Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
-
- Apr 13, 2016
-
-
Takashi Iwai authored
While the previous commit fixed the missing monitor_present flag update, it may be still in an inconsistent state while the driver repolls: the flag itself is updated, but the eld_valid flag and the contents don't follow until the repoll finishes (and may be repeated for a few times). The basic problem is that pin_eld->monitor_present is updated in the caller side. This should have been updated only in update_eld(). So, the proper fix is to avoid accessing pin_eld but only spec->temp_eld. Signed-off-by: -
Hyungwon Hwang authored
The commit [bd481285: ALSA: hda - Fix forgotten HDMI monitor_present update] covered the missing update of monitor_present flag, but this caused a regression for devices without the i915 eld notifier. Since the old code supposed that pin_eld->monitor_present was updated by the caller side, the hdmi_present_sense_via_verbs() doesn't update the temporary eld->monitor_present but only pin_eld->monitor_present, which is now overridden in update_eld(). The fix is to update pin_eld->monitor_present as well before calling update_eld(). Note that this may still leave monitor_present flag in an inconsistent state when the driver repolls, but this is at least the old behavior. More proper fix will follow in the later patch. Fixes: bd481285 ('ALSA: hda - Fix forgotten HDMI monitor_present update') Signed-off-by:
Hyungwon Hwang <hyungwon.hwang7@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Apr 11, 2016
-
-
Sven Eckelmann authored
The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in order to get working sound output on the docking stations headphone jack. Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock on kernel 4.4.6. Signed-off-by:
Sven Eckelmann <sven@narfation.org> Tested-by:
Simon Wunderlich <sw@simonwunderlich.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Apr 01, 2016
-
-
Hui Wang authored
The front mic jack (pink color) can't detect any plug or unplug. After applying this fix, both detecting function and recording function work well. BugLink: https://bugs.launchpad.net/bugs/1564712 Cc: stable@vger.kernel.org Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
- Mar 31, 2016
-
-
Maruthi Srinivas Bayyavarapu authored
This commit fixes garbled audio on Polaris-10/11 variants Signed-off-by:
Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- Mar 23, 2016
-
-
Bobi Mihalca authored
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=115181 Signed-off-by:
Bobi Mihalca <bobbymihalca@touchtech.ro> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Bobi Mihalca authored
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=115181 Signed-off-by:
-
Bobi Mihalca authored
ASUS N750JV needs the same fixup as N550 for enabling its subwoofer. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181 Signed-off-by:
-
- Mar 21, 2016
-
-
Takashi Iwai authored
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:
-
- Mar 20, 2016
-
-
Takashi Iwai authored
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=94566 Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.5 Signed-off-by:
-
- Mar 18, 2016
-
-
Takashi Iwai authored
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:
-
Takashi Iwai authored
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: -
Takashi Iwai authored
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:
-
- Mar 17, 2016
-
-
Takashi Iwai authored
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:
-
- Mar 15, 2016
-
-
Takashi Iwai authored
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:
-
Takashi Iwai authored
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:
-
- Mar 14, 2016
-
-
Subhransu S. Prusty authored
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:
Andreas Reis <andreas.reis@gmail.com> Signed-off-by:
Subhransu S. Prusty <subhransu.s.prusty@intel.com> Tested-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Aaron Plattner authored
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:
Aaron Plattner <aplattner@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Mar 11, 2016
-
-
Hui Wang authored
This Lenovo ThinkCentre AIO also uses Line2 as mic mute button and uses GPIO2 to control the mic mute led, so applying this quirk can make both the button and led work. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1555912 Signed-off-by:
-
- Mar 10, 2016
-
-
Takashi Iwai authored
The current Intel HDMI codec driver supports only three fixed ports from port B to port D. However, i915 driver may assign a DP on other ports, e.g. port A, when no eDP is used. This incompatibility is caught later at pin_nid_to_pin_index() and results in a warning message like "HDMI: pin nid 4 not registered" at each time. This patch filters out such invalid events beforehand, so that the kernel won't be too grumbling. Reported-by:
Stefan Assmann <sassmann@kpanic.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
Just like CX20722, CX7024 codec also requires the power down at reboot in order to reduce the noise at reboot/shutdown. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=113511 Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Mar 07, 2016
-
-
Subhransu S. Prusty authored
Signed-off-by:
-
Subhransu S. Prusty authored
Chmap helpers, ops, controls are moved to core. Signed-off-by:
-
Subhransu S. Prusty authored
Chmap helper arguments are modified to use either hdac_device object or hdac_chmap object instead of codec specific object. With this moving these APIs to core will be easier. Helper added to access a specific channel_allocation object instead of directly accessing. Signed-off-by:
-
Subhransu S. Prusty authored
Add slot and channel count programming to hdmi_chmap object and move the chmap_ops to core. Use register_chmap_ops API to register for default ops. Override specific chmap ops in the driver. Signed-off-by:
-
Subhransu S. Prusty authored
Signed-off-by:
-
Subhransu S. Prusty authored
With this chmap object is added as private data and new ops are added to access driver specific chmap. Signed-off-by:
-
Subhransu S. Prusty authored
chmap object represents multichannel capability and contains chmap ops. Legacy driver is updated to use this. With next set of patches chmap object is moved to common to be reused by other drivers (ex: skylake ASoC hdmi driver). Signed-off-by:
-
- Mar 04, 2016
-
-
Libin Yang authored
Defer to register acomp eld notifier until hdmi audio driver is fully ready. After registering eld notifier, gfx driver can use this callback function to notify audio driver the monitor connection event. However this action may happen when audio driver is adding the pins or doing other initialization. This is not always safe, however. For example, using per_pin->lock before the lock is initialized. Let's register the eld notifier after the initialization is done. Signed-off-by:
-
Libin Yang authored
To make sure audio_ptr is set before intel_audio_codec_enable() or intel_audio_codec_disable() calling pin_eld_notify(), this patch adds wmb barrier to prevent optimizing. Signed-off-by:
-
- Mar 03, 2016
-
-
Simon South authored
This patch applies the microphone-related fix created for the Acer Aspire E1-572 to the E1-472 as well, as it uses the same Realtek ALC282 CODEC and demonstrates the same issues. This patch allows an external, headset microphone to be used and limits the gain on the (quite noisy) internal microphone. Signed-off-by:
Simon South <simon@simonsouth.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Mar 01, 2016
-
-
Libin Yang authored
hdmi_find_pcm_slot return -EBUSY when not no pcm slot found, not -ENODEV. So the caller should compare with -EBUSY. Fixes: a76056f2 ('ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug') Signed-off-by:
-
- Feb 26, 2016
-
-
Ville Syrjälä authored
azx_probe_continue() uses pm_runtime_put_noidle() to drop the rpm usage_count, which means that if it's the last reference the autosuspend of the controller won't actually happen. So if the codecs autosuspend before the azx_probe_continue() drops the last reference we'll fail to autosuspend the controller. This does happen in practice, but not every time. As can be seen in [1] the controller autosuspend attempt fails due to the usage_count when suspending the codecs. A bit later we see the the contoller usage_count dropping to zero without further attempts at autosuspend. Fix the problem by using pm_runtime_put_autosuspend() instead, which will kick off the autosuspend of the controller even if the codecs are already asleep. As can be seen in [2] the controller autosuspend still fails while suspending the codecs, but later on we see another autosuspend attempt after dropping the usage_count to 0. I was also a bit worried that there might still be a race between the controller autosuspend and the rest of the code in azx_probe_continue(). So I also tried replacing the the put_noidle() with put_sync_suspend(). No explosions occurred, so I'm somewhat satisfied that there are no serious problems in this area. [1] kworker/1:2-122 [001] .... 63.661310: __pm_runtime_suspend: hdaudioC0D0 usage_count 0 kworker/1:2-122 [001] d..2 63.661316: rpm_suspend: hdaudioC0D0 flags-d cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:2-122 [001] d..1 63.661317: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/1:2-122 [001] d..2 63.661332: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/1:1-72 [001] d..2 63.661543: rpm_suspend: hdaudioC0D0 flags-a cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:1-72 [001] d..1 63.661544: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/1:1-72 [001] .... 63.661545: hda_codec_runtime_suspend: hdaudioC0D0 suspend kworker/1:1-72 [001] d..2 63.661614: rpm_idle: 0000:00:03.0 flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:1-72 [001] d..1 63.661615: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1 kworker/1:1-72 [001] d..1 63.661615: rpm_check_suspend_allowed: 0000:00:03.0 retval -11 kworker/1:1-72 [001] d..2 63.661616: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11 kworker/1:1-72 [001] d..2 63.661616: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/1:2-122 [001] d..2 63.664834: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:2-122 [001] d..1 63.664835: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/1:2-122 [001] d..2 63.664836: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/1:2-122 [001] d..2 63.664841: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/1:2-122 [001] d..1 63.664841: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/1:2-122 [001] d..2 63.664841: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/1:2-122 [001] .... 63.664842: azx_probe_continue: 0000:00:03.0 usage_count=0 [2] kworker/0:0-4 [000] .... 50.354567: __pm_runtime_suspend: hdaudioC0D0 usage_count 0 kworker/0:0-4 [000] d..2 50.354574: rpm_suspend: hdaudioC0D0 flags-d cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.354575: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/0:0-4 [000] d..2 50.354589: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/0:2-135 [000] d..2 50.354809: rpm_suspend: hdaudioC0D0 flags-a cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:2-135 [000] d..1 50.354810: rpm_check_suspend_allowed: hdaudioC0D0 retval 0 kworker/0:2-135 [000] .... 50.354816: hda_codec_runtime_suspend: hdaudioC0D0 suspend kworker/0:2-135 [000] d..2 50.354908: rpm_idle: 0000:00:03.0 flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:2-135 [000] d..1 50.354909: rpm_check_suspend_allowed: 0000:00:03.0 usage_count 1 kworker/0:2-135 [000] d..1 50.354909: rpm_check_suspend_allowed: 0000:00:03.0 retval -11 kworker/0:2-135 [000] d..2 50.354909: rpm_return_int: rpm_idle+0x249/0x487:0000:00:03.0 ret=-11 kworker/0:2-135 [000] d..2 50.354910: rpm_return_int: rpm_suspend+0x406/0x5e8:hdaudioC0D0 ret=0 kworker/0:0-4 [000] d..2 50.373791: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.373792: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/0:0-4 [000] d..2 50.373793: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/0:0-4 [000] d..2 50.373797: rpm_idle: hdaudioC0D0 flags-8 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.373798: rpm_check_suspend_allowed: hdaudioC0D0 retval 1 kworker/0:0-4 [000] d..2 50.373798: rpm_return_int: rpm_idle+0x249/0x487:hdaudioC0D0 ret=-11 kworker/0:0-4 [000] .... 50.373799: __pm_runtime_suspend: 0000:00:03.0 usage_count 0 kworker/0:0-4 [000] d..2 50.373800: rpm_suspend: 0000:00:03.0 flags-d cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.373800: rpm_check_suspend_allowed: 0000:00:03.0 retval 0 kworker/0:0-4 [000] d..2 50.373803: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0 kworker/0:0-4 [000] d..2 50.385164: rpm_suspend: 0000:00:03.0 flags-a cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:0-4 [000] d..1 50.385165: rpm_check_suspend_allowed: 0000:00:03.0 retval 0 kworker/0:0-4 [000] .... 50.385174: azx_runtime_suspend: 0000:00:03.0 azx suspend releaseing power well kworker/0:0-4 [000] .... 50.385179: azx_runtime_suspend: 0000:00:03.0 azx suspend kworker/0:0-4 [000] d..2 50.386872: rpm_return_int: rpm_suspend+0x406/0x5e8:0000:00:03.0 ret=0 Signed-off-by:
-
Takashi Iwai authored
Currently the interrupt handler of HD-audio driver assumes that no irq update is needed while processing the irq. But in reality, it has been confirmed that the HW irq is issued even during the irq handling. Since we clear the irq status at the beginning, process the interrupt, then exits from the handler, the lately issued interrupt is left untouched without being properly processed. This patch changes the interrupt handler code to loop over the check-and-process. The handler tries repeatedly as long as the IRQ status are turned on, and either stream or CORB/RIRB is handled. For checking the stream handling, snd_hdac_bus_handle_stream_irq() returns a value indicating the stream indices bits. Other than that, the change is only in the irq handler itself. Reported-by:
-
- Feb 25, 2016
-
-
Takashi Iwai authored
HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic working. Also, it suffers from the loopback noise problem, so we should disable aamix path as well. Reported-by:
Derick Eddington <derick.eddington@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
David Henningsson authored
On one of the machines we enable, we found that the actual speaker volume did not always correspond to the volume set in alsamixer. This patch fixes that problem. This patch was orginally written by Kailang @ Realtek, I've rebased it to fit sound git master. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1549660 Co-Authored-By:
Kailang <kailang@realtek.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
