summaryrefslogtreecommitdiff
path: root/sound/hda
AgeCommit message (Collapse)AuthorFilesLines
2020-02-18Merge tag 'asoc-fix-v5.6-rc2' of ↵Takashi Iwai1-3/+6
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.6 A few fixes sent in since the merge window, none of them with global impact but all important for the users they affect.
2020-02-18ALSA: hda: Use scnprintf() for printing texts for sysfs/procfsTakashi Iwai1-1/+1
Some code in HD-audio driver calls snprintf() in a loop and still expects that the return value were actually written size, while snprintf() returns the expected would-be length instead. When the given buffer limit were small, this leads to a buffer overflow. Use scnprintf() for addressing those issues. It returns the actually written size unlike snprintf(). Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200218091409.27162-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-02-10ALSA: hda: do not override bus codec_mask in link_get()Kai Vehmanen1-3/+6
snd_hdac_ext_bus_link_get() does not work correctly in case there are multiple codecs on the bus. It unconditionally resets the bus->codec_mask value. As per documentation in hdaudio.h and existing use in client code, this field should be used to store bit flag of detected codecs on the bus. By overwriting value of the codec_mask, information on all detected codecs is lost. No current user of hdac is impacted, but use of bus->codec_mask is planned in future patches for SOF. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200206200223.7715-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-28ALSA: hda: Reset stream if DMA RUN bit not clearedMohan Kumar1-12/+19
Tegra HDA has FIFO size which can hold upto 10 audio frames to support DVFS. When HDA DMA RUN bit is set to 0 to stop the stream, the DMA RUN bit will be cleared to 0 only after transferring all the remaining audio frames queued up in the fifo. This is not in sync with spec which states the controller will stop transmitting(output) in the beginning of the next frame for the relevant stream. The above behavior with Tegra HDA was resulting in machine check error during the system suspend flow with active audio playback with below kernel error logs. [ 33.524583] mc-err: [mcerr] (hda) csr_hdar: EMEM address decode error [ 33.531088] mc-err: [mcerr] status = 0x20000015; addr = 0x00000000 [ 33.537431] mc-err: [mcerr] secure: no, access-type: read, SMMU fault: none This was due to the fifo has more than one audio frame when the DMA RUN bit is set to 0 during system suspend flow and the timeout handling in snd_hdac_stream_sync() was not designed to handle this scenario. So the DMA will continue running even after timeout hit until all remaining audio frames in the fifo are transferred, but the suspend flow will try to reset the controller and turn off the hda clocks without the knowledge of the DMA is still running and could result in mc-err. The above issue can be resolved by doing stream reset with the help of snd_hdac_stream_reset() which would ensure the DMA RUN bit is cleared if the timeout was hit in snd_hdac_stream_sync(). Signed-off-by: Mohan Kumar <mkumard@nvidia.com> Link: https://lore.kernel.org/r/20200128051508.26064-1-mkumard@nvidia.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-21ALSA: hda: No preallocation on x86 platformsTakashi Iwai1-2/+4
Like many other drivers, HD-audio drivers also do PCM buffer preallocation to assure the buffer pages allocated at the early boot stage. This step is useful for platforms that may fail to allocate the PCM hardware buffers -- which is mostly for either large continuous pages or with the specific DMA mask (like emu10k1). OTOH, when a buffer is allocated as SG-buffer and the DMA mask is either 32 or 64 bits, the allocation almost never fails unless it hits the real OOM situation. In such a case, we don't need the preallocation inevitably unlike the cases above. That said, we may drop the preallocation for HD-audio that does allocate via SG-buffers, and the patch achieves it. However, there is one caveat: the buffer allocation behavior depends on CONFIG_SND_DMA_SGBUF, and it falls back to the continuous pages when it's not set. And, currently this SG buffer allocation is enabled only on x86 platforms. So, covering those fall-outs, the patch adjusts CONFIG_SND_HDA_PREALLOC_SIZE depending on the condition, and keeps the old behavior as-is for non-x86 platforms. On x86, the kconfig item is no longer adjustable but always set to zero for disabling the preallocation. You can still enable the preallocation via procfs interface at any time later, too. Link: https://lore.kernel.org/r/20200120124423.11862-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-14ALSA: hda: Update kernel-doc function parameter descriptionsKeyon Jie8-18/+28
Make W=1 throws a lot of warnings, with multiple misalignments between function params and their descriptions. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200113205638.27338-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-13ALSA: hda: Manage concurrent reg access more properlyTakashi Iwai2-35/+108
In the commit 8e85def5723e ("ALSA: hda: enable regmap internal locking"), we re-enabled the regmap lock due to the reported regression that showed the possible concurrent accesses. It was a temporary workaround, and there are still a few opened races even after the revert. In this patch, we cover those still opened windows with a proper mutex lock and disable the regmap internal lock again. First off, the patch introduces a new snd_hdac_device.regmap_lock mutex that is applied for each snd_hdac_regmap_*() call, including read, write and update helpers. The mutex is applied carefully so that it won't block the self-power-up procedure in the helper function. Also, this assures the protection for the accesses without regmap, too. The snd_hdac_regmap_update_raw() is refactored to use the standard regmap_update_bits_check() function instead of the open-code. The non-regmap case is still open-coded but it's an easy part. The all read and write operations are in the single mutex protection, so it's now race-free. In addition, a couple of new helper functions are added: snd_hdac_regmap_update_raw_once() and snd_hdac_regmap_sync(). Both are called from HD-audio legacy driver. The former is to initialize the given verb bits but only once when it's not initialized yet. Due to this condition, the function invokes regcache_cache_only(), and it's now performed inside the regmap_lock (formerly it was racy) too. The latter function is for simply invoking regcache_sync() inside the regmap_lock, which is called from the codec resume call path. Along with that, the HD-audio codec driver code is slightly modified / simplified to adapt those new functions. And finally, snd_hdac_regmap_read_raw(), *_write_raw(), etc are rewritten with the helper macro. It's just for simplification because the code logic is identical among all those functions. Tested-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200109090104.26073-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-11Merge branch 'for-linus' into for-nextTakashi Iwai1-1/+0
Sync 5.5-devel branch once again for applying the HD-audio fixes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-08ALSA: hda: enable regmap internal lockingKai Vehmanen1-1/+0
This reverts commit 42ec336f1f9d ("ALSA: hda: Disable regmap internal locking"). Without regmap locking, there is a race between snd_hda_codec_amp_init() and PM callbacks issuing regcache_sync(). This was caught by following kernel warning trace: <4> [358.080081] WARNING: CPU: 2 PID: 4157 at drivers/base/regmap/regcache.c:498 regcache_cache_only+0xf5/0x130 [...] <4> [358.080148] Call Trace: <4> [358.080158] snd_hda_codec_amp_init+0x4e/0x100 [snd_hda_codec] <4> [358.080169] snd_hda_codec_amp_init_stereo+0x40/0x80 [snd_hda_codec] Suggested-by: Takashi Iwai <tiwai@suse.de> BugLink: https://gitlab.freedesktop.org/drm/intel/issues/592 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200108180856.5194-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-08ALSA: hda: Fix a typo in commentsTakashi Iwai1-1/+1
Link: https://lore.kernel.org/r/20200108153430.31456-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-05ALSA: hda: More constificationsTakashi Iwai3-4/+4
Apply const prefix to the remaining possible places: the string tables, the rate tables, the verb tables, the index tables, etc. Just for minor optimization and no functional changes. Link: https://lore.kernel.org/r/20200105144823.29547-10-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-18Merge branch 'for-linus' into for-nextTakashi Iwai1-3/+1
Taking the 5.5 devel branch back into the main devel branch. A USB-audio fix needs to be adjusted to adapt the changes that have been formerly applied for stop_sync. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-14ALSA: hda: Comment about snd_hdac_bus_update_rirb() and spinlockTakashi Iwai1-0/+1
The call of snd_hdac_bus_update_rirb() needs the bus->reg_lock spinlock protection for concurrency. Comment about it more explicitly. Link: https://lore.kernel.org/r/20191213163005.19116-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-14ALSA: hda: Fix regression by strip mask fixTakashi Iwai1-3/+1
The commit e38e486d66e2 ("ALSA: hda: Modify stream stripe mask only when needed") tried to address the regression by the unconditional application of the stripe mask, but this caused yet another regression for the previously working devices. Namely, the patch clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this may be called multiple times before restarting the stream, so this ended up with clearance of the flag for the whole time. This patch fixes the regression by moving the azx_dev->stripe flag clearance at the counter-part, the close callback of HDMI codec driver instead. Fixes: e38e486d66e2 ("ALSA: hda: Modify stream stripe mask only when needed") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205855 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191214175217.31852-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-13ALSA: hda: Unify get_response handlingTakashi Iwai1-1/+10
Now most of the get_response handling became quite similar between HDA-core and legacy drivers, and the only differences are: - the handling of extra-long polling delay for some codecs - the debug message for the stalled communication and both are worth to share in the common code. This patch unifies the code into snd_hdac_bus_get_response(), and use this from the legacy get_response callback. It results in a good amount of code reduction in the end. Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20191212191101.19517-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-13ALSA: hda: Use waitqueue for RIRB in HDA-core helper, tooTakashi Iwai1-2/+14
This patch implements the same logic that was done for the legacy HD-audio controller driver by the commit 88452da92ba2 ("ALSA: hda: Use standard waitqueue for RIRB wakeup") to the HDA-core helper code, too. This makes snd_hdac_bus_get_response() waiting for the response with bus->rirb_wq instead of polling when bus->polling is false. It'll save both CPU time and response latency. Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20191212191101.19517-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-10ALSA: hda: Use standard waitqueue for RIRB wakeupTakashi Iwai2-0/+4
The HD-audio CORB/RIRB communication was programmed in a way that was documented in the reference in decades ago, which is essentially a polling in the waiter side. It's working fine but costs CPU cycles on some platforms that support only slow communications. Also, for some platforms that had unreliable communications, we put longer wait time (2 ms), which accumulate quite long time if you execute many verbs in a shot (e.g. at the initialization or resume phase). This patch attempts to improve the situation by introducing the standard waitqueue in the RIRB waiter side instead of polling. The test results on my machine show significant improvements. The time spent for "cat /proc/asound/card*/codec#*" were changed like: * Intel SKL + Realtek codec before the patch: 0.00user 0.04system 0:00.10elapsed 40.0%CPU after the patch: 0.00user 0.01system 0:00.10elapsed 10.0%CPU * Nvidia GP107GL + Nvidia HDMI codec before the patch: 0.00user 0.00system 0:02.76elapsed 0.0%CPU after the patch: 0.00user 0.00system 0:00.01elapsed 17.0%CPU So, for Intel chips, the total time is same, while the total time is greatly reduced (from 2.76 to 0.01s) for Nvidia chips. The only negative data here is the increase of CPU time for Nvidia, but this is the unavoidable cost for faster wakeups, supposedly. Link: https://lore.kernel.org/r/20191210145727.22054-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-03ALSA: hda: Modify stream stripe mask only when neededTakashi Iwai1-7/+12
The recent commit in HD-audio stream management for changing the stripe control seems causing a regression on some platforms. The stripe control is currently used only by HDMI codec, and applying the stripe mask unconditionally may lead to scratchy and static noises as seen on some MacBooks. For addressing the regression, this patch changes the stream management code to apply the stripe mask conditionally only when the codec driver requested. Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477 Tested-by: Michael Pobega <mpobega@neverware.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191202074947.1617-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-05ALSA: hda: Disable regmap internal lockingTakashi Iwai1-0/+1
Since we apply the own mutex (bus->cmd_mutex) in HDA core side, the internal locking in regmap is superfluous. This patch adds the flag to indicate that. Also, an infamous side-effect by this change is that it disables the regmap debugfs, too, and this is seen rather good; the regmap debugfs isn't quite useful for HD-audio as it provides the very sparse registers and its debugfs access tends to lead to the way too high resource usages or sometimes hang up. So it'd be rather safe to disable it altogether. Link: https://lore.kernel.org/r/2029139028.10333037.1572874551626.JavaMail.zimbra@redhat.com Link: https://lore.kernel.org/r/20191105081806.4896-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-28ALSA: hda: Allow non-Intel device probe gracefullyTakashi Iwai1-4/+4
The recent addition of snd_intel_dsp_driver_probe() check caused a spurious kernel warning when the driver is loaded for a non-Intel hardware due to snd_BUG_ON(). Moreover, for such a hardware, we should always return SND_INTEL_DSP_DRIVER_ANY, not check the dsp_driver option at all. This patch fixes these issues for non-Intel devices. Fixes: 82d9d54a6c0e ("ALSA: hda: add Intel DSP configuration / probe code") Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20191028130634.3501-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-28Merge branch 'for-linus' into for-nextTakashi Iwai2-2/+5
Back-merge the development process for catching up the HD-audio fix (and apply a new one on top of that). Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-28Revert "ALSA: hda: Flush interrupts on disabling"Takashi Iwai1-2/+0
This reverts commit caa8422d01e983782548648e125fd617cadcec3f. It turned out that this commit caused a regression at shutdown / reboot, as the synchronize_irq() calls seems blocking the whole shutdown. Also another part of the change about shuffling the call order looks suspicious; the azx_stop_chip() call disables the CORB / RIRB while the others may still need the CORB/RIRB update. Since the original commit itself was a cargo-fix, let's revert the whole patch. Fixes: caa8422d01e9 ("ALSA: hda: Flush interrupts on disabling") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205333 BugLinK: https://bugs.freedesktop.org/show_bug.cgi?id=111174 Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://lore.kernel.org/r/20191028081056.22010-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-23ALSA: hda: fix intel DSP configPierre-Louis Bossart1-56/+164
Reshuffle list of devices by historical order and add correct information as needed. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20191022174313.29087-2-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-23ALSA: hda: add Intel DSP configuration / probe codeJaroslav Kysela4-7/+260
For distributions, we need one place where we can decide which driver will be activated for the auto-configation of the Intel's HDA hardware with DSP. Actually, we cover three drivers: * Legacy HDA * Intel SST * Intel Sound Open Firmware (SOF) All those drivers registers similar PCI IDs, so the first driver probed from the PCI stack can win. But... it is not guaranteed that the correct driver wins. This commit changes Intel's NHLT ACPI module to a common DSP probe module for the Intel's hardware. All above sound drivers calls this code. The user can force another behaviour using the module parameter 'dsp_driver' located in the 'snd-intel-dspcfg' module. This change allows to add specific dmi checks for the specific systems. The examples are taken from the pull request: https://github.com/thesofproject/linux/pull/927 Tested on Lenovo Carbon X1 7th gen. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191022174313.29087-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-07ALSA: hdac: clear link output stream mappingRander Wang1-0/+5
Fix potential DMA hang upon starting playback on devices in HDA mode on Intel platforms (Gemini Lake/Whiskey Lake/Comet Lake/Ice Lake). It doesn't affect platforms before Gemini Lake or any Intel device in non-HDA mode. The reset value for the LOSDIV register is all output streams valid. Clear this register to invalidate non-existent streams when the bus is powered up. Signed-off-by: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190930142945.7805-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-15Revert "ALSA: hda: Add codec on bus address table lately"Takashi Iwai1-12/+9
This reverts commit ee5f85d9290f ("ALSA: hda: Add codec on bus address table lately"). The commit caused several regression since I've overlooked that the function doesn't manage only the caddr_tbl but also the codec linked list that is referred indirectly in the other drivers. Revert for now to make everything back to work. Fixes: ee5f85d9290f ("ALSA: hda: Add codec on bus address table lately") Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-14ALSA: hda: Unexport a few more stuffTakashi Iwai4-6/+9
Drop EXPORT_SYMBOL*() from a few more stuff in HD-audio core that aren't used outside. Particular the unsol event handler can be staticized now because the recent change removed all external callers. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-14ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()Takashi Iwai2-2/+5
snd_hdac_bus_add_device() and snd_hdac_remove_device() are called only internally in hda-core. Let's drop the exports of them and move the declarations into local.h. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-14ALSA: hda: Add codec on bus address table latelyTakashi Iwai1-9/+12
The call of snd_hdac_bus_add_device() is needed only for registering the codec onto the bus caddr_tbl[] that is referred essentially only in the unsol event handler. That is, the reason of this call and the release by the counter-part function snd_hdac_bus_remove_device() is just to assure that the unsol event gets notified to the codec. But the current implementation of the unsol notification wouldn't work properly when the codec is still in a premature init state. So this patch tries to work around it by delaying the caddr_tbl[] registration at the point of snd_hdac_device_register(). Also, the order of snd_hdac_bus_remove_device() and device_del() calls are shuffled to make sure that the unsol event is masked before deleting the device. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204565 Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-12ALSA: hda: Set fifo_size for both playback and capture streamsTakashi Iwai1-5/+1
Currently we set hdac_stream.fifo_size field only for the playback stream by some odd reason I forgot, while this field isn't referred in any places. Actually this fifo_size field would have been required in the position report correction for VIA chipset, but due to the lack of the fifo_size set for capture streams, snd-hda-intel driver fetches the register by itself. This patch straightens and simplifies the code by setting the fifo_size field for both playback and capture streams, and use it in the HD-audio controller driver. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-09Merge branch 'topic/hda-bus-ops-cleanup' into for-nextTakashi Iwai1-0/+1
Pull the compile fix on arm due to missing include. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-09ALSA: hda: readl/writel need linux/io.hStephen Rothwell1-0/+1
Fixes: 19abfefd4c76 ("ALSA: hda: Direct MMIO accesses") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-08Merge branch 'topic/hda-bus-ops-cleanup' into for-nextTakashi Iwai5-76/+49
Pull HD-audio bus ops cleanups. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-08ALSA: hda: Direct MMIO accessesTakashi Iwai3-50/+35
HD-audio drivers access to the mmio registers indirectly via the corresponding bus->io_ops callbacks. This is because some platform (notably Tegra SoC) requires the word-aligned access. But it's rather a rare case, and other platforms suffer from the penalties by indirect calls unnecessarily. This patch is an attempt to optimize and cleanup for this situation. Now the special aligned access is used only when a new kconfig CONFIG_SND_HDA_ALIGNED_MMIO is set. And the HD-audio core itself provides the aligned MMIO access helpers instead of the driver side. If Kconfig isn't set (as default), the standard helpers like readl() or writel() are used directly. A couple of places in ASoC Intel drivers have the access via io_ops reg_writel(), and they are replaced with the direct writel() calls. And now with this patch, the whole bus->io_ops becomes empty, so it's dropped completely. The bus initialization functions are changed accordingly as well to drop the whole bus->io_ops. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-08ALSA: hda: Remove page allocation redirectionTakashi Iwai4-26/+14
The HD-audio core allocates and releases pages via driver's specific dma_alloc_pages and dma_free_pages ops defined in bus->io_ops. This was because some platforms require the uncached pages and the handling of page flags had to be done locally in the driver code. Since the recent change in ALSA core memory allocator, we can simply pass SNDRV_DMA_TYPE_DEV_UC for the uncached pages, and the only difference became about this type to be passed to the core allocator. That is, it's good time for cleaning up the mess. This patch changes the allocation code in HD-audio core to call the core allocator directly so that we get rid of dma_alloc_pages and dma_free_pages io_ops. If a driver needs the uncached pages, it has to set bus->dma_type right after the bus initialization. This is merely a code refactoring and shouldn't bring any behavior changes. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-06Merge branch 'for-linus' into for-nextTakashi Iwai1-4/+6
Pull 5.3 development branch for further fixes of USB-audio stuff. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-31Merge branch 'topic/hda-dmic' into for-nextTakashi Iwai3-0/+115
Pull HD-audio DMIC probe patchset from Pierre-Louis Bossart Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-31ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometryPierre-Louis Bossart1-1/+5
The NHLT spec defines a VENDOR_DEFINED geometry, which requires reading additional information to figure out the number of microphones. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-31ALSA: hda: move parts of NHLT code to new modulePierre-Louis Bossart3-0/+111
Move parts of the code outside of the Skylake driver to help detect the presence of DMICs (which are not supported by the HDaudio legacy driver). No functionality change (except for the removal of useless OR operations), only indentation and checkpatch fixes, making sure that the code compiles without ACPI and fixing an ACPI leak Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-27ALSA: hda: Fix 1-minute detection delay when i915 module is not availableSamuel Thibault1-4/+6
Distribution installation images such as Debian include different sets of modules which can be downloaded dynamically. Such images may notably include the hda sound modules but not the i915 DRM module, even if the latter was enabled at build time, as reported on https://bugs.debian.org/931507 In such a case hdac_i915 would be linked in and try to load the i915 module, fail since it is not there, but still wait for a whole minute before giving up binding with it. This fixes such as case by only waiting for the binding if the module was properly loaded (or module support is disabled, in which case i915 is already compiled-in anyway). Fixes: f9b54e1961c7 ("ALSA: hda/i915: Allow delayed i915 audio component binding") Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-22ALSA: hda: Flush interrupts on disablingChris Wilson1-0/+2
I was looking at <4> [241.835158] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [241.835181] CPU: 1 PID: 214 Comm: kworker/1:3 Tainted: G U 5.2.0-CI-CI_DRM_6509+ #1 <4> [241.835199] Hardware name: Dell Inc. OptiPlex 745 /0GW726, BIOS 2.3.1 05/21/2007 <4> [241.835234] Workqueue: events snd_hdac_bus_process_unsol_events [snd_hda_core] <4> [241.835256] RIP: 0010:input_handle_event+0x16d/0x5e0 <4> [241.835270] Code: 48 8b 93 58 01 00 00 8b 52 08 89 50 04 8b 83 f8 06 00 00 48 8b 93 00 07 00 00 8d 70 01 48 8d 04 c2 83 e1 08 89 b3 f8 06 00 00 <66> 89 28 66 44 89 60 02 44 89 68 04 8b 93 f8 06 00 00 0f 84 fd fe <4> [241.835304] RSP: 0018:ffffc9000019fda0 EFLAGS: 00010046 <4> [241.835317] RAX: 6b6b6b6ec6c6c6c3 RBX: ffff8880290fefc8 RCX: 0000000000000000 <4> [241.835332] RDX: 000000006b6b6b6b RSI: 000000006b6b6b6c RDI: 0000000000000046 <4> [241.835347] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000001 <4> [241.835362] R10: ffffc9000019faa0 R11: 0000000000000000 R12: 0000000000000004 <4> [241.835377] R13: 0000000000000000 R14: ffff8880290ff1d0 R15: 0000000000000293 <4> [241.835392] FS: 0000000000000000(0000) GS:ffff88803de80000(0000) knlGS:0000000000000000 <4> [241.835409] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [241.835422] CR2: 00007ffe9a99e9b7 CR3: 000000002f588000 CR4: 00000000000006e0 <4> [241.835436] Call Trace: <4> [241.835449] input_event+0x45/0x70 <4> [241.835464] snd_jack_report+0xdc/0x100 <4> [241.835490] snd_hda_jack_report_sync+0x83/0xc0 [snd_hda_codec] <4> [241.835512] snd_hdac_bus_process_unsol_events+0x5a/0x70 [snd_hda_core] <4> [241.835530] process_one_work+0x245/0x610 which has the hallmarks of a worker queued from interrupt after it was supposedly cancelled (note the POISON_FREE), and I could not see where the interrupt would be flushed on shutdown so added the likely suspects. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111174 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-08Merge tag 'asoc-v5.3' of ↵Takashi Iwai14-39/+20
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v5.3 This is a very big update, mainly thanks to Morimoto-san's refactoring work and some fairly large new drivers. - Lots more work on moving towards a component based framework from Morimoto-san. - Support for force disconnecting muxes from Jerome Brunet. - New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant CX2072X, Realtek RT1011 and RT1308. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-07Merge branch 'topic/hda-refresh-cleanup' into for-nextTakashi Iwai2-14/+17
Merge a cleanup for HD-audio widget refresh code Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-05ALSA: hda: Simplify snd_hdac_refresh_widgets()Takashi Iwai2-9/+6
Along with the recent fix for the races of snd_hdac_refresh_widgets() it turned out that the instantiation of widgets sysfs at snd_hdac_sysfs_reinit() could cause a race. The race itself was already covered later by extending the mutex protection range, the commit 98482377dc72 ("ALSA: hda: Fix widget_mutex incomplete protection"), but this also indicated that the call of *_reinit() is basically superfluous, as the widgets shall be created sooner or later from snd_hdac_device_register(). This patch removes the redundant call of snd_hdac_sysfs_reinit() at first. By this removal, the sysfs argument itself in snd_hdac_refresh_widgets() becomes superfluous, too, because the only case sysfs=false is always with codec->widgets=NULL. So, we drop this redundant argument as well. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-01ALSA: hda: Fix widget_mutex incomplete protectionEvan Green1-6/+12
The widget_mutex was introduced to serialize callers to hda_widget_sysfs_{re}init. However, its protection of the sysfs widget array is incomplete. For example, it is acquired around the call to hda_widget_sysfs_reinit(), which actually creates the new array, but isn't still acquired when codec->num_nodes and codec->start_nid is updated. So the lock ensures one thread sets up the new array at a time, but doesn't ensure which thread's value will end up in codec->num_nodes. If a larger num_nodes wins but a smaller array was set up, the next call to refresh_widgets() will touch free memory as it iterates over codec->num_nodes that aren't there. The widget_lock really protects both the tree as well as codec->num_nodes, start_nid, and end_nid, so make sure it's held across that update. It should also be held during snd_hdac_get_sub_nodes(), so that a very old read from that function doesn't end up clobbering a later update. Fixes: ed180abba7f1 ("ALSA: hda: Fix race between creating and refreshing sysfs entries") Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-01Merge branch 'for-linus' into for-nextTakashi Iwai1-1/+0
This back-merge is necessary for adjusting the latest FireWire fix with the recent refactoring in 5.3 development branch. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-01ALSA: hda: Fix a headphone detection issue when using SOFRander Wang1-3/+2
To save power, the hda hdmi driver in ASoC invokes snd_hdac_ext_bus_link_put to disable CORB/RIRB buffers DMA if there is no user of bus and invokes snd_hdac_ext_bus_link_get to set up CORB/RIRB buffers when it is used. Unsolicited responses is disabled in snd_hdac_bus_stop_cmd_io called by snd_hdac_ext_bus_link_put , but it is not enabled in snd_hdac_bus_init_cmd_io called by snd_hdac_ext_bus_link_get. So for put-get sequence, Unsolicited responses is disabled and headphone can't be detected by hda codecs. Now unsolicited responses is only enabled in snd_hdac_bus_reset_link which resets controller. The function is only called for setup of controller. This patch enables Unsolicited responses after RIRB is initialized in snd_hdac_bus_init_cmd_io which works together with snd_hdac_bus_reset_link to set up controller. Tested legacy hda driver and SOF driver on intel whiskeylake. Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-06-26Merge tag 'v5.2-rc6' into asoc-5.3Mark Brown14-37/+14
Linux 5.2-rc6
2019-06-25ALSA: hdac: Fix codec name after machine driver is unloaded and reloadedAmadeusz Sławiński1-2/+6
Currently on each driver reload internal counter is being increased. It causes failure to enumerate driver devices, as they have hardcoded: .codec_name = "ehdaudio0D2", As there is currently no devices with multiple hda codecs and there is currently no established way to reliably differentiate, between them, always assign bus->idx = 0; This fixes a problem when we unload and reload machine driver idx gets incremented, so .codec_name would've needed to be set to "ehdaudio1D2" after first reload and so on. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Acked-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-14Merge tag 'sound-5.2-rc5' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "It might feel like deja vu to receive a bulk of changes at rc5, and it happens again; we've got a collection of fixes for ASoC. Most of fixes are targeted for the newly merged SOF (Sound Open Firmware) stuff and the relevant fixes for Intel platforms. Other than that, there are a few regression fixes for the recent ASoC core changes and HD-audio quirk, as well as a couple of FireWire fixes and for other ASoC codecs" * tag 'sound-5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (54 commits) Revert "ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops" ALSA: ice1712: Check correct return value to snd_i2c_sendbytes (EWS/DMX 6Fire) ALSA: oxfw: allow PCM capture for Stanton SCS.1m ALSA: firewire-motu: fix destruction of data for isochronous resources ASoC: Intel: sst: fix kmalloc call with wrong flags ASoC: core: Fix deadlock in snd_soc_instantiate_card() SoC: rt274: Fix internal jack assignment in set_jack callback ALSA: hdac: fix memory release for SST and SOF drivers ASoC: SOF: Intel: hda: use the defined ppcap functions ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_card ASoC: Intel: cht_bsw_rt5672: fix kernel oops with platform_name override ASoC: Intel: cht_bsw_nau8824: fix kernel oops with platform_name override ASoC: Intel: bytcht_es8316: fix kernel oops with platform_name override ASoC: Intel: cht_bsw_max98090: fix kernel oops with platform_name override ASoC: sun4i-i2s: Add offset to RX channel select ASoC: sun4i-i2s: Fix sun8i tx channel offset mask ASoC: max98090: remove 24-bit format support if RJ is 0 ASoC: da7219: Fix build error without CONFIG_I2C ASoC: SOF: Intel: hda: Fix COMPILE_TEST build error ASoC: SOF: fix DSP oops definitions in FW ABI ...
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 17:16:03 +0000