- Feb 15, 2016
-
-
Takashi Iwai authored
The commit [991f86d7: ALSA: hda - Flush the pending probe work at remove] introduced the sync of async probe work at remove for fixing the race. However, this may lead to another hangup when the module removal is performed quickly before starting the probe work, because it issues flush_work() and it's blocked forever. The workaround is to use cancel_work_sync() instead of flush_work() there. Fixes: 991f86d7 ('ALSA: hda - Flush the pending probe work at remove') Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
- Jan 29, 2016
-
-
Libin Yang authored
On Broxton, to make sure the reset controller works properly, MISCBDCGE bit (bit 6) in CGCTL (0x48) of PCI configuration space need be cleared before reset and set back to 1 after reset. Otherwise, it may prevent the CORB/RIRB logic from being reset. Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
-
- Jan 20, 2016
-
-
Takashi Iwai authored
As HD-audio driver does deferred probe internally via workqueue, the driver might go into the mixed state doing both probe and remove when the module gets unloaded during the probe work. This eventually triggers an Oops, unsurprisingly. For avoiding this race, we just need to flush the pending probe work explicitly before actually starting the resource release. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=960710 Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
-
Takashi Iwai authored
Currently HD-audio driver on Intel Skylake or Broxteon gives an error message when binding with i915 audio component fails. However, this isn't any serious error on a system without Intel graphics. Indeed there are such systems, where a third-party codec (e.g. Creative) is put on the mobo while using other discrete GPU (e.g. Nvidia). Printing a kernel "error" message is overreaction in such a case. This patch downgrades the print level for that message. For systems that mandate the i915 binding (e.g. Haswell or Broadwell HDMI/DP), another kernel error message is shown in addition to make clear what went wrong. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111021 Signed-off-by:
-
- Jan 12, 2016
-
-
Heiner Kallweit authored
Currently the info in /proc/interrupts doesn't allow to figure out which interrupt belongs to which card (HDMI, PCH, ..). Therefore add card details to the interrupt description. With the patch the info in /proc/interrupts looks like this: PCI-MSI 442368-edge snd_hda_intel:card1 PCI-MSI 49152-edge snd_hda_intel:card0 NOTE: this patch adds the new irq_descr field snd_card struct that is filled automatically at a card object creation. This can be used generically for other drivers as well. The changes for others will follow later -- tiwai Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
- Dec 18, 2015
-
-
Xiong Zhang authored
It takes three minutes to enter into hibernation on some OEM SKL machines and we see many codec spurious response after thaw() opertion. This is because HDA is still in D0 state after freeze() call and pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver. It seems bios still access HDA when system enter into freeze state, HDA will receive codec response interrupt immediately after thaw() call. Because of this unexpected interrupt, HDA enter into a abnormal state and slow down the system enter into hibernation. In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and put HDA into D0 state in azx_thaw_noirq(). V2: Only apply this fix to SKL+ Fix compile error when CONFIG_PM_SLEEP isn't defined [Yet another fix for CONFIG_PM_SLEEP ifdef and the additional comment by tiwai] Signed-off-by:Xiong Zhang <xiong.y.zhang@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Dec 17, 2015
-
-
Takashi Iwai authored
AZX_DCAPS_REVERSE_ASSIGN is no longer referred by any code. Let's drop it. Signed-off-by: -
Takashi Iwai authored
AZX_DCAPS_POSFIX_VIA is coupled always with AZX_DRIVER_VIA type, so we don't have to keep this bit in dcaps. Save one more! Signed-off-by: -
Takashi Iwai authored
AZX_DCAPS_RIRB_DELAY is dedicated only for Nvidia and its purpose is just to set a flag in bus. So it's better to be set in the toplevel driver, either hda_intel.c or hda_tegra.c, instead of the common hda_controller.c. This also allows us to strip this flag from dcaps, so save one more bit there. Signed-off-by: -
Takashi Iwai authored
AZX_DCAPS_RIRB_PRE_DELAY is always tied with AZX_DCAPS_CTX_WORKAROUND, which is Creative's XFi specific. So, we can replace it and reduce one more bit free for DCAPS. Signed-off-by:
-
- Dec 15, 2015
-
-
Takashi Iwai authored
Intel Atom processors seem to have a problem at recording when bdl_pos_adj is set to an odd value. When a value like 1 is used, it may drop the samples unexpectedly. Actually, for the old Atoms, we used to set AZX_DRIVER_SCH type, and this assigns 32 as default. Meanwhile the newer chips, Baytrail and Braswell, are set as AZX_DRIVER_PCH, and the lower default value, 1, is assigned. This patch changes the default values for these chipsets to a safer default, 32, again. Since changing the driver type (AZX_DRIVER_XXX) leads to the rename of the driver string, it would result in a possible regression. So, we can't change the type. Instead, in this patch, manual (ugly) PCI ID checks are added on top. A drawback by this increase is the slight increase of the latency, but it's a sub-ms order in normal situations, so mostly negligible. Reported-and-tested-by:
Jochen Henneberg <jh@henneberg-systemdesign.com> Signed-off-by:
-
Takashi Iwai authored
Just a minor cleanup; instead of passing an array, pass the assigned bdl_pos_adj option value directory in struct azx. Also split the code to get the default bdl_pos_adj value for the change that will follow after this. Signed-off-by:
-
- Dec 10, 2015
-
-
Takashi Iwai authored
Due to the recent change, HDA controller driver for Intel PCH tries to bind i915 audio component always at the probe time no matter whether HDMI/DP codec is found. This is, however, superflulous for old chipsets (e.g. on IVB) where they don't have always the HDMI/DP codecs but often have only a discrete GPU instead. For the newer chipsets, we need already the i915 binding from the beginning due to power well control. Meanwhile, for older chipsets where we don't need power well, we don't need the i915 binding at the controller level. This patch removes again the i915 binding in the HDA controller driver for old Intel PCHs, but adds the binding in HDMI/DP codec driver instead. This allows still the use of the direct notification from the graphics driver while we can avoid the unnecessary load of i915 driver for machines only with another GPU. Signed-off-by:
-
- Dec 09, 2015
-
-
Takashi Iwai authored
The recent commit [6603249d: ALSA: hda - Enable audio component for old Intel PCH devices] enabled the i915 binding for HDMI/DP on old Intel PCHs. But many boards are without HDMI/DP, and they actually don't need i915 binding, and yet the driver has a check of i915 binding and complains like Haswell must be built with CONFIG_SND_HDA_I915 This error is false-positive, and it should be put only for HSW/BDW, instead of all devices that may be bound with i915. This patch fixes the condition to check, as well as rephrasing the message specific to HSW/BDW HDMI/DP. Fixes: 6603249d ('ALSA: hda - Enable audio component for old Intel PCH devices') Signed-off-by:
-
- Dec 07, 2015
-
-
Lu, Han authored
In BXT-P A0, HD-Audio DMA requests is later than expected, and makes an audio stream sensitive to system latencies when 24/32 bits are playing. Adjusting threshold of DMA fifo to force the DMA request sooner to improve latency tolerance at the expense of power. v2: move Intel specific code to hda_intel.c Signed-off-by:
Lu, Han <han.lu@intel.com> Signed-off-by:
-
- Dec 04, 2015
-
-
Takashi Iwai authored
As i915 graphics driver provides the notification via audio component, not only the currently implemented HSW+ and VLV+ platforms but also all other PCH-based platforms (e.g. Cougar Point, Panther Point, etc) can use this infrastructure. It'll improve the reliability and the power consumption significantly, especially once when we implement the ELD notification via component. As a preliminary, this patch enables the usage of audio component for all PCH platforms. The HDA controller just needs to set AZX_DCAPS_I915_POWERWELL flag appropriately. The name of the flag is a bit confusing, but this actually works even on the chips without the powerwell but accesses only the other component ops. In the HDMI/DP codec driver side, we just need to register/unregister the notifier for such chips. This can be identified by checking the audio_component field in the assigned hdac_bus. One caveat is that PCH for Haswell and Broadwell must not be bound with i915 audio component, as there are dedicated HD-audio HDMI controllers on these platforms. Ditto for Poulsbo and Oaktrail as they use gma500 graphics, not i915. Signed-off-by:
-
- Nov 19, 2015
-
-
Lu, Han authored
Add HD Audio Device PCI ID for the Intel Broxton platform. It is an HDA Intel PCH controller. Signed-off-by:
-
- Nov 05, 2015
-
-
Alexandra Yates authored
Adding Intel codename Lewisburg platform device IDs for audio. [rearranged the position by tiwai] Signed-off-by:
Alexandra Yates <alexandra.yates@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Oct 27, 2015
-
-
Takashi Iwai authored
We've had many reports that some Creative sound cards with CA0132 don't work well. Some reported that it starts working after reloading the module, while some reported it starts working when a 32bit kernel is used. All these facts seem implying that the chip fails to communicate when the buffer is located in 64bit address. This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT flag to the corresponding PCI entries. I casually had a chance to test an SB Recon3D board, and indeed this seems helping. Although this hasn't been tested on all Creative devices, it's safer to assume that this restriction applies to the rest of them, too. So the flag is applied to all Creative entries. Cc: <stable@vger.kernel.org> Signed-off-by:
-
- Oct 19, 2015
-
-
Lukas Wunner authored
Currently everyone and their dog has their own favourite spelling for vga_switcheroo. This makes it hard to grep dmesg for log entries relating to vga_switcheroo. It also makes it hard to find related source files in the tree. vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- Sep 24, 2015
-
-
Lukas Wunner authored
The active attribute in struct vga_switcheroo_client denotes whether the outputs are currently switched to this client. The attribute is only meaningful for vga clients. It is never used for audio clients. The function vga_switcheroo_register_audio_client() misuses this attribute to store whether the audio device is fully initialized. Most likely there was a misunderstanding about the meaning of "active" when this was added. Comment from Takashi's review: "Not really. The full initialization of audio was meant that the audio is active indeed. Admittedly, though, the active flag for each audio client doesn't play any role because the audio always follows the gfx state changes, and the value passed there doesn't reflect the actual state due to the later change. So, I agree with the removal of the flag itself -- or let the audio active flag following the corresponding gfx flag. The latter will make the proc output more consistent while the former is certainly more reduction of code." Set the active attribute to false for audio clients. Remove the active parameter from vga_switcheroo_register_audio_client() and its sole caller, hda_intel.c:register_vga_switcheroo(). vga_switcheroo_register_audio_client() was introduced by 3e9e63db ("vga_switcheroo: Add the support for audio clients"). Its use in hda_intel.c was introduced by a82d51ed ("ALSA: hda - Support VGA-switcheroo"). v1.1: The changes above imply that in find_active_client() the call to client_is_vga() is now superfluous. Drop it. Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
- Jul 29, 2015
-
-
U. Artie Eoff authored
PM ops could be triggered before HDA is done initializing and cause PM to set HDA controller to D3Hot. This can result in "CORB reset timeout#2, CORBRP = 65535" and "no codecs initialized". Additionally, PM ops can be triggered before azx_probe_continue finishes (async probe). This can result in a NULL deref kernel crash. To fix this, avoid PM ops if !chip->running. Signed-off-by:
U. Artie Eoff <ullysses.a.eoff@intel.com> Signed-off-by:
-
- Jul 20, 2015
-
-
Maruthi Srinivas Bayyavarapu authored
Fixes audio problems on newer asics Signed-off-by:
Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
David Henningsson authored
When the controller is powered up but the HDMI codec is powered down on Skylake, the power well is turned off. When the codec is then powered up again, we need to poke the codec a little extra to make sure it wakes up. Otherwise we'll get sad "no response from codec" messages and broken audio. This also changes azx_runtime_resume to actually call snd_hdac_set_codec_wakeup for Skylake (before STATETS read). (Otherwise it would only have been called for Haswell and Broadwell, which both do not need it, so this probably was not the author's intention.) Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Reviewed-by:
Libin Yang <libin.yang@intel.com> Signed-off-by:
-
- Jun 25, 2015
-
-
Alex Deucher authored
Fixes audio problems on newer asics. Noticed by: Kelly Anderson <kelly@xilka.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- Jun 16, 2015
-
-
Takashi Iwai authored
When CONFIG_SND_HDA_I915=n, we get a compile warning: sound/pci/hda/hda_intel.c: In function ‘azx_probe_continue’: sound/pci/hda/hda_intel.c:1882:2: warning: label ‘skip_i915’ defined but not used [-Wunused-label] Fix it by putting again ifdef to it. Sigh. Fixes: bf06848b ('ALSA: hda - Continue probing even if i915 binding fails') Reported-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
- Jun 12, 2015
-
-
Takashi Iwai authored
The previous patch tried to continue the probe if i915 binding fails. For for simplicity reason, we haven't implemented abort even for controller chips that are dedicated for HDMI/DP on HSW and BDW. However, Mengdong suggested that this can be dangerous; BIOS may disable gfx power well although the PCI entry for HD-audio is left, and this may result in the unexpected behavior, kernel errors, etc. For avoiding this situation, abort the probe at i915 binding failure only for HSW/BDW chips selectively. For other chips, it still continues. Fixes: bf06848b ('ALSA: hda - Continue probing even if i915 binding fails') Reported-by:
Mengdong Lin <mengdong.lin@intel.com> Signed-off-by:
-
- Jun 11, 2015
-
-
Takashi Iwai authored
Currently snd-hda-intel driver aborts the probing of Intel HD-audio controller with i915 power well management when binding with i915 driver via hda_i915_init() fails. This is no big problem for Haswell and Broadwell where the HD-audio controllers are dedicated to HDMI/DP, thus i915 link is mandatory. However, Skylake, Baytrail and Braswell have only one controller and both HDMI/DP and analog codecs share the same bus. Thus, even if HDMI/DP isn't usable, we should keep the controller working for other codecs. For fixing this, this patch simply allows continuing the probing even if hda_i915_init() call fails. This may leave stale sound components for HDMI/DP devices that are unbound with graphics. We could abort the probing selectively, but from the code simplicity POV, it's better to continue in all cases. Reported-by:
-
- Jun 03, 2015
-
-
Libin Yang authored
For SKL, only the HDMI codec is in the display power well while the HD-A controller isn't. So the controller flag 'need_i915_power' is not set to release the display power after probe, and the codec flag 'link_power_control' is set to request/release the display power via bus link_power ops. Signed-off-by:
-
- May 28, 2015
-
-
Luis R. Rodriguez authored
Most code already uses consts for the struct kernel_param_ops, sweep the kernel for the last offending stragglers. Other than include/linux/moduleparam.h and kernel/params.c all other changes were generated with the following Coccinelle SmPL patch. Merge conflicts between trees can be handled with Coccinelle. In the future git could get Coccinelle merge support to deal with patch --> fail --> grammar --> Coccinelle --> new patch conflicts automatically for us on patches where the grammar is available and the patch is of high confidence. Consider this a feature request. Test compiled on x86_64 against: * allnoconfig * allmodconfig * allyesconfig @ const_found @ identifier ops; @@ const struct kernel_param_ops ops = { }; @ const_not_found depends on !const_found @ identifier ops; @@ -struct kernel_param_ops ops = { +const struct kernel_param_ops ops = { }; Generated-by: Coccinelle SmPL Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Junio C Hamano <gitster@pobox.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org> Cc: Tejun Heo <tj@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: cocci@systeme.lip6.fr Cc: linux-kernel@vger.kernel.org Signed-off-by:Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au>
-
- May 27, 2015
-
-
Takashi Iwai authored
A new AMD controller [1002:aac8] seems to need the quirk for other AMD NS HDMI stuff, otherwise it gives noisy sounds. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99021 Cc: <stable@vger.kernel.org> Signed-off-by:
-
- May 20, 2015
-
-
Mengdong Lin authored
The file is moved to hda core and renamed to hdac_i915.c, so can be used by both legacy HDA driver and new Skylake audio driver. - Add snd_hdac_ prefix to the public APIs. - The i915 audio component is moved to core bus and dynamically allocated. - A static pointer hdac_acomp is used to help bind/unbind callbacks to get this component, because the sound card's private_data is used by the azx chip pointer, which is a legacy structure. It could be removed if private _data changes to some core structure which can be extended to find the bus. - snd_hdac_get_display_clk() is added to get the display core clock for HSW/BDW. - haswell_set_bclk() is moved to hda_intel.c because it needs to write the controller registers EM4/EM5, and only legacy HD-A needs it for HSW/BDW. - Move definition of HSW/BDW-specific registers EM4/EM5 to hda_register.h and rename them to HSW_EM4/HSW_EM5, because other HD-A controllers have different layout for the extended mode registers. Signed-off-by:
-
- May 18, 2015
-
-
Libin Yang authored
This patch creates hda_intel_trace.h to add some pm trace functions used in hda_intel.c Signed-off-by:
-
- May 05, 2015
-
-
Lu, Han authored
In SKL, HDMI/DP codec and PCH HD Audio Controller are in different power wells, so it's necessary to reset display audio codecs when power well on, otherwise display audio codecs will disappear when resume from low power state. Reset steps when power on: enable codec wakeup -> azx_init_chip() -> disable codec wakeup The callback for codec wakeup enable/disable is in drivers/gpu/drm/i915/. Signed-off-by:
-
- Apr 30, 2015
-
-
Takashi Iwai authored
We're providing dummy functions for CONFIG_SND_HDA_i915=n, thus ifdef can be reduced. (But hda_i915_init() has to be fixed to return zero.) This automatically fixes a compile warning: sound/pci/hda/hda_intel.c: In function 'azx_probe_continue': sound/pci/hda/hda_intel.c:1966:1: warning: label 'i915_power_fail' defined but not used [-Wunused-label] Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
- Apr 29, 2015
-
-
Mengdong Lin authored
For Baytrail (Valleyview) and Braswell (Cherryview), only the HDMI codec is in the display power well while the HD-A controller isn't. So the controller flag 'need_i915_power' is not set to release the display power after probe, and the codec flag 'link_power_control" is set to request/release the display power via bus link_power ops. Signed-off-by:
-
Mengdong Lin authored
This patch can improve power saving for Intel platforms on which only the display audio codec is in the shared i915 power well: - Add a flag "need_i915_power" to indicate whether the controller needs the i915 power well. - The driver will always request the i915 power when probing the controller and codecs if AZX_DCAPS_I915_POWERWELL is set (either the controller or a codec needs this power). - If the controller needs the i915 power, the power will be held after probe until the controller is runtime suspended or S3. If the controller doesn't need the power, the power will be released the after probe, and a codec that needs the power can request/release the power via bus link_power ops. Background: - For Haswell/Broadwell, which has a separate HD-A controller for display audio, both the controller and the display codec are in the i915 power well. - For Baytrail/Braswell, the display and analog audio share the same HDA controller and link, and only the display codec is in the i915 power well. - For Skylake, the display and analog audio share the same HDA controller but use separate links. Only the display codec is in the i915 power well. And in legacy mode we take the two links as one. So it can follow Baytrail/Braswell. Signed-off-by:
-
Mengdong Lin authored
This patch implements the bus link_power ops to request/release i915 display power well. It can be used by the display codec which shares this power well with GPU on Intel platforms. Signed-off-by:
-
- Apr 21, 2015
-
-
Mengdong Lin authored
This patch addes AZX_DCAPS_I915_POWERWELL to BYT (Baytrail). Like Braswell and Skylake, the HDMI codec on Bytrail is also in the shared power well with GPU. This power well must be turned on before we reset link to probe the codec, to avoid communication failure with the codec. The side effect is that this power is always ON in S0 because the BYT HDMI codec does not support EPSS or D3ClkStop and so the controller doesn't enter D3 at runtime, and the HDMI codec and analog codec share a single physical HD-A link and so we cannot reset the HD-A link freely when we re-enable the power to use the HDMI codec. Next step is to test if an AGP reset or double AGP reset on BYT HDMI codec is okay to bring the HDMI codec back to a functional state after restoring the power. If okay, we can bind the power on/off with the HDMI codec PM without interrupting the analog audio. Signed-off-by:
-
- Apr 16, 2015
-
-
Quentin Lambert authored
Replace occurences of the pci api by appropriate call to the dma api. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr ) @deprecated@ idexpression id; position p; @@ ( pci_dma_supported@p ( id, ...) | pci_alloc_consistent@p ( id, ...) ) @bad1@ idexpression id; position deprecated.p; @@ ...when != &id->dev when != pci_get_drvdata ( id ) when != pci_enable_device ( id ) ( pci_dma_supported@p ( id, ...) | pci_alloc_consistent@p ( id, ...) ) @depends on !bad1@ idexpression id; expression direction; position deprecated.p; @@ ( - pci_dma_supported@p ( id, + dma_supported ( &id->dev, ... + , GFP_ATOMIC ) | - pci_alloc_consistent@p ( id, + dma_alloc_coherent ( &id->dev, ... + , GFP_ATOMIC ) ) Signed-off-by:
Quentin Lambert <lambert.quentin@gmail.com> Signed-off-by:
-
