1. 02 Feb, 2020 1 commit
  2. 01 Feb, 2020 4 commits
  3. 31 Jan, 2020 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Fix sparse warnings wrt snd_pcm_state_t · cb639a42
      Takashi Iwai authored
      Since we have a bitwise definition of snd_pcm_state_t and use it for
      certain struct fields, a few new (and years old) sparse warnings came
      up.  This patch is an attempt to cover them.
      
      - The state fields in snd_pcm_mmap_status* and co are all defined as
        snd_pcm_state_t type now
      
      - The PCM action callbacks take snd_pcm_state_t argument as well;
        some actions taking special values got the explicit cast and
        comments
      
      - For the PCM action that doesn't need an extra argument receives
        ACTION_ARG_IGNORE instead of ambiguous 0
      
      While we're at it, the boolean argument is also properly changed to
      bool and true/false, as well as a slight refactoring of PCM pause
      helper function to make easier to read.
      
      No functional changes, just shutting up chatty sparse.
      
      Fixes: 46b770f7 ("ALSA: uapi: Fix sparse warning")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Link: https://lore.kernel.org/r/20200131152214.11698-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cb639a42
  4. 29 Jan, 2020 2 commits
  5. 28 Jan, 2020 1 commit
    • Mohan Kumar's avatar
      ALSA: hda: Reset stream if DMA RUN bit not cleared · 7faa26c1
      Mohan Kumar authored
      Tegra HDA has FIFO size which can hold upto 10 audio frames to support
      DVFS. When HDA DMA RUN bit is set to 0 to stop the stream, the DMA RUN
      bit will be cleared to 0 only after transferring all the remaining audio
      frames queued up in the fifo. This is not in sync with spec which states
      the controller will stop transmitting(output) in the beginning of the
      next frame for the relevant stream.
      
      The above behavior with Tegra HDA was resulting in machine check error
      during the system suspend flow with active audio playback with below kernel
      error logs.
      [ 33.524583] mc-err: [mcerr] (hda) csr_hdar: EMEM address decode error
      [ 33.531088] mc-err: [mcerr] status = 0x20000015; addr = 0x00000000
      [ 33.537431] mc-err: [mcerr] secure: no, access-type: read, SMMU fault: none
      
      This was due to the fifo has more than one audio frame when the DMA
      RUN bit is set to 0 during system suspend flow and the timeout handling in
      snd_hdac_stream_sync() was not designed to handle this scenario. So the
      DMA will continue running even after timeout hit until all remaining
      audio frames in the fifo are transferred, but the suspend flow will try
      to reset the controller and turn off the hda clocks without the knowledge
      of the DMA is still running and could result in mc-err.
      
      The above issue can be resolved by doing stream reset with the help of
      snd_hdac_stream_reset() which would ensure the DMA RUN bit is cleared
      if the timeout was hit in snd_hdac_stream_sync().
      Signed-off-by: default avatarMohan Kumar <mkumard@nvidia.com>
      Link: https://lore.kernel.org/r/20200128051508.26064-1-mkumard@nvidia.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7faa26c1
  6. 27 Jan, 2020 1 commit
    • Takashi Iwai's avatar
      Merge tag 'asoc-v5.6' of... · 90fb04f8
      Takashi Iwai authored
      Merge tag 'asoc-v5.6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Updates for v5.6
      
      A pretty big release this time around, a lot of new drivers and both
      Morimoto-san and Takashi were doing subsystem wide updates as well:
      
       - Further big refactorings from Morimoto-san simplifying the core
         interfaces and moving things to the component level.
       - Transition of drivers to managed buffer allocation and removal of
         redundant PCM ioctls.
       - New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm
         WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011, RT1015
         and RT1308.
      90fb04f8
  7. 26 Jan, 2020 3 commits
  8. 23 Jan, 2020 15 commits
  9. 22 Jan, 2020 1 commit
  10. 21 Jan, 2020 11 commits