Skip to content
  1. Oct 18, 2021
    • Takashi Iwai's avatar
      ALSA: memalloc: Support for non-contiguous page allocation · a25684a9
      Takashi Iwai authored
      This patch adds the support for allocation of non-contiguous DMA pages
      in the common memalloc helper.  It's another SG-buffer type, but
      unlike the existing one, this is directional and requires the explicit
      sync / invalidation of dirty pages on non-coherent architectures.
      
      For this enhancement, the following points are changed:
      - snd_dma_device stores the DMA direction.
      - snd_dma_device stores need_sync flag indicating whether the explicit
        sync is required or not.
      - A new variant of helper functions, snd_dma_alloc_dir_pages() and
        *_all() are introduced; the old snd_dma_alloc_pages() and *_all()
        kept as just wrappers with DMA_BIDIRECTIONAL.
      - A new helper snd_dma_buffer_sync() is introduced; this gets called
        in the appropriate places.
      - A new allocation type, SNDRV_DMA_TYPE_NONCONTIG, is introduced.
      
      When the driver allocates pages with this new type, and it may require
      the SNDRV_PCM_INFO_EXPLICIT_SYNC flag set to the PCM hardware.info for
      taking the full control of PCM applptr and hwptr changes (that implies
      disabling the mmap of control/status data).  When the buffer
      allocation is managed by snd_pcm_set_managed_buffer(), this flag is
      automatically set depending on the result of dma_need_sync()
      internally.  Otherwise, if the buffer is managed manually, the driver
      has to set the flag explicitly, too.
      
      The explicit sync between CPU and device for non-coherent memory is
      performed at the points before and after read/write transfer as well
      as the applptr/hwptr syncptr ioctl.  In the case of mmap mode,
      user-space is supposed to call the syncptr ioctl with the hwptr flag
      to update and fetch the status at first; this corresponds to CPU-sync.
      Then user-space advances the applptr via syncptr ioctl again with
      applptr flag, and this corresponds to the device sync with flushing.
      
      Other than the DMA direction and the explicit sync, the usage of this
      new buffer type is almost equivalent with the existing
      SNDRV_DMA_TYPE_DEV_SG; you can get the page and the address via
      snd_sgbuf_get_page() and snd_sgbuf_get_addr(), also calculate the
      continuous pages via snd_sgbuf_get_chunk_size().
      
      For those SG-page handling, the non-contig type shares the same ops
      with the vmalloc handler.  As we do always vmap the SG pages at first,
      the actual address can be deduced from the vmapped address easily
      without iterating the SG-list.
      
      Link: https://lore.kernel.org/r/20211017074859.24112-2-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a25684a9
  2. Oct 17, 2021
    • Randy Dunlap's avatar
      ALSA: ISA: not for M68K · 3c05f147
      Randy Dunlap authored
      
      
      On m68k, compiling drivers under SND_ISA causes build errors:
      
      ../sound/core/isadma.c: In function 'snd_dma_program':
      ../sound/core/isadma.c:33:17: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration]
         33 |         flags = claim_dma_lock();
            |                 ^~~~~~~~~~~~~~
      ../sound/core/isadma.c:41:9: error: implicit declaration of function 'release_dma_lock' [-Werror=implicit-function-declaration]
         41 |         release_dma_lock(flags);
            |         ^~~~~~~~~~~~~~~~
      
      ../sound/isa/sb/sb16_main.c: In function 'snd_sb16_playback_prepare':
      ../sound/isa/sb/sb16_main.c:253:72: error: 'DMA_AUTOINIT' undeclared (first use in this function)
        253 |         snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_WRITE | DMA_AUTOINIT);
            |                                                                        ^~~~~~~~~~~~
      ../sound/isa/sb/sb16_main.c:253:72: note: each undeclared identifier is reported only once for each function it appears in
      ../sound/isa/sb/sb16_main.c: In function 'snd_sb16_capture_prepare':
      ../sound/isa/sb/sb16_main.c:322:71: error: 'DMA_AUTOINIT' undeclared (first use in this function)
        322 |         snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_READ | DMA_AUTOINIT);
            |                                                                       ^~~~~~~~~~~~
      
      and more...
      
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Link: https://lore.kernel.org/r/20211016062602.3588-1-rdunlap@infradead.org
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3c05f147
  3. Oct 15, 2021
  4. Oct 14, 2021
  5. Oct 13, 2021
    • Jonas Hahnfeld's avatar
      ALSA: usb-audio: Add quirk for VF0770 · 48827e1d
      Jonas Hahnfeld authored
      
      
      The device advertises 8 formats, but only a rate of 48kHz is honored
      by the hardware and 24 bits give chopped audio, so only report the
      one working combination. This fixes out-of-the-box audio experience
      with PipeWire which otherwise attempts to choose S24_3LE (while
      PulseAudio defaulted to S16_LE).
      
      Signed-off-by: default avatarJonas Hahnfeld <hahnjo@hahnjo.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      48827e1d
    • Kai Vehmanen's avatar
      ALSA: hda: avoid write to STATESTS if controller is in reset · b37a1518
      Kai Vehmanen authored
      The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
      before performing controller reset. This code dates back to an old
      bugfix in commit e8a7f136 ("[ALSA] hda-intel - Improve HD-audio
      codec probing robustness"). Originally the code was added to
      azx_reset().
      
      The code was moved around in commit a41d1224 ("ALSA: hda - Embed bus
      into controller object") and ended up to snd_hdac_bus_reset_link() and
      called primarily via snd_hdac_bus_init_chip().
      
      The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
      called when controller is not in reset. In this case, STATESTS can be
      cleared. This can be useful e.g. when forcing a controller reset to retry
      codec probe. A normal non-power-on reset will not clear the bits.
      
      However, this old logic is problematic when controller is already in
      reset. The HDA specification states that controller must be taken out of
      reset before writing to registers other than GCTL.CRST (1.0a...
      b37a1518
  6. Oct 12, 2021
    • Takashi Iwai's avatar
      ALSA: usb-audio: Less restriction for low-latency playback mode · 53451b6d
      Takashi Iwai authored
      The recent support for the improved low-latency playback mode applied
      the SNDRV_PCM_INFO_EXPLICIT_SYNC flag for the target streams, but this
      was a slight overkill.  The use of the flag above disables effectively
      both PCM status and control mmaps, while basically what we want to
      track is only about the appl_ptr update.
      
      For less restriction, use a more proper flag,
      SNDRV_PCM_INFO_SYNC_APPLPTR instead, which disables only the control
      mmap.
      
      Fixes: d5f871f8 ("ALSA: usb-audio: Improved lowlatency playback support")
      Link: https://lore.kernel.org/r/20211011103650.10182-1-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      53451b6d
    • Hui Wang's avatar
      ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW · a3fd1a98
      Hui Wang authored
      We need to define the codec pin 0x1b to be the mic, but somehow
      the mic doesn't support hot plugging detection, and Windows also has
      this issue, so we set it to phantom headset-mic.
      
      Also the determine_headset_type() often returns the omtp type by a
      mistake when we plug a ctia headset, this makes the mic can't record
      sound at all. Because most of the headset are ctia type nowadays and
      some machines have the fixed ctia type audio jack, it is possible this
      machine has the fixed ctia jack too. Here we set this mic jack to
      fixed ctia type, this could avoid the mic type detection mistake and
      make the ctia headset work stable.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537
      
      
      Reported-and-tested-by: default avatarmsd <msd.mmq@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.com
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a3fd1a98
    • Takashi Iwai's avatar
      ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl · 228af5a4
      Takashi Iwai authored
      Michael Forney reported an incorrect padding type that was defined in
      the commit 80fe7430 ("ALSA: add new 32-bit layout for
      snd_pcm_mmap_status/control") for PCM control mmap data.
      His analysis is correct, and this caused the misplacements of PCM
      control data on 32bit arch and 32bit compat mode.
      
      The bug is that the __pad2 definition in __snd_pcm_mmap_control64
      struct was wrongly with __pad_before_uframe, which should have been
      __pad_after_uframe instead.  This struct is used in SYNC_PTR ioctl and
      control mmap.  Basically this bug leads to two problems:
      
      - The offset of avail_min field becomes wrong, it's placed right after
        appl_ptr without padding on little-endian
      
      - When appl_ptr and avail_min are read as 64bit values in kernel side,
        the values become either zero or corrupted (mixed up)
      
      One good news is that, because both user-space and kernel
      misunderstand the wrong offset, at least, 32bit application running on
      32bit kernel wor...
      228af5a4
  7. Oct 11, 2021
  8. Oct 07, 2021
  9. Oct 06, 2021
    • Werner Sembach's avatar
      ALSA: hda/realtek: Add quirk for TongFang PHxTxX1 · dd6dd6e3
      Werner Sembach authored
      
      
      This applies a SND_PCI_QUIRK(...) to the TongFang PHxTxX1 barebone. This
      fixes the issue of the internal Microphone not working after booting
      another OS.
      
      When booting a certain another OS this barebone keeps some coeff settings
      even after a cold shutdown. These coeffs prevent the microphone detection
      from working in Linux, making the Laptop think that there is always an
      external microphone plugged-in and therefore preventing the use of the
      internal one.
      
      The relevant indexes and values where gathered by naively diff-ing and
      reading a working and a non-working coeff dump.
      
      Signed-off-by: default avatarWerner Sembach <wse@tuxedocomputers.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20211006130415.538243-1-wse@tuxedocomputers.com
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dd6dd6e3
  10. Oct 05, 2021
  11. Oct 04, 2021
  12. Oct 01, 2021
  13. Sep 30, 2021
    • Takashi Iwai's avatar
      ALSA: seq: Fix a potential UAF by wrong private_free call order · 1f8763c5
      Takashi Iwai authored
      John Keeping reported and posted a patch for a potential UAF in
      rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be
      called after the associated rawmidi object got already freed.
      After a deeper look, it turned out that the bug is rather the
      incorrect private_free call order for a snd_seq_device.  The
      snd_seq_device private_free gets called at the release callback of the
      sequencer device object, while this was rather expected to be executed
      at the snd_device call chains that runs at the beginning of the whole
      card-free procedure.  It's been broken since the rewrite of
      sequencer-device binding (although it hasn't surfaced because the
      sequencer device release happens usually right along with the card
      device release).
      
      This patch corrects the private_free call to be done in the right
      place, at snd_seq_device_dev_free().
      
      Fixes: 7c37ae5c
      
       ("ALSA: seq: Rewrite sequencer device binding with standard bus")
      Reported-and-tested-by: default avatarJohn Keeping <john@metanate.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1f8763c5
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid killing in-flight URBs during draining · 813a17ca
      Takashi Iwai authored
      While draining a stream, ALSA PCM core stops the stream by issuing
      snd_pcm_stop() after all data has been sent out.  And, at PCM trigger
      stop, currently USB-audio driver kills the in-flight URBs explicitly,
      then at sync-stop ops, sync with the finish of all remaining URBs.
      This might result in a drop of the drained samples as most of
      USB-audio devices / hosts allow relatively long in-flight samples (as
      a sort of FIFO).
      
      For avoiding the trimming, this patch changes the stream-stop behavior
      during PCM draining state.  Under that condition, the pending URBs
      won't be killed.  The leftover in-flight URBs are caught by the
      sync-stop operation that shall be performed after the trigger-stop
      operation.
      
      Link: https://lore.kernel.org/r/20210929080844.11583-10-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      813a17ca