Skip to content

L
linux
Switch branch/tag
  1. 26 Jan, 2020 3 commits
  3. 23 Jan, 2020 1 commit
  5. 22 Jan, 2020 1 commit
  7. 21 Jan, 2020 3 commits
    • Kai Vehmanen's avatar
      ALSA: hda/hdmi - add retry logic to parse_intel_hdmi() · 2928fa0a
      Kai Vehmanen authored 
      The initial snd_hda_get_sub_node() can fail on certain
devices (e.g. some Chromebook models using Intel GLK).
The failure rate is very low, but as this is is part of
the probe process, end-user impact is high.

In observed cases, related hardware status registers have
expected values, but the node query still fails. Retrying
the node query does seem to help, so fix the problem by
adding retry logic to the query. This does not impact
non-Intel platforms.

BugLink: https://github.com/thesofproject/linux/issues/1642Signed-off-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200120160117.29130-4-kai.vehmanen@linux.intel.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2928fa0a
    • 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
  9. 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
  11. 17 Jan, 2020 1 commit
  13. 16 Jan, 2020 4 commits
  15. 15 Jan, 2020 2 commits
  17. 14 Jan, 2020 4 commits
  19. 13 Jan, 2020 17 commits
  21. 12 Jan, 2020 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7