1. 30 Jun, 2017 1 commit
  2. 15 May, 2017 1 commit
    • Ville Syrjälä's avatar
      drm/i915: Fix runtime PM for LPE audio · 668e3b01
      Ville Syrjälä authored
      Not calling pm_runtime_enable() means that runtime PM can't be
      enabled at all via sysfs. So we definitely need to call it
      from somewhere.
      Calling it from the driver seems like a bad idea because it
      would have to be paired with a pm_runtime_disable() at driver
      unload time, otherwise the core gets upset. Also if there's
      no LPE audio driver loaded then we couldn't runtime suspend
      i915 either.
      So it looks like a better plan is to call it from i915 when
      we register the platform device. That seems to match how
      pci generally does things. I cargo culted the
      pm_runtime_forbid() and pm_runtime_set_active() calls from
      pci as well.
      The exposed runtime PM API is massive an thorougly misleading, so
      I don't actually know if this is how you're supposed to use the API
      or not. But it seems to work. I can now runtime suspend i915 again
      with or without the LPE audio driver loaded, and reloading the
      LPE audio driver also seems to work.
      Note that powertop won't auto-tune runtime PM for platform devices,
      which is a little annoying. So I'm not sure that leaving runtime
      PM in "on" mode by default is the best choice here. But I've left
      it like that for now at least.
      Also remove the comment about there not being much benefit from
      LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
      PM, which will also block s0ix, and that could have a measurable
      impact on power consumption.
      Cc: stable@vger.kernel.org
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Fixes: 0b6b524f ("ALSA: x86: Don't enable runtime PM as default")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-2-ville.syrjala@linux.intel.comReviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      (cherry picked from commit 183c0035)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
  3. 09 May, 2017 1 commit
  4. 03 May, 2017 9 commits
  5. 21 Mar, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: x86: Make CONFIG_SND_X86 bool · c6736a94
      Takashi Iwai authored
      CONFIG_SND_X86 is a menu config to filter only for x86-specific
      drivers in its sub-menu, and this doesn't have to be tristate but
      rather it should be a bool.  Also, like other sub-menu configs, it's
      more user-friendly to be default=y; it's merely a menu config and the
      actual drivers are configured in the sub-menu, after all.
      Fixes: 287599cf ("ALSA: add Intel HDMI LPE audio driver for BYT/CHT-T")
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  6. 21 Feb, 2017 3 commits
    • Arnd Bergmann's avatar
      ALSA: x86: hdmi: select CONFIG_SND_PCM · 4b49f0f7
      Arnd Bergmann authored
      The newly added driver uses the PCM helpers and fails to link if they are disabled:
      sound/built-in.o: In function `hdmi_lpe_audio_runtime_suspend':
      intel_hdmi_audio.c:(.text+0x15906): undefined reference to `snd_pcm_suspend'
      sound/built-in.o: In function `had_pcm_hw_params':
      intel_hdmi_audio.c:(.text+0x15ac7): undefined reference to `snd_pcm_lib_malloc_pages'
      sound/built-in.o: In function `had_pcm_open':
      intel_hdmi_audio.c:(.text+0x15d49): undefined reference to `snd_pcm_hw_constraint_integer'
      This uses a Kconfig 'select' statement to make sure they are enabled.
      Fixes: 5dab11d8 ("ALSA: x86: hdmi: Add audio support for BYT and CHT")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: x86: Don't enable runtime PM as default · 0b6b524f
      Takashi Iwai authored
      Unlike HSW and newer, BYT/CHT devices have no fine control of audio
      power domain in i915 side.  Since there is little gain by runtime PM
      on BYT/CHT, so far, this commit removes the pm_runtime_enable() call
      as default.
      User who still wants the runtime PM may adjust the corresponding
      sysfs files (power/control and power/autosuspend_delay_ms)
      appropriately, of course.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: x86: Use runtime PM autosuspend · 3002b9fb
      Takashi Iwai authored
      This patch adds a few lines to the driver to use autosuspend for the
      runtime PM.  It'll become useful with the combination of the keep-link
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  7. 16 Feb, 2017 8 commits
  8. 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>
    • 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>
  9. 10 Feb, 2017 5 commits
  10. 07 Feb, 2017 6 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>
    • 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>
    • 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>
    • 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>
    • 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
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • 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>
  11. 06 Feb, 2017 1 commit
    • 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>
  12. 05 Feb, 2017 2 commits