blackbird-op-linux/sound/hda, branch master

ALSA: hda: Reset stream if DMA RUN bit not cleared

2020-01-28T09:29:41+00:00

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 Link: https://lore.kernel.org/r/20200128051508.26064-1-mkumard@nvidia.com Signed-off-by: Takashi Iwai

ALSA: hda: No preallocation on x86 platforms

2020-01-21T06:12:08+00:00

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

ALSA: hda: Update kernel-doc function parameter descriptions

2020-01-14T06:40:37+00:00

Make W=1 throws a lot of warnings, with multiple misalignments between function params and their descriptions. Signed-off-by: Keyon Jie Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200113205638.27338-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai

ALSA: hda: Manage concurrent reg access more properly

2020-01-13T12:40:41+00:00

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 Link: https://lore.kernel.org/r/20200109090104.26073-1-tiwai@suse.de Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2020-01-11T08:03:40+00:00

Sync 5.5-devel branch once again for applying the HD-audio fixes. Signed-off-by: Takashi Iwai

ALSA: hda: enable regmap internal locking

2020-01-08T19:10:08+00:00

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 BugLink: https://gitlab.freedesktop.org/drm/intel/issues/592 Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200108180856.5194-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai

ALSA: hda: Fix a typo in comments

2020-01-08T15:35:00+00:00

Link: https://lore.kernel.org/r/20200108153430.31456-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: More constifications

2020-01-05T15:14:32+00:00

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

Merge branch 'for-linus' into for-next

2019-12-18T19:07:43+00:00

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

ALSA: hda: Comment about snd_hdac_bus_update_rirb() and spinlock

2019-12-14T17:56:06+00:00

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