summaryrefslogtreecommitdiffstats
path: root/sound/pci
Commit message (Collapse)AuthorAgeFilesLines
...
* | ALSA: hda/tegra: implement runtime suspend/resumeSameer Pujar2019-01-221-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch moves clock enable/disable from system resume/suspend to runtime resume/suspend respectively. Along with this hda controller chip init or stop is also moved. System resume/suspend can invoke runtime callbacks and do necessary setup. chip->running can be used to check for probe completion and device access during runtime_resume or runtime_suspend can be avoided if probe is not yet finished. This helps to avoid kernel panic during boot where runtime PM callbacks can happen from system PM. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com> Reviewed-by: Mohan Kumar D <mkumard@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: hda/tegra: remove redundant clock enable APISameer Pujar2019-01-221-7/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | Explicit clock enable is not required during probe, as this would be managed by runtime PM calls. Clock can be enabled/disabled in runtime resume/suspend. This way it is easier to balance clock enable/disable counts. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com> Reviewed-by: Mohan Kumar D <mkumard@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: hda/tegra: add runtime PM callbacksSameer Pujar2019-01-221-0/+15
| | | | | | | | | | | | | | | | | | This patch adds skeleton of runtime suspend and resume callbacks. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com> Reviewed-by: Mohan Kumar D <mkumard@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: hda/tegra: get clock handles early in probeSameer Pujar2019-01-221-16/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Moved devm_clk_get() API calls to a separate function and the same can be called early in the probe. This is done before runtime PM for the device is enabled. The runtime resume/suspend callbacks can later enable/disable clocks respectively(the support would be added in subsequent patches). Clock handles should be available by the time runtime suspend/resume calls can happen. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com> Reviewed-by: Mohan Kumar D <mkumard@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: hda/tegra: runtime power management supportSameer Pujar2019-01-221-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables runtime power management(runtime PM) support for hda. pm_runtime_enable() and pm_runtime_disable() are added during device probe and remove respectively. The runtime PM callbacks will be forbidden if hda controller does not have support for runtime PM. pm_runtime_get_sync() and pm_runtime_put() are added for hda register access. The callbacks for above will be added in subsequent patches. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com> Reviewed-by: Mohan Kumar D <mkumard@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: hda - Fix unused variable warningTakashi Iwai2019-01-211-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | The unused variable was forgotten to be removed and now we get a compiler warning: sound/pci/hda/hda_codec.c: In function 'hda_codec_runtime_suspend': sound/pci/hda/hda_codec.c:2926:18: warning: unused variable 'pcm' Fixes: 17bc4815de58 ("ALSA: pci: Remove superfluous snd_pcm_suspend*() calls") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | Merge branch 'topic/pcm-device-suspend' into for-nextTakashi Iwai2019-01-1833-96/+10Star
|\ \ | | | | | | | | | | | | | | | | | | | | | Pull the PCM suspend improvement / cleanup. This moves the most of snd_pcm_suspend*() calls into PCM's own device PM ops. There should be no change from the functionality POV. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: pci: Remove superfluous snd_pcm_suspend*() callsTakashi Iwai2019-01-1532-85/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | The call of snd_pcm_suspend_all() & co became superfluous since we call it in the PCM PM ops. Let's remove them. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: atiixp: Move PCM suspend/resume code into trigger callbackTakashi Iwai2019-01-151-11/+8Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ATIIXP driver supports the full PCM resume and saves/restores the running PCM pointer. This used to be done in the suspend and resume callbacks together with snd_pcm_suspend() call. But since we moved the snd_pcm_supsend*() call in PCM device PM ops, this should be moved to a more appropriate place, i.e. the trigger callback. Along with the movement of the PCM suspend/resume code, remove the superfluous snd_pcm_suspend_all() call, too. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: hda: program stripe control for codecSameer Pujar2019-01-141-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Program codec stripe through AC_VERB_SET_STRIPE_CONTROL to use multiple sdo lines if supported. Audio needs to be striped across number of sdo lines for simultaneous playbacks of higher resolutions to work. This needs to be implemented only for an Audio Output Converter and only if the stripe bit(AC_WCAP_STRIPE) of Audio Widget Capabilities parameter is 1. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Mohan Kumar D <mkumard@nvidia.com> Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: ice1712: fix a missing check of snd_i2c_sendbytesAditya Pakki2019-01-071-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | snd_i2c_sendbytes could fail. The fix checks its return value: if it fails, issues an error message and returns with its error code. Signed-off-by: Aditya Pakki <pakki001@umn.edu> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: oxygen: initialize spdif_playback_enable to 0Tom Yan2019-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | There's no reason for us to do that while we initialize dac_mute to 1. Also oxygen_init() has been clearing the OXYGEN_SPDIF_OUT_ENABLE bit anyway. Signed-off-by: Tom Yan <tom.ty89@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: virtuoso: add de-emphasis controlTom Yan2019-01-072-3/+69
| |/ |/| | | | | | | | | | | Add control for the de-emphasis filter in the PCM179x DACs Signed-off-by: Tom Yan <tom.ty89@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: hda/realtek - Support Dell headset mode for New AIO platformKailang Yang2019-01-071-0/+1
|/ | | | | | | | | Dell has new platform for ALC274. This will support to enable headset mode. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - Revert DSP detection on legacy HD-audio driverTakashi Iwai2019-01-013-110/+8Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This essentially reverts the commits c337104b1a16 ("ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected") and d82b51c855a2 ("ALSA: HD-Audio: SKL+: force HDaudio legacy or SKL+ driver selection") for the path of legacy HD-audio controller (snd-hda-intel). The automatic DSP detection and skip of binding with the legacy driver caused regressions on several machines like Dell XPS13. They give the PCI class 0x40380 indicating the availability of DSP while they don't work with ASoC SKL driver (yet). As the support of ASoC driver for such devices isn't available, it's better to revert the whole DSP-detection-and-skip behavior of the legacy driver, so that we can get the old good driver working on such devices. The pci_binding option for ASoC SKL driver is still kept so that it can work without blacklisting. Fixes: c337104b1a16 ("ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected") Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Hans de Goede <hdegoede@redhat.com> Reported-by: Azat Khuzhin <dohardgopro@gmail.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda/tegra: clear pending irq handlersSameer Pujar2019-01-011-0/+2
| | | | | | | | | | | | | | | | Even after disabling interrupts on the module, it could be possible that irq handlers are still running. System hang is seen during suspend path. It was found that, there were pending writes on the HDA bus and clock was disabled by that time. Above mentioned issue is fixed by clearing any pending irq handlers before disabling clocks and returning from hda suspend. Suggested-by: Mohan Kumar <mkumard@nvidia.com> Suggested-by: Dara Ramesh <dramesh@nvidia.com> Signed-off-by: Sameer Pujar <spujar@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda/realtek: Enable the headset mic auto detection for ASUS laptopsJian-Hong Pan2019-01-011-1/+1
| | | | | | | | | | | | The headset mic of ASUS laptops like UX533FD, UX433FN and UX333FA, whose CODEC is Realtek ALC294 has jack auto detection feature. This patch enables the feature. Fixes: 4e051106730d ("ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294") Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: HD-Audio: SKL+: force HDaudio legacy or SKL+ driver selectionPierre-Louis Bossart2018-12-191-3/+23
| | | | | | | | | | | | | | | | | | | | | For HDaudio and Skylake drivers, add module parameter "pci_binding" When pci_binding == 0 (AUTO), the PCI class/subclass info is used to select drivers based on the presence of the DSP. pci_binding == 1 (LEGACY) forces the use of the HDAudio legacy driver, even if the DSP is present. pci_binding == 2 (ASOC) forces the use of the ASOC driver. The information on the DSP presence is bypassed. The value for the module parameter needs to be identical for both drivers. This parameter is intended as a back-up solution if the automatic detection fails or when the DSP usage fails. Such cases should be reported on the alsa-devel mailing list for analysis. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selectedPierre-Louis Bossart2018-12-193-8/+90
| | | | | | | | | | | | | | | | | | | | | | | | Now that the SST/Skylake driver supports per platform selectors, we can add logic to automatically select the right driver. If the Skylake driver is selected for a specific platform, and the DSP is detected at run-time based on the PCI class/subclass/prog-if information, the legacy HDaudio driver aborts the probe. This will result in a single driver probing and remove the need for modprobe blacklists. Follow-up patches will add a module parameter to bypass the logic if this automatic detection fails, or if the Skylake driver is unable to actually support the platform (firmware authentication, missing topology file, hardware issue, etc). The same mechanism will be used to conflicts generated by the same PCI ID being registered by both legacy HDAuudio and SOF drivers for Intel platforms. In other words SOF will not require changes to the HDaudio legacy. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda/realtek: Enable audio jacks of ASUS UX391UA with ALC294Wandrille RONCE2018-12-191-0/+1
| | | | | | | | | | | | | | By default, there is no sound on Asus UX391UA on Linux. This patch adds sound support on Asus UX391UA. Tested working by three different users. The problem has also been described at https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1784485 Signed-off-by: Wandrille RONCE <w@ndrille.fr> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: Fix potential Spectre v1 vulnerabilitiesGustavo A. R. Silva2018-12-191-0/+5
| | | | | | | | | | | | | | | | | | | | | | ipcm->substream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/pci/emu10k1/emufx.c:1031 snd_emu10k1_ipcm_poke() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap) sound/pci/emu10k1/emufx.c:1075 snd_emu10k1_ipcm_peek() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap) Fix this by sanitizing ipcm->substream before using it to index emu->fx8010.pcm Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rme9652: Fix potential Spectre v1 vulnerabilityGustavo A. R. Silva2018-12-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | info->channel is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/pci/rme9652/hdsp.c:4100 snd_hdsp_channel_info() warn: potential spectre issue 'hdsp->channel_map' [r] (local cap) Fix this by sanitizing info->channel before using it to index hdsp->channel_map Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. Also, notice that I refactored the code a bit in order to get rid of the following checkpatch warning: ERROR: do not use assignment in if condition FILE: sound/pci/rme9652/hdsp.c:4103: if ((mapped_channel = hdsp->channel_map[info->channel]) < 0) [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: add mute LED support for HP EliteBook 840 G4Mantas Mikulėnas2018-12-161-0/+1
| | | | | | | | | | | Tested with 4.19.9. v2: Changed from CXT_FIXUP_MUTE_LED_GPIO to CXT_FIXUP_HP_DOCK because that's what the existing fixups for EliteBooks use. Signed-off-by: Mantas Mikulėnas <grawity@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'topic/huawei-leds' into for-nextTakashi Iwai2018-12-131-0/+22
|\ | | | | | | | | | | Pull Huawei LEDS and hotkey support. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: hda: add support for Huawei WMI micmute LEDAyman Bagabas2018-12-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Some of Huawei laptops come with a LED in the micmute key. This patch enables the use of micmute LED for these devices: 1. Matebook X (19e5:3200), (19e5:3201) 2. Matebook X Pro (19e5:3204) Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ayman Bagabas <ayman.bagabas@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: hda: fix front speakers on Huawei MBXPAyman Bagabas2018-12-131-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch solves bug 200501 'Only 2 of 4 speakers playing sound.' It enables the front speakers on Huawei Matebook X Pro laptops. These laptops come with Dolby Atmos sound system and these pins configuration enables the front speakers. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200501 Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ayman Bagabas <ayman.bagabas@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | Merge branch 'topic/hda-pm-refactor' into for-nextTakashi Iwai2018-12-135-163/+98Star
|\ \ | | | | | | | | | | | | | | | Pull refactoring / fixes of HD-audio PM and display power management Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/hdmi: Always set display_power_control for Intel HSW+ codecsTakashi Iwai2018-12-111-5/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've excluded the display_power_control flag for Intel HSW and BDW codecs as the HD-audio controllers of the corresponding platforms take care of the display power as well. But the recent refactoring separates the controller and the codec power accounting, so it's fine to call the display PM even for HSW/BDW codecs. This is less confusing since we can avoid this well-hidden condition. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda: Make snd_hdac_display_power() void functionTakashi Iwai2018-12-111-8/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | After the recent refactoring, snd_hdac_display_power() doesn't return any error, hence it can be defined to return void. This makes many error checks redundant and allows us to reduce them gracefully. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/intel: Properly free the display power at error pathTakashi Iwai2018-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | When an error occurs in azx_probe_continue(), we should release the display power. However, the current code ignores it and releases the display power only for HSW/BDW cases. Fix it. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/intel: Drop superfluous AZX_DCAPS_I915_POWERWELL checksTakashi Iwai2018-12-112-51/+28Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | snd_hdac_display_power() can be called even for a HDA controller without DRM binding. The same is true for other helpers, snd_hdac_i915_set_bclk() and snd_hdac_set_codec_wakeup(). So all superfluous AZX_DCAPS_I915_POWERWELL checks in hda_intel.c can be dropped, and the definition of AZX_DCAPS_I915_POWERWELL itself can be removed as well. This simplifies the code a lot. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda: Refactor display power managementTakashi Iwai2018-12-114-31/+22Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current HD-audio code manages the DRM audio power via too complex redirections, and this seems even still unbalanced in a corner case as Intel DRM CI has been intermittently reporting. This patch is a big surgery for addressing the complexity and the possible unbalance. Basically the patch changes the display PM in the following ways: - Both HD-audio controller and codec drivers call a single helper, snd_hdac_display_power(). (Formerly, the display power control from a codec was done indirectly via link_power bus ops.) - snd_hdac_display_power() receives the codec address index. For turning on/off from the controller, pass HDA_CODEC_IDX_CONTROLLER. - snd_hdac_display_power() doesn't manage refcounts any longer, but keeps the power status in bitmap. If any of controller or codecs is turned on, the function updates the DRM power state via get_power() or put_power(). Also this refactor allows us more cleanup: - The link_power bus ops is dropped, so there is no longer indirect management, as mentioned in the above. - hdac_device link_power_control flag is moved to hda_codec display_power_control flag, as it's only for HDA legacy. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106525 Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/intel: Refactoring PM codeTakashi Iwai2018-12-091-91/+69Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make unified suspend / resume helpers and call them from both the runtime- and the system-PM callbacks for simplifying code. There are slight changes of call orders, but there shouldn't be any functional difference after refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: hda/ca0132 - make pci_iounmap() call conditionalArnd Bergmann2018-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building without CONFIG_PCI, we can (depending on the architecture) get a link failure: ERROR: "pci_iounmap" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined! Adding a compile-time check for PCI gets it to work correctly on 32-bit ARM. Fixes: d99501b8575d ("ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | Merge branch 'for-linus' into for-nextTakashi Iwai2018-12-101-0/+44
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Back-merge for resolving the conflict of fixup entries added in both branches. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | | ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294Jian-Hong Pan2018-12-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ASUS UX433FN and UX333FA with ALC294 cannot detect the headset MIC and output through the internal speaker and the headphone until ALC294_FIXUP_ASUS_SPK and ALC294_FIXUP_ASUS_HEADSET_MIC quirk applied. Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | | ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294Jian-Hong Pan2018-12-101-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ASUS UX533FD with ALC294 cannot detect the headset MIC and outputs through the internal speaker and the headphone until ALC294_FIXUP_ASUS_SPK and ALC294_FIXUP_ASUS_HEADSET_MIC quirk applied. Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | | ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UNChris Chiu2018-12-101-0/+15
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack sensing and enable use of the internal microphone on this laptop X542UN. However, it's ALC294 so create a new fixup named ALC294_FIXUP_ASUS_MIC to avoid confusion. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Chris Chiu <chiu@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/realtek - Fix the mute LED regresion on Lenovo X1 CarbonHui Wang2018-12-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users reported a mute LED regression on Lenovo X1 Carbon, the root cause is we applied the fixup of ALC285_FIXUP_LENOVO_HEADPHONE_NOISE to this machine, then the machine can't apply the fixup of ALC269_FIXUP_THINKPAD_ACPI anymore. To fix it, we chain two fixup together. Fixes: c4cfcf6f4297 ("ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops") Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: hda/realtek - Enable headset button support for new codecKailang Yang2018-12-071-0/+66
| | | | | | | | | | | | | | | | | | | | | This patch will enable headset button for new Chrome platform. Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: hda - Add jack button supportTakashi Iwai2018-12-073-10/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend some structs to add the support for jack button changes. Now snd_hda_jack_add_kctl() receives two more arguments: the jack type and the jack keymaps. Both are optional, and when zero are passed, the function behaves just like before. For reporting button state changes, you'd need to update jack->button_state bits accordingly, typically in the jack callback. Then the value OR'ed with button_state and the jack plug state is passed to snd_jack_report(). Note that currently the code assumes only the one-shot button events, i.e. it tries to send the button release soon after sending the button event. If a driver really supports the button release handling by itself, we may need to introduce some flag to control this behavior in future. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | ALSA: hda - Add jack pointer and unsolicited event bits to callbackTakashi Iwai2018-12-072-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | For allowing the callee to evaluate the associated jack information and the unsolicited event data, add the new fields to hda_jack_callback. They can be used, for example, to retrieve the headset button state in the callback. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | Merge branch 'for-linus' into for-nextTakashi Iwai2018-12-072-0/+99
|\| | | | | | | | | | | | | | | | | | | | Back-merge for applying the more HD-audio quirks on top of the latest code. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/realtek - Fixed headphone issue for ALC700Kailang Yang2018-12-071-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If it plugged headphone or headset into the jack, then do the reboot, it will have a chance to cause headphone no sound. It just need to run the headphone mode procedure after boot time. The issue will be fixed. It also suitable for ALC234 ALC274 and ALC294. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860GChris Chiu2018-12-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues with the input from external microphone. The issue can be fixed by the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Chris Chiu <chiu@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660GChris Chiu2018-12-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Acer AIO Veriton Z4660G with ALC286 codec has issue with the input from external microphones connecting via 'Front Mic' jack. The fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of the headset and fix the audio input issue of external microphone. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Chris Chiu <chiu@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset micChris Chiu2018-12-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Acer AIO Aspire C24-860 with ALC286 can't detect the headset microphone. Just like another Acer AIO U27-880, it needs a different pin value for 0x18 and the headset fixup to make headset mic work. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Chris Chiu <chiu@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880Chris Chiu2018-12-051-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Acer Aspire U27-880(AIO) with ALC286 codec can not detect headset mic and internal mic not working either. It needs the similar quirk like Sony laptops to fix headphone jack sensing and enables use of the internal microphone. Unfortunately jack sensing for the headset mic is still not working. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Chris Chiu <chiu@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570Takashi Iwai2018-12-031-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've got a regression report for some Thinkpad models (at least T570s) which shows the too low speaker output volume. The bisection leaded to the commit 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform"), and it's basically adding the two pin configurations for the dock, and looks harmless. The real culprit seems, though, that the DAC assignment for the speaker pin is implicitly assumed on these devices, i.e. pin NID 0x14 to be coupled with DAC NID 0x03. When more pins are configured by the commit above, the auto-parser changes the DAC assignment, and this resulted in the regression. As a workaround, just provide the fixed pin / DAC mapping table for this Thinkpad fixup function. It's no generic solution, but the problem itself is pretty much device-specific, so must be good enough. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1554304 Fixes: 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform") Cc: <stable@vger.kernel.org> Reported-and-tested-by: Jeremy Cline <jcline@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | ALSA: hda: Add support for AMD Stoney RidgeKai-Heng Feng2018-11-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | It's similar to other AMD audio devices, it also supports D3, which can save some power drain. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-20 15:15:03 +0200