- 16 9月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
[ Upstream commit 2756d9143aa517b97961e85412882b8ce31371a6 ] It turned out that the recent Intel HD-audio controller chips show a significant stall during the system PM resume intermittently. It doesn't happen so often and usually it may read back successfully after one or more seconds, but in some rare worst cases the driver went into fallback mode. After trial-and-error, we found out that the communication stall seems covered by issuing the sync after each verb write, as already done for AMD and other chipsets. So this patch enables the write-sync flag for the recent Intel chips, Skylake and onward, as a workaround. Also, since Broxton and co have the very same driver flags as Skylake, refer to the Skylake driver flags instead of defining the same contents again for simplification. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901Reported-and-tested-by: NTodd Brandt <todd.e.brandt@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 25 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
commit de768ce45466f3009809719eb7b1f6f5277d9373 upstream. MSI MPG X570 board is with another AMD HD-audio controller (PCI ID 1022:1487) and it requires the same workaround applied for X370, etc (PCI ID 1022:1457). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 8月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
commit c02f77d32d2c45cfb1b2bb99eabd8a78f5ecc7db upstream. A long-time problem on the recent AMD chip (X370, X470, B450, etc with PCI ID 1022:1457) with Realtek codecs is the crackled or distorted sound for capture streams, as well as occasional playback hiccups. After lengthy debugging sessions, the workarounds we've found are like the following: - Set up the proper driver caps for this controller, similar as the other AMD controller. - Correct the DMA position reporting with the fixed FIFO size, which is similar like as workaround used for VIA chip set. - Even after the position correction, PulseAudio still shows mysterious stalls of playback streams when a capture is triggered in timer-scheduled mode. Since we have no clear way to eliminate the stall, pass the BATCH PCM flag for PA to suppress the tsched mode as a temporary workaround. This patch implements the workarounds. For the driver caps, it defines a new preset, AXZ_DCAPS_PRESET_AMD_SB. It enables the FIFO- corrected position reporting (corresponding to the new position_fix=6) and enforces the SNDRV_PCM_INFO_BATCH flag. Note that the current implementation is merely a workaround. Hopefully we'll find a better alternative in future, especially about removing the BATCH flag hack again. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 6月, 2019 1 次提交
-
-
由 Bard Liao 提交于
[ Upstream commit fa763f1b2858752e6150ffff46886a1b7faffc82 ] We observed the same issue as reported by commit a8d7bde2 ("ALSA: hda - Force polling mode on CFL for fixing codec communication") We don't have a better solution. So apply the same workaround to CNL. Signed-off-by: NBard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 15 6月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
[ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ] Currently the IRQ handler in HD-audio controller driver is registered before the chip initialization. That is, we have some window opened between the azx_acquire_irq() call and the CORB/RIRB setup. If an interrupt is triggered in this small window, the IRQ handler may access to the uninitialized RIRB buffer, which leads to a NULL dereference Oops. This is usually no big problem since most of Intel chips do register the IRQ via MSI, and we've already fixed the order of the IRQ enablement and the CORB/RIRB setup in the former commit b61749a8 ("sound: enable interrupt after dma buffer initialization"), hence the IRQ won't be triggered in that room. However, some platforms use a shared IRQ, and this may allow the IRQ trigger by another source. Another possibility is the kdump environment: a stale interrupt might be present in there, the IRQ handler can be falsely triggered as well. For covering this small race, let's move the azx_acquire_irq() call after hda_intel_init_chip() call. Although this is a bit radical change, it can cover more widely than checking the CORB/RIRB setup locally in the callee side. Reported-by: NLiwei Song <liwei.song@windriver.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
- 17 4月, 2019 1 次提交
-
-
由 Hui Wang 提交于
commit cae30527901d9590db0e12ace994c1d58bea87fd upstream. Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when configuring the kernel, then two machines were reported to have noise after installing the new kernel. Put them in the blacklist, the noise disappears. https://bugs.launchpad.net/bugs/1821663 Cc: <stable@vger.kernel.org> Signed-off-by: NHui Wang <hui.wang@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 27 3月, 2019 1 次提交
-
-
由 Jaroslav Kysela 提交于
commit 721f1e6c1fd137e7e2053d8e103b666faaa2d50c upstream. Another machine which does not like the power saving (noise): https://bugzilla.redhat.com/show_bug.cgi?id=1689623 Also, reorder the Lenovo C50 entry to keep the table sorted. Reported-by: hs.guimaraes@outlook.com Signed-off-by: NJaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 2月, 2019 1 次提交
-
-
由 Takashi Iwai 提交于
commit 305a0ade180981686eec1f92aa6252a7c6ebb1cf upstream. In the current code, the codec registration may happen both at the codec bind time and the end of the controller probe time. In a rare occasion, they race with each other, leading to Oops due to the still uninitialized card device. This patch introduces a simple flag to prevent the codec registration at the codec bind time as long as the controller probe is going on. The controller probe invokes snd_card_register() that does the whole registration task, and we don't need to register each piece beforehand. Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 12月, 2018 1 次提交
-
-
由 Kai-Heng Feng 提交于
commit 3deef52ce10514ccdebba8e8ab85f9cebd0eb3f7 upstream. It's similar to other AMD audio devices, it also supports D3, which can save some power drain. Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 06 12月, 2018 1 次提交
-
-
由 Hans de Goede 提交于
commit 39070a98d668db8fbaa2a6a6752f732cbcbb14b1 upstream. Power-saving is causing plops on audio start/stop on the built-in audio of the nForce 430 based ASRock N68C-S UCC motherboard, add this model to the power_save blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104 Cc: <stable@vger.kernel.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 14 11月, 2018 2 次提交
-
-
由 Takashi Iwai 提交于
[ Upstream commit 78c9be61c3a5cd9e2439fd27a5ffad73a81958c7 ] Introduce a new flag, uc_buffer, to indicate that the controller requires the non-cached pages for stream buffers, either as a chip-specific requirement or specified via snoop=0 option. This improves the code-readability. Also, this patch fixes the incorrect behavior for C-Media chip where the stream buffers were never handled as non-cached due to the check of driver_type even if you pass snoop=0 option. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
commit 5cb6b5fc013ee711d19bfc4e9deb8d6ae80741db upstream. Power-saving is causing plops on audio start/stop on Dell Precision T3600 laptops and Intel DZ77BH boards, add these to the power_save blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104Signed-off-by: NHans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 9月, 2018 1 次提交
-
-
由 Takashi Iwai 提交于
The recent change of vga_switcheroo allowed the runtime PM for HD-audio on AMD GPUs, but this also resulted in a regression. When the HD-audio controller driver gets runtime-suspended, HD-audio link is turned off, and the hotplug notification is ignored. This leads to the inconsistent audio state (the connection isn't notified and ELD is ignored). The best fix would be to implement the proper ELD notification via the audio component, but it's still not ready. As a quick workaround, this patch adds the check of runtime_idle and allows the runtime suspend only when the vga_switcheroo is bound with discrete GPU. That is, a system with a single GPU and APU would be again without runtime PM to keep the HD-audio link for the hotplug notification and ELD read out. Also, the codec->auto_runtime_pm flag is set only for the discrete GPU at the time GPU gets bound via vga_switcheroo (i.e. only dGPU is forcibly runtime-PM enabled), so that APU can still get the ELD notification. For identifying which GPU is bound, a new vga_switcheroo client callback, gpu_bound, is implemented. The vga_switcheroo simply calls this when GPU is bound, and tells whether it's dGPU or APU. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200945 Fixes: 07f4f97d ("vga_switcheroo: Use device link for HDA controller") Reported-by: NJian-Hong Pan <jian-hong@endlessm.com> Tested-by: NJian-Hong Pan <jian-hong@endlessm.com> Acked-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 02 8月, 2018 1 次提交
-
-
由 Hans de Goede 提交于
I added the subsys product-id for the HDMI HDA device rather then for the PCH one, this commit fixes this. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104 Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 17 7月, 2018 1 次提交
-
-
由 Jim Qu 提交于
On modern laptop, there are more and more platforms have two GPUs, and each of them maybe have audio codec for HDMP/DP output. For some dGPU which is no output, audio codec usually is disabled. In currect HDA audio driver, it will set all codec as VGA_SWITCHEROO_DIS, the audio which is binded to UMA will be suspended if user use debugfs to contorl power In HDA driver side, it is difficult to know which GPU the audio has binded to. So set the bound gpu pci dev to vga_switcheroo. if the audio client is not the third registration, audio id will set in vga_switcheroo enable function. if the audio client is the last registration when vga_switcheroo _ready() get true, we should get audio client id from bound GPU directly. Signed-off-by: NJim Qu <Jim.Qu@amd.com> Reviewed-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 16 7月, 2018 1 次提交
-
-
由 Jim Qu 提交于
Except PCI_CLASS_DISPLAY_VGA, some PCI class is sometimes PCI_CLASS_DISPLAY_3D or PCI_CLASS_DISPLAY_OTHER. Signed-off-by: NJim Qu <Jim.Qu@amd.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 28 6月, 2018 1 次提交
-
-
由 Kai-Heng Feng 提交于
This patch can make audio controller in AMD Raven Ridge gets runtime suspended to D3, to save ~1W power when it's not in use. Cc: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 29 5月, 2018 1 次提交
-
-
由 Hans de Goede 提交于
Power-saving is causing a humming sound when active on the Intel NUC5i7RY, add it to the blacklist. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199607Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 23 5月, 2018 4 次提交
-
-
由 Hans de Goede 提交于
Power-saving is causing plops on audio start/stop on ASRock H81M-HDS machines, add these to the power_save blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Hans de Goede 提交于
Power-saving is causing plops on audio start/stop on Gigabyte P55A-UD3 and Gigabyte Z87-D3HP machines, add these to the power_save blacklist. Note these 2 boards both use 1458:a002 as subsystem ids, so they share a single entry. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Hans de Goede 提交于
Power-saving is causing a plop and silences the first 2 seconds (give or take) of audio, silencing notifications sounds on Medion / Clevo W35xSS_370SS laptops. Add the Clevo W35xSS_370SS to the power_save blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1581607Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Hans de Goede 提交于
Power-saving is causing a humming sound when active on the Intel NUC7i3BNB, add it to the blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520902Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 13 5月, 2018 1 次提交
-
-
由 Hans de Goede 提交于
Power-saving is causing loud plops on the Lenovo C50 All in one, add it to the blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1572975Signed-off-by: NHans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 16 4月, 2018 1 次提交
-
-
由 David Wang 提交于
This patch is used to tell kernel that new VIA HDAC controller also support no-snoop path. [ minor coding style fix by tiwai ] Signed-off-by: NDavid Wang <davidwang@zhaoxin.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 30 3月, 2018 1 次提交
-
-
由 Lukas Wunner 提交于
The system sleep PM ops azx_suspend() and azx_resume() were previously called by vga_switcheroo, but commit 07f4f97d ("vga_switcheroo: Use device link for HDA controller") removed their invocation. Unfortunately the commit neglected to update the #ifdef surrounding the two functions, so if CONFIG_PM_SLEEP is *not* enabled but all three of CONFIG_PM, CONFIG_VGA_SWITCHEROO and CONFIG_SND_HDA_CODEC_HDMI *are* enabled, the compiler now emits the following warning: sound/pci/hda/hda_intel.c:1024:12: warning: 'azx_resume' defined but not used [-Wunused-function] static int azx_resume(struct device *dev) ^~~~~~~~~~ sound/pci/hda/hda_intel.c:989:12: warning: 'azx_suspend' defined but not used [-Wunused-function] static int azx_suspend(struct device *dev) ^~~~~~~~~~~ Silence by updating the #ifdef. Because the #ifdef block now uses the same condition as the one immediately succeeding it, the two blocks can be collapsed together, shaving off another two lines. Fixes: 07f4f97d ("vga_switcheroo: Use device link for HDA controller") Reviewed-by: NTakashi Iwai <tiwai@suse.de> Reported-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.kernel.org/patch/10313441/ Link: https://patchwork.freedesktop.org/patch/msgid/b8e70e34a9acbd4f0a1a6c7673cea96888ae9503.1522323444.git.lukas@wunner.de
-
- 21 3月, 2018 1 次提交
-
-
由 Takashi Iwai 提交于
We've observed too long probe time with Coffee Lake (CFL) machines, and the likely cause is some communication problem between the HD-audio controller and the codec chips. While the controller expects an IRQ wakeup for each codec response, it seems sometimes missing, and it takes one second for the controller driver to time out and read the response in the polling mode. Although we aren't sure about the real culprit yet, in this patch, we put a workaround by forcing the polling mode as default for CFL machines; the polling mode itself isn't too heavy, and much better than other workarounds initially suggested (e.g. disabling power-save), at least. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199007 Fixes: e79b0006 ("ALSA: hda - Add Coffelake PCI ID") Reported-and-tested-by: NHui Wang <hui.wang@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 14 3月, 2018 1 次提交
-
-
由 Lukas Wunner 提交于
Back in 2013, runtime PM for GPUs with integrated HDA controller was introduced with commits 0d69704a ("gpu/vga_switcheroo: add driver control power feature. (v3)") and 246efa4a ("snd/hda: add runtime suspend/resume on optimus support (v4)"). Briefly, the idea was that the HDA controller is forced on and off in unison with the GPU. The original code is mostly still in place even though it was never a 100% perfect solution: E.g. on access to the HDA controller, the GPU is powered up via vga_switcheroo_runtime_resume_hdmi_audio() but there are no provisions to keep it resumed until access to the HDA controller has ceased: The GPU autosuspends after 5 seconds, rendering the HDA controller inaccessible. Additionally, a kludge is required when hda_intel.c probes: It has to check whether the GPU is powered down (check_hdmi_disabled()) and defer probing if so. However in the meantime (in v4.10) the driver core has gained a feature called device links which promises to solve such issues in a clean way: It allows us to declare a dependency from the HDA controller (consumer) to the GPU (supplier). The PM core then automagically ensures that the GPU is runtime resumed as long as the HDA controller's ->probe hook is executed and whenever the HDA controller is accessed. By default, the HDA controller has a dependency on its parent, a PCIe Root Port. Adding a device link creates another dependency on its sibling: PCIe Root Port ^ ^ | | | | HDA ===> GPU The device link is not only used for runtime PM, it also guarantees that on system sleep, the HDA controller suspends before the GPU and resumes after the GPU, and on system shutdown the HDA controller's ->shutdown hook is executed before the one of the GPU. It is a complete solution. Using this functionality is as simple as calling device_link_add(), which results in a dmesg entry like this: pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0 The code for the GPU-governed audio power management can thus be removed (except where it's still needed for legacy manual power control). The device link is added in a PCI quirk rather than in hda_intel.c. It is therefore legal for the GPU to runtime suspend to D3cold even if the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL is not enabled, for accesses to the HDA controller will cause the GPU to wake up regardless if they're occurring outside of hda_intel.c (think config space readout via sysfs). Contrary to the previous implementation, the HDA controller's power state is now self-governed, rather than GPU-governed, whereas the GPU's power state is no longer fully self-governed. (The HDA controller needs to runtime suspend before the GPU can.) It is thus crucial that runtime PM is always activated on the HDA controller even if CONFIG_SND_HDA_POWER_SAVE_DEFAULT is set to 0 (which is the default), lest the GPU stays awake. This is achieved by setting the auto_runtime_pm flag on every codec and the AZX_DCAPS_PM_RUNTIME flag on the HDA controller. A side effect is that power consumption might be reduced if the GPU is in use but the HDA controller is not, because the HDA controller is now allowed to go to D3hot. Before, it was forced to stay in D0 as long as the GPU was in use. (There is no reduction in power consumption on my Nvidia GK107, but there might be on other chips.) The code paths for legacy manual power control are adjusted such that runtime PM is disabled during power off, thereby preventing the PM core from resuming the HDA controller. Note that the device link is not only added on vga_switcheroo capable systems, but for *any* GPU with integrated HDA controller. The idea is that the HDA controller streams audio via connectors located on the GPU, so the GPU needs to be on for the HDA controller to do anything useful. This commit implicitly fixes an unbalanced runtime PM ref upon unbind of hda_intel.c: On ->probe, a runtime PM ref was previously released under the condition "azx_has_pm_runtime(chip) || hda->use_vga_switcheroo", but on ->remove a runtime PM ref was only acquired under the first of those conditions. Thus, binding and unbinding the driver twice on a vga_switcheroo capable system caused the runtime PM refcount to drop below zero. The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag is now always set if use_vga_switcheroo is true. For more information on device links please refer to: https://www.kernel.org/doc/html/latest/driver-api/device_link.html Documentation/driver-api/device_link.rst Cc: Dave Airlie <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NPeter Wu <peter@lekensteyn.nl> Tested-by: Kai Heng Feng <kai.heng.feng@canonical.com> # AMD PowerXpress Tested-by: Mike Lothian <mike@fireburn.co.uk> # AMD PowerXpress Tested-by: Denis Lisov <dennis.lissov@gmail.com> # Nvidia Optimus Tested-by: Peter Wu <peter@lekensteyn.nl> # Nvidia Optimus Tested-by: Lukas Wunner <lukas@wunner.de> # MacBook Pro Signed-off-by: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/51bd38360ff502a8c42b1ebf4405ee1d3f27118d.1520068884.git.lukas@wunner.de
-
- 13 3月, 2018 1 次提交
-
-
由 Guneshwor Singh 提交于
Icelake is a next generation Intel platform. Add PCI ID for it. Signed-off-by: NGuneshwor Singh <guneshwor.o.singh@intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 12 3月, 2018 1 次提交
-
-
由 Takashi Iwai 提交于
With the commit 1ba8f9d3 ("ALSA: hda: Add a power_save blacklist"), we changed the default value of power_save option to -1 for processing the power-save blacklist. Unfortunately, this seems breaking user-space applications that actually read the power_save parameter value via sysfs and judge / adjust the power-saving status. They see the value -1 as if the power-save is turned off, although the actual value is taken from CONFIG_SND_HDA_POWER_SAVE_DEFAULT and it can be a positive. So, overall, passing -1 there was no good idea. Let's partially revert it -- at least for power_save option default value is restored again to CONFIG_SND_HDA_POWER_SAVE_DEFAULT. Meanwhile, in this patch, we keep the blacklist behavior and make is adjustable via the new option, pm_blacklist. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073 Fixes: 1ba8f9d3 ("ALSA: hda: Add a power_save blacklist") Acked-by: NHans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 24 2月, 2018 1 次提交
-
-
由 Hans de Goede 提交于
On some boards setting power_save to a non 0 value leads to clicking / popping sounds when ever we enter/leave powersaving mode. Ideally we would figure out how to avoid these sounds, but that is not always feasible. This commit adds a blacklist for devices where powersaving is known to cause problems and disables it on these devices. Note I tried to put this blacklist in userspace first: https://github.com/systemd/systemd/pull/8128 But the systemd maintainers rightfully pointed out that it would be impossible to then later remove entries once we actually find a way to make power-saving work on listed boards without issues. Having this list in the kernel will allow removal of the blacklist entry in the same commit which fixes the clicks / plops. The blacklist only applies to the default power_save module-option value, if a user explicitly sets the module-option then the blacklist is not used. [ added an ifdef CONFIG_PM for the build error -- tiwai] BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198611 Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 23 11月, 2017 1 次提交
-
-
由 Vijendar Mukunda 提交于
This commit adds PCI ID for Raven platform Signed-off-by: NVijendar Mukunda <Vijendar.Mukunda@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 07 8月, 2017 1 次提交
-
-
由 Guneshwor Singh 提交于
Cannonlake is next generation Intel platform. This commit adds PCI ID for it. Signed-off-by: NGuneshwor Singh <guneshwor.o.singh@intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 04 7月, 2017 1 次提交
-
-
由 Takashi Iwai 提交于
The commit dba9b7b6 ("ALSA: hda - Fix doubly initialization of i915 component") contained a typo that leads to the unbalance of i915 module reference. The value to be checked is not chip->driver_type but chip->driver_caps. Fixes: dba9b7b6 ("ALSA: hda - Fix doubly initialization of i915 component") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196219Reported-by: NMartin Peres <martin.peres@free.fr> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 30 6月, 2017 1 次提交
-
-
由 Takashi Iwai 提交于
In the commit fcc88d91 ("ALSA: hda - Bind with i915 component before codec binding"), the binding with i915 audio component is moved to be performed always at probing the controller. This fixed the potential problems on IVB, but now it brought another issue on HSW and BDW. These two platforms give two individual HD-audio controllers, one for the analog codec on PCH and another for HDMI over gfx. Since I decided to take a lazy path to check only AZX_DRIVER_PCH type in the commit above, now both controllers try to bind with i915, and you see a kernel WARNING. This patch tries to address it again properly. Now a new DCAPS bit, AZX_DCAPS_I915_COMPONENT, is introduced for indicating the binding with i915 component in addition to the existing I915_POWERWELL bit flag. Each PCI entry has to give this new flag if it requires the binding with i915 component. For HSW/BDW PCH (i.e. the ones defined by AZX_DCAPS_INTEL_PCH) doesn't contain AZX_DCAPS_I915_COMPONENT bit while others have it. While we're at it, add parentheses around the bit flag check for avoiding possible compiler warnings, too. The bug was spotted by Intel CI tests. Fixes: fcc88d91 ("ALSA: hda - Bind with i915 component before codec binding") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196219Reported-by: NMartin Peres <martin.peres@free.fr> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 28 6月, 2017 1 次提交
-
-
由 Takashi Iwai 提交于
We used a on-demand i915 component binding for IvyBridge and SandyBridge HDMI codecs, but it has a potential problem of the nested module loading. For avoiding that situation, assure the i915 binding happening at the controller driver level for PCH controller devices, where the initialization is performed in a detached work, instead of calling from the codec driver probe. Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 20 6月, 2017 2 次提交
-
-
由 Takashi Iwai 提交于
We checked the quirks specific to the recent Intel chips by checking the PCI IDs manually, but it's becoming messy with lots of IS_SKL() and other macros, as the amount accumulated. For simplification, here the new AZX_DRIVER_SKL type is introduced, and check chip->driver_type instead of the manual PCI ID. The short name for this is still "HDA Intel PCH", so that it doesn't break the existing user-space unnecessarily. Suggested-by: NVinod Koul <vinod.koul@intel.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
由 Takashi Iwai 提交于
Broxton-T was a forgotten child and we didn't apply the quirks for Skylake+ properly. Meanwhile, a quirk for reducing the DMA latency seems specific to the early Broxton model, so we leave as is. Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 14 6月, 2017 1 次提交
-
-
由 Megha Dey 提交于
Coffelake is another Intel part, so need to add PCI ID for it. Signed-off-by: NMegha Dey <megha.dey@intel.com> Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com> Acked-by: NVinod Koul <vinod.koul@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-
- 09 5月, 2017 1 次提交
-
-
由 Laura Abbott 提交于
set_memory_* functions have moved to set_memory.h. Switch to this explicitly. Link: http://lkml.kernel.org/r/1488920133-27229-14-git-send-email-labbott@redhat.comSigned-off-by: NLaura Abbott <labbott@redhat.com> Acked-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 4月, 2017 1 次提交
-
-
由 Subhransu S. Prusty 提交于
Geminilake is Skylake family platform. So add it's id to skl_plus check. Fixes: 126cfa2f ("ALSA: hda: Add Geminilake HDMI codec ID") Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com> Cc: Senthilnathan Veppur <senthilnathanx.veppur@intel.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: NTakashi Iwai <tiwai@suse.de>
-