Skip to content
Snippets Groups Projects
  1. Nov 22, 2021
  2. Nov 04, 2021
  3. Oct 29, 2021
  4. Oct 25, 2021
  5. Oct 19, 2021
  6. Oct 18, 2021
    • Kuninori Morimoto's avatar
      ASoC: soc-component: add snd_soc_component_is_codec() · 01e90ee1
      Kuninori Morimoto authored
      
      Checking .non_legacy_dai_naming is not readable.
      Let's add new snd_soc_component_is_codec().
      
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/87h7dft7dn.wl-kuninori.morimoto.gx@renesas.com
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      01e90ee1
    • 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.de
      
      
      Signed-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.de
      
      
      Signed-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.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a25684a9
  7. Oct 15, 2021
  8. Oct 07, 2021
    • Takashi Iwai's avatar
      ALSA: hda: intel: Allow repeatedly probing on codec configuration errors · c0f1886d
      Takashi Iwai authored
      It seems that a few recent AMD systems show the codec configuration
      errors at the early boot, while loading the driver at a later stage
      works magically.  Although the root cause of the error isn't clear,
      it's certainly not bad to allow retrying the codec probe in such a
      case if that helps.
      
      This patch adds the capability for retrying the probe upon codec probe
      errors on the certain AMD platforms.  The probe_work is changed to a
      delayed work, and at the secondary call, it'll jump to the codec
      probing.
      
      Note that, not only adding the re-probing, this includes the behavior
      changes in the codec configuration function.  Namely,
      snd_hda_codec_configure() won't unregister the codec at errors any
      longer.  Instead, its caller, azx_codec_configure() unregisters the
      codecs with the probe failures *if* any codec has been successfully
      configured.  If all codec probe failed, it doesn't unregister but let
      it re-probed -- which is the most case we're seeing and this patch
      tries to improve.
      
      Even if the driver doesn't re-probe or give up, it will go to the
      "free-all" error path, hence the leftover codecs shall be disabled /
      deleted in anyway.
      
      BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801
      Link: https://lore.kernel.org/r/20211006141940.2897-1-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c0f1886d
  9. Oct 05, 2021
  10. Oct 01, 2021
  11. Sep 28, 2021
  12. Sep 23, 2021
  13. Sep 20, 2021
  14. Sep 15, 2021
  15. Sep 13, 2021
  16. Aug 30, 2021
  17. Aug 26, 2021
    • Pierre Bossart's avatar
      ASoC: soc-pcm: test refcount before triggering · 6479f758
      Pierre Bossart authored
      
      On start/pause_release/resume, when more than one FE is connected to
      the same BE, it's possible that the trigger is sent more than
      once. This is not desirable, we only want to trigger a BE once, which
      is straightforward to implement with a refcount.
      
      For stop/pause/suspend, the problem is more complicated: the check
      implemented in snd_soc_dpcm_can_be_free_stop() may fail due to a
      conceptual deadlock when we trigger the BE before the FE. In this
      case, the FE states have not yet changed, so there are corner cases
      where the TRIGGER_STOP is never sent - the dual case of start where
      multiple triggers might be sent.
      
      This patch suggests an unconditional trigger in all cases, without
      checking the FE states, using a refcount protected by a spinlock.
      
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Message-Id: <20210817164054.250028-3-pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      6479f758
  18. Aug 14, 2021
  19. Aug 13, 2021
  20. Aug 05, 2021
  21. Aug 04, 2021
  22. Jul 19, 2021
Loading