1. 20 Feb, 2017 2 commits
  2. 19 Feb, 2017 1 commit
  3. 16 Feb, 2017 9 commits
  4. 15 Feb, 2017 2 commits
  5. 14 Feb, 2017 1 commit
  6. 13 Feb, 2017 2 commits
    • Takashi Iwai's avatar
      ALSA: x86: Drop unused stream.running field · df42cb49
      Takashi Iwai authored
      The pcm_stream_info.running field is only set in the PCM trigger
      callback but never referred, thus it can be safely removed.
      
      Also, properly cover the spinlock in both the trigger START and STOP
      to protect had_enable_audio() calls.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      df42cb49
    • Takashi Iwai's avatar
      ALSA: x86: Handle reset at prepare callback · e2acecf2
      Takashi Iwai authored
      Currently the driver handles some reset procedure at the trigger STOP
      and the underrun functions, where both are executed in the interrupt
      context.  Especially the underrun function has a sync-loop to clear
      the UNDERRUN status bit, and this is supposed to be one of plausible
      causes of GPU hangup.
      
      Since the job to be done in the interrupt handler should be minimum,
      we move the reset function out of trigger and underrun, and push it
      into the prepare (and hw_free) callbacks instead.  Here a new flag,
      need_reset, is introduced to indicate the requirement of the reset
      procedure.  This is for avoiding the multiple resets when PCM prepare
      is called sequentially.
      
      Also in the UNDERRUN bit-clear sync loop, take a longer pause to be in
      the safer side.  Taking a longer delay is no longer a problem now
      because we're running in the normal context.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e2acecf2
  7. 10 Feb, 2017 5 commits
  8. 09 Feb, 2017 1 commit
  9. 08 Feb, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: seq: Fix race at creating a queue · 4842e98f
      Takashi Iwai authored
      When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
      new queue element to the public list before referencing it.  Thus the
      queue might be deleted before the call of snd_seq_queue_use(), and it
      results in the use-after-free error, as spotted by syzkaller.
      
      The fix is to reference the queue object at the right time.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4842e98f
  10. 07 Feb, 2017 9 commits
    • Takashi Iwai's avatar
      ALSA: x86: Cache AUD_CONFIG register value · 40ce4b5d
      Takashi Iwai authored
      At enabling the audio, we modify AUD_CONFIG register bit 0.  So far,
      it does read-modify-write procedure with a special hack for the
      channel bits due to the silicon bug.  But we can optimize it by
      remembering the AUD_CONFIG register value privately.  This simplifies
      the things a lot.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      40ce4b5d
    • Takashi Iwai's avatar
      ALSA: x86: Rearrange defines · 77531bee
      Takashi Iwai authored
      We have two header files and everything is mixed up chaotically.
      Move the chip-specific definitions like the hardware registers to
      intel_hdmi_lpe_audio.h, and the rest, the implementation specific
      stuff into intel_hdmi_audio.h.
      
      In addition, put some more comments to the register fields, and fix
      the incorrect name prefix for AUD_HDMI_STATUS bits, too.
      
      The whole changes are merely a code shuffling, and there is no
      functional change.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      77531bee
    • Arnd Bergmann's avatar
      ALSA: x86: mark hdmi suspend/resume functions as __maybe_unused · 1df98924
      Arnd Bergmann authored
      The two functions are unused when CONFIG_PM_SLEEP is disabled:
      
      sound/x86/intel_hdmi_audio.c:1633:12: error: 'hdmi_lpe_audio_resume' defined but not used [-Werror=unused-function]
      sound/x86/intel_hdmi_audio.c:1622:12: error: 'hdmi_lpe_audio_suspend' defined but not used [-Werror=unused-function]
      
      Marking them as __maybe_unused avoids the warning without introducing an
      ugly #ifdef.
      
      Fixes: 182cdf23 ("ALSA: x86: Implement runtime PM")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1df98924
    • Takashi Iwai's avatar
      ALSA: x86: Fix driver name string overflow · 873ab035
      Takashi Iwai authored
      The driver sets card->driver name string over its size (16 bytes).
      Shorten the name string to fit with it.
      
      Also, set more verbose string to card->shortname and ->longname.
      This doesn't have to be identical with card->driver at all.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      873ab035
    • Takashi Iwai's avatar
      ALSA: x86: Rename had_enable_audio_int() to had_ack_irqs() · 075a1d46
      Takashi Iwai authored
      had_enable_audio_int() came from the LPE audio shell set_caps
      callback with ENABLE_INT and DISABLE_INT caps.  I interpreted as these
      correspond to enabling / disabling the audio interface, but the actual
      implementation is only to clear (send ACK) to both BUFFER_DONE and
      BUFFER_UNDERRUN interrupts unconditionally.  And, there is no
      counterpart, DISABLE_INT, code at all.
      
      For avoiding the further misunderstanding, rename the function to the
      more fitting one, had_ack_irqs(), and drop the calls with enable=false
      in allover places.  There is no functional changes at all.
      
      After this patch, there is only one caller at the PCM trigger start.
      Then it's doubtful whether this call is still really needed or not; I
      bet it not, but let's stay in the safer side for now and keep it as
      was.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      075a1d46
    • Takashi Iwai's avatar
      ALSA: x86: Drop suspicious U24 format support · 3e21a76c
      Takashi Iwai authored
      U24 format is declared to be supported by the driver, but this looks
      really doubtful, as there is no corresponding code.  Better to drop
      it.  This format is very uncommon, so there should be practically no
      impact by this change.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3e21a76c
    • Andrej Krutak's avatar
      ALSA: line6: Always setup isochronous transfer properties · 5d81296b
      Andrej Krutak authored
      While not all line6 devices currently support PCM, it causes no
      harm to 'have it prepared'.
      
      This also fixes toneport, which only has PCM - in which case
      we previously skipped the USB transfer properties detection completely.
      Signed-off-by: default avatarAndrej Krutak <dev@andree.sk>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5d81296b
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 1e94320f
      Takashi Iwai authored
      1e94320f
    • Takashi Iwai's avatar
      Revert "ALSA: line6: Only determine control port properties if needed" · f3d83317
      Takashi Iwai authored
      This reverts commit f6a0dd10.
      
      The commit caused a regression on LINE6 Transport that has no control
      caps.  Although reverting the commit may result back in a spurious
      error message for some device again, it's the simplest regression fix,
      hence it's taken as is at first.  The further code fix will follow
      later.
      
      Fixes: f6a0dd10 ("ALSA: line6: Only determine control port properties if needed")
      Reported-by: default avatarIgor Zinovev <zinigor@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f3d83317
  11. 06 Feb, 2017 2 commits
    • Takashi Iwai's avatar
      ALSA: seq: Don't handle loop timeout at snd_seq_pool_done() · 37a7ea4a
      Takashi Iwai authored
      snd_seq_pool_done() syncs with closing of all opened threads, but it
      aborts the wait loop with a timeout, and proceeds to the release
      resource even if not all threads have been closed.  The timeout was 5
      seconds, and if you run a crazy stuff, it can exceed easily, and may
      result in the access of the invalid memory address -- this is what
      syzkaller detected in a bug report.
      
      As a fix, let the code graduate from naiveness, simply remove the loop
      timeout.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      37a7ea4a
    • Takashi Iwai's avatar
      ALSA: x86: Refactor PCM process engine · e1b239f3
      Takashi Iwai authored
      This is again a big rewrite of the driver; now it touches the code to
      process PCM stream transfers.
      
      The most fundamental change is that the driver may support more than
      four periods.  Instead of keeping the same index between both the ring
      buffer (with the fixed four buffer descriptors) and the PCM buffer
      periods, we keep difference indices for both (bd_head and pcm_head
      fields).  In addition, when the periods are more than four, we need to
      track both head and next indices.  That is, we now have three indices:
      bd_head, pcm_head and pcm_filled.
      
      Also, the driver works better for periods < 4, too: the remaining BDs
      out of four are marked as invalid, so that the hardware skips those
      BDs in its loop.
      
      By this flexibility, we can use even ALSA-lib dmix plugin, which
      requires 16 periods as default.
      
      The buffer size could be up to 20bit, so the max buffer size was
      increased accordingly.  However, the buffer pre-allocation is kept as
      the old value (600kB) as default.  The reason is the limited number of
      BDs: since it doesn't suffice for the useful SG page management that
      can fit with the usual page allocator like some other drivers, we have
      to still allocate continuous pages, hence we shouldn't take too big
      memories there.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e1b239f3
  12. 05 Feb, 2017 5 commits