Skip to content

L
linux
Switch branch/tag
  1. 21 Jan, 2020 2 commits
    • Takashi Iwai's avatar
      ALSA: hda: No preallocation on x86 platforms · c31427d0
      Takashi Iwai authored 
      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.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c31427d0
    • Takashi Iwai's avatar
      ALSA: pcm: Set per-card upper limit of PCM buffer allocations · d4cfb30f
      Takashi Iwai authored 
      Currently, the available buffer allocation size for a PCM stream
depends on the preallocated size; when a buffer has been preallocated,
the max buffer size is set to that size, so that application won't
re-allocate too much memory.  OTOH, when no preallocation is done,
each substream may allocate arbitrary size of buffers as long as
snd_pcm_hardware.buffer_bytes_max allows -- which can be quite high,
HD-audio sets 1GB there.

It means that the system may consume a high amount of pages for PCM
buffers, and they are pinned and never swapped out.  This can lead to
OOM easily.

For avoiding such a situation, this patch adds the upper limit per
card.  Each snd_pcm_lib_malloc_pages() and _free_pages() calls are
tracked and it will return an error if the total amount of buffers
goes over the defined upper limit.  The default value is set to 32MB,
which should be really large enough for usual operations.

If larger buffers are needed for any specific usage, it can be
adjusted (also dynamically) via snd_pcm.max_alloc_per_card option.
Setting zero there means no chceck is performed, and again, unlimited
amount of buffers are allowed.

Link: https://lore.kernel.org/r/20200120124423.11862-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d4cfb30f
  3. 20 Jan, 2020 2 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 9d0af44c
      Takashi Iwai authored 
      Resolved the merge conflict in HD-audio Tegra driver.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9d0af44c
    • Takashi Iwai's avatar
      ALSA: hda: Apply aligned MMIO access only conditionally · 4d024fe8
      Takashi Iwai authored 
      It turned out that the recent simplification of HD-audio bus access
helpers caused a regression on the virtual HD-audio device on QEMU
with ARM platforms.  The driver got a CORB/RIRB timeout and couldn't
probe any codecs.

The essential difference that caused a problem was the enforced
aligned MMIO accesses by simplification.  Since snd-hda-tegra driver
is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes
the all HD-audio drivers using the aligned MMIO accesses.  While this
is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM
gets broken by this access pattern.

For addressing the regression, this patch introduces a new flag,
aligned_mmio, to hdac_bus object, and applies the aligned MMIO only
when this flag is set.  This change affects only platforms with
CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms.

Unfortunately the patch became a big bigger than it should be, just
because the former calls didn't take hdac_bus object in the argument,
hence we had to extend the call patterns.

Fixes: 19abfefd ("ALSA: hda: Direct MMIO accesses")
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4d024fe8
  5. 17 Jan, 2020 1 commit
  7. 16 Jan, 2020 4 commits
  9. 15 Jan, 2020 2 commits
  11. 14 Jan, 2020 4 commits
  13. 13 Jan, 2020 17 commits
  15. 12 Jan, 2020 3 commits
  17. 11 Jan, 2020 2 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 3cdca6d6
      Takashi Iwai authored 
      Sync 5.5-devel branch once again for applying the HD-audio fixes.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3cdca6d6
    • Takashi Iwai's avatar
      ALSA: hda: Rename back to dmic_detect option · 7fba6aea
      Takashi Iwai authored 
      We've got quite a few bug reports showing the SOF driver being loaded
unintentionally recently, and the reason seems to be that users didn't
know the module option change: with the recent kernel, a new option
dsp_driver=1 has to be passed to a new module snd-intel-dspcfg
instead of snd_hda_intel.dmic_detect=0 option.

That is, actually there are two tricky things here:
- We changed the whole detection in another module and another
  option semantics.
- The existing option for skipping the DSP probe was also renamed.

For avoiding the confusion and giving user more hint, this patch
reverts the renamed option dsp_driver back to dmic_detect for
snd-hda-intel module, and show the warning about the module option
change when the non-default value is passed.

Fixes: 82d9d54a ("ALSA: hda: add Intel DSP configuration / probe code")
Link: https://lore.kernel.org/r/20200109082000.26729-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7fba6aea
  19. 10 Jan, 2020 1 commit
  21. 09 Jan, 2020 1 commit
    • Olivier Moysan's avatar
      ASoC: stm32: sai: fix possible circular locking · a14bf98c
      Olivier Moysan authored 
      In current driver, locks can be taken as follows:
- Register access: take a lock on regmap config and then on clock.
- Master clock provider: take a lock on clock and then on regmap config.
This can lead to the circular locking summarized below.

Remove peripheral clock management through regmap framework, and manage
peripheral clock in driver instead. On register access, lock on clock
is taken first, which allows to avoid possible locking issue.

[ 6696.561513] ======================================================
[ 6696.567670] WARNING: possible circular locking dependency detected
[ 6696.573842] 4.19.49 #866 Not tainted
[ 6696.577397] ------------------------------------------------------
[ 6696.583566] pulseaudio/6439 is trying to acquire lock:
[ 6696.588697] 87b0a25b (enable_lock){..-.}, at: clk_enable_lock+0x64/0x128
[ 6696.595377]
[ 6696.595377] but task is already holding lock:
[ 6696.601197] d858f825 (stm32_sai_sub:1342:(sai->regmap_config)->lock){....}
...
[ 6696.812513]  Possible unsafe locking scenario:
[ 6696.812513]
[ 6696.818418]        CPU0                    CPU1
[ 6696.822935]        ----                    ----
[ 6696.827451]   lock(stm32_sai_sub:1342:(sai->regmap_config)->lock);
[ 6696.833618]                                lock(enable_lock);
[ 6696.839350]                                lock(stm32_sai_sub:1342:
                                              (sai->regmap_config)->lock);
[ 6696.848035]   lock(enable_lock);

Fixes: 03e78a24 ("ASoC: stm32: sai: add h7 support")
Signed-off-by: default avatarOlivier Moysan <olivier.moysan@st.com>
Link: https://lore.kernel.org/r/20200109083254.478-1-olivier.moysan@st.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      a14bf98c
  23. 08 Jan, 2020 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7