1. 18 Oct, 2021 4 commits
    • Takashi Iwai's avatar
      ALSA: firewire: Fix C++ style comments in uapi header · b1570647
      Takashi Iwai authored
      UAPI headers are built with -std=c90 and C++ style comments are
      explicitly prohibited.  The recent commit overlooked the rule and
      caused the error at header installation.  This patch corrects those.
      
      Fixes: bea36afa ("ALSA: firewire-motu: add message parser to gather meter information in register DSP model")
      Fixes: 90b28f3b ("ALSA: firewire-motu: add message parser for meter information in command DSP model")
      Fixes: 634ec0b2 ("ALSA: firewire-motu: notify event for parameter change in register DSP model")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20211018113812.0a16efb0@canb.auug.org.au
      Link: https://lore.kernel.org/r/20211018063700.30834-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b1570647
    • Takashi Iwai's avatar
      ALSA: memalloc: Convert x86 SG-buffer handling with non-contiguous type · 2d9ea399
      Takashi Iwai authored
      We've had an x86-specific SG-buffer handling code, but now it can be
      merged gracefully with the standard non-contiguous DMA pages.
      
      After the migration, SNDRV_DMA_TYPE_DMA_SG becomes identical with
      SNDRV_DMA_TYPE_NONCONTIG on x86, while others still fall back to
      SNDRV_DMA_TYPE_DEV.
      
      The remaining problem is about the SG-buffer with WC pages: the DMA
      core stuff on x86 doesn't treat it well, so we still need some special
      handling to manipulate the page attribute manually.  The mmap handler
      for SNDRV_DMA_TYPE_DEV_SG_WC still returns -ENOENT intentionally for
      the fallback to the default handler.
      
      Link: https://lore.kernel.org/r/20211017074859.24112-4-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2d9ea399
    • Takashi Iwai's avatar
      ALSA: memalloc: Support for non-coherent page allocation · 73325f60
      Takashi Iwai authored
      Following to the addition of non-contiguous pages, this patch adds the
      new contiguous non-coherent page allocation to the standard memalloc
      helper.  Like the previous non-contig type, this non-coherent type is
      also directional and requires the explicit sync, too.  Hence the
      driver using this type of buffer may need to set
      SNDRV_PCM_INFO_EXPLICIT_SYNC flag to the PCM hardware.info as well,
      unless it's set up in the managed mode.
      
      Link: https://lore.kernel.org/r/20211017074859.24112-3-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      73325f60
    • 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.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a25684a9
  2. 17 Oct, 2021 1 commit
    • 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.orgSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3c05f147
  3. 15 Oct, 2021 11 commits
  4. 14 Oct, 2021 7 commits
  5. 12 Oct, 2021 4 commits
    • 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.deSigned-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 spec,
      3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
      if the controller is already in reset per the HDA specification mentioned.
      
      This has been harmless on older hardware. On newer generation of Intel
      PCIe based HDA controllers, if configured to report issues, this write
      will emit an unsupported request error. If ACPI Platform Error Interface
      (APEI) is enabled in kernel, this will end up to kernel log.
      
      Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
      the function is called when controller is not in reset. Otherwise
      clearing the bits is not possible and should be skipped.
      Signed-off-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
      Link: https://lore.kernel.org/r/20211012142935.3731820-1-kai.vehmanen@linux.intel.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b37a1518
    • 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.deSigned-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=214537Reported-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.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a3fd1a98
  6. 11 Oct, 2021 2 commits
    • 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 works as is.  Also, 64bit applications are unaffected
      because the padding size is zero.  The remaining problem is the 32bit
      compat mode; as mentioned in the above, avail_min is placed right
      after appl_ptr on little-endian archs, 64bit kernel reads bogus values
      for appl_ptr updates, which may lead to streaming bugs like jumping,
      XRUN or whatever unexpected.
      (However, we haven't heard any serious bug reports due to this over
      years, so practically seen, it's fairly safe to assume that the impact
      by this bug is limited.)
      
      Ideally speaking, we should correct the wrong mmap status control
      definition.  But this would cause again incompatibility with the
      existing binaries, and fixing it (e.g. by renumbering ioctls) would be
      really messy.
      
      So, as of this patch, we only correct the behavior of 32bit compat
      mode and keep the rest as is.  Namely, the SYNC_PTR ioctl is now
      handled differently in compat mode to read/write the 32bit values at
      the right offsets.  The control mmap of 32bit apps on 64bit kernels
      has been already disabled (which is likely rather an overlook, but
      this worked fine at this time :), so covering SYNC_PTR ioctl should
      suffice as a fallback.
      
      Fixes: 80fe7430 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
      Reported-by: default avatarMichael Forney <mforney@mforney.org>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: <stable@vger.kernel.org>
      Cc: Rich Felker <dalias@libc.org>
      Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org
      Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      228af5a4
    • Cameron Berkenpas's avatar
      ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2 · 023a062f
      Cameron Berkenpas authored
      The previous patch's HDA verb initialization for the Lenovo 13s
      sequence was slightly off. This updated verb sequence has been tested
      and confirmed working.
      
      Fixes: ad7cc2d4 ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.")
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarCameron Berkenpas <cam@neo-zeon.de>
      Link: https://lore.kernel.org/r/20211010225410.23423-1-cam@neo-zeon.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      023a062f
  7. 10 Oct, 2021 1 commit
  8. 07 Oct, 2021 3 commits
  9. 06 Oct, 2021 1 commit
  10. 05 Oct, 2021 2 commits
  11. 04 Oct, 2021 2 commits
  12. 01 Oct, 2021 2 commits