Skip to content

L
linux
Switch branch/tag
  1. 06 Feb, 2020 3 commits
  3. 05 Feb, 2020 2 commits
  5. 04 Feb, 2020 3 commits
  7. 02 Feb, 2020 4 commits
  9. 01 Feb, 2020 4 commits
  11. 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
  13. 29 Jan, 2020 7 commits
  15. 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
  17. 27 Jan, 2020 11 commits
  19. 26 Jan, 2020 3 commits
  21. 24 Jan, 2020 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7