1. 01 2月, 2019 3 次提交
    • T
      ALSA: hda - Serialize codec registrations · 305a0ade
      Takashi Iwai 提交于
      In the current code, the codec registration may happen both at the
      codec bind time and the end of the controller probe time.  In a rare
      occasion, they race with each other, leading to Oops due to the still
      uninitialized card device.
      
      This patch introduces a simple flag to prevent the codec registration
      at the codec bind time as long as the controller probe is going on.
      The controller probe invokes snd_card_register() that does the whole
      registration task, and we don't need to register each piece
      beforehand.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      305a0ade
    • T
      ALSA: hda/realtek - Use a common helper for hp pin reference · 35a39f98
      Takashi Iwai 提交于
      Replace the open-codes in many places with a new common helper for
      performing the same thing: referring to the primary headphone pin.
      
      This eventually fixes the potentially missing headphone pin on some
      weird devices, too.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      35a39f98
    • K
      ALSA: hda/realtek - Fix lose hp_pins for disable auto mute · d561aa0a
      Kailang Yang 提交于
      When auto_mute = no or spec->suppress_auto_mute = 1, cfg->hp_pins will
      lose value.
      
      Add this patch to find hp_pins value.
      I add fixed for ALC282 ALC225 ALC256 ALC294 and alc_default_init()
      alc_default_shutup().
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d561aa0a
  2. 31 1月, 2019 1 次提交
  3. 29 1月, 2019 1 次提交
    • K
      ALSA: hda/realtek - Fixed hp_pin no value · 693abe11
      Kailang Yang 提交于
      Fix hp_pin always no value.
      
      [More notes on the changes:
      
       The hp_pin value that is referred in alc294_hp_init() is always zero
       at the moment the function gets called, hence this is actually
       useless as in the current code.
      
       And, this kind of init sequence should be called from the codec init
       callback, instead of the parser function.  So, the first fix in this
       patch to move the call call into its own init_hook.
      
       OTOH, this function is needed to be called only once after the boot,
       and it'd take too long for invoking at each resume (where the init
       callback gets called).  So we add a new flag and invoke this only
       once as an additional fix.
      
       The one case is still not covered, though: S4 resume.  But this
       change itself won't lead to any regression in that regard, so we
       leave S4 issue as is for now and fix it later.  -- tiwai ]
      
      Fixes: bde1a745 ("ALSA: hda/realtek - Fixed headphone issue for ALC700")
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      693abe11
  4. 21 1月, 2019 1 次提交
  5. 14 1月, 2019 1 次提交
  6. 09 1月, 2019 2 次提交
  7. 07 1月, 2019 1 次提交
  8. 02 1月, 2019 1 次提交
    • T
      ALSA: hda - Revert DSP detection on legacy HD-audio driver · 3e9ad24b
      Takashi Iwai 提交于
      This essentially reverts the commits
        c337104b ("ALSA: HD-Audio: SKL+: abort probe if DSP is present
        and Skylake driver selected")
      and
        d82b51c8 ("ALSA: HD-Audio: SKL+: force HDaudio legacy or SKL+
        driver selection")
      for the path of legacy HD-audio controller (snd-hda-intel).
      
      The automatic DSP detection and skip of binding with the legacy driver
      caused regressions on several machines like Dell XPS13.  They give the
      PCI class 0x40380 indicating the availability of DSP while they don't
      work with ASoC SKL driver (yet).
      
      As the support of ASoC driver for such devices isn't available, it's
      better to revert the whole DSP-detection-and-skip behavior of the
      legacy driver, so that we can get the old good driver working on such
      devices.
      
      The pci_binding option for ASoC SKL driver is still kept so that it
      can work without blacklisting.
      
      Fixes: c337104b ("ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected")
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: NHans de Goede <hdegoede@redhat.com>
      Reported-by: NAzat Khuzhin <dohardgopro@gmail.com>
      Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3e9ad24b
  9. 01 1月, 2019 2 次提交
  10. 20 12月, 2018 2 次提交
    • P
      ALSA: HD-Audio: SKL+: force HDaudio legacy or SKL+ driver selection · d82b51c8
      Pierre-Louis Bossart 提交于
      For HDaudio and Skylake drivers, add module parameter "pci_binding"
      
      When pci_binding == 0 (AUTO), the PCI class/subclass info is used to
      select drivers based on the presence of the DSP.
      
      pci_binding == 1 (LEGACY) forces the use of the HDAudio legacy driver,
      even if the DSP is present.
      
      pci_binding == 2 (ASOC) forces the use of the ASOC driver. The
      information on the DSP presence is bypassed.
      
      The value for the module parameter needs to be identical for both
      drivers. This parameter is intended as a back-up solution if the
      automatic detection fails or when the DSP usage fails. Such cases
      should be reported on the alsa-devel mailing list for analysis.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d82b51c8
    • P
      ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected · c337104b
      Pierre-Louis Bossart 提交于
      Now that the SST/Skylake driver supports per platform selectors, we
      can add logic to automatically select the right driver.
      
      If the Skylake driver is selected for a specific platform, and the DSP
      is detected at run-time based on the PCI class/subclass/prog-if
      information, the legacy HDaudio driver aborts the probe. This will
      result in a single driver probing and remove the need for modprobe
      blacklists.
      
      Follow-up patches will add a module parameter to bypass the logic if
      this automatic detection fails, or if the Skylake driver is unable to
      actually support the platform (firmware authentication, missing
      topology file, hardware issue, etc).
      
      The same mechanism will be used to conflicts generated by the same PCI
      ID being registered by both legacy HDAuudio and SOF drivers for Intel
      platforms. In other words SOF will not require changes to the HDaudio
      legacy.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c337104b
  11. 19 12月, 2018 1 次提交
  12. 16 12月, 2018 1 次提交
  13. 13 12月, 2018 2 次提交
  14. 11 12月, 2018 6 次提交
    • A
      ALSA: hda/ca0132 - make pci_iounmap() call conditional · 1e73359a
      Arnd Bergmann 提交于
      When building without CONFIG_PCI, we can (depending on the architecture)
      get a link failure:
      
      ERROR: "pci_iounmap" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
      
      Adding a compile-time check for PCI gets it to work correctly on
      32-bit ARM.
      
      Fixes: d99501b8 ("ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1e73359a
    • T
      ALSA: hda/hdmi: Always set display_power_control for Intel HSW+ codecs · 46594d33
      Takashi Iwai 提交于
      We've excluded the display_power_control flag for Intel HSW and BDW
      codecs as the HD-audio controllers of the corresponding platforms take
      care of the display power as well.  But the recent refactoring
      separates the controller and the codec power accounting, so it's fine
      to call the display PM even for HSW/BDW codecs.  This is less
      confusing since we can avoid this well-hidden condition.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      46594d33
    • T
      ALSA: hda: Make snd_hdac_display_power() void function · 4f799e73
      Takashi Iwai 提交于
      After the recent refactoring, snd_hdac_display_power() doesn't return
      any error, hence it can be defined to return void.
      This makes many error checks redundant and allows us to reduce them
      gracefully.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4f799e73
    • T
      ALSA: hda/intel: Properly free the display power at error path · 457f3c86
      Takashi Iwai 提交于
      When an error occurs in azx_probe_continue(), we should release the
      display power.  However, the current code ignores it and releases the
      display power only for HSW/BDW cases.  Fix it.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      457f3c86
    • T
      ALSA: hda/intel: Drop superfluous AZX_DCAPS_I915_POWERWELL checks · e454ff8e
      Takashi Iwai 提交于
      snd_hdac_display_power() can be called even for a HDA controller
      without DRM binding.  The same is true for other helpers,
      snd_hdac_i915_set_bclk() and snd_hdac_set_codec_wakeup().
      So all superfluous AZX_DCAPS_I915_POWERWELL  checks in hda_intel.c can
      be dropped, and the definition of AZX_DCAPS_I915_POWERWELL itself can
      be removed as well.  This simplifies the code a lot.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e454ff8e
    • T
      ALSA: hda: Refactor display power management · 029d92c2
      Takashi Iwai 提交于
      The current HD-audio code manages the DRM audio power via too complex
      redirections, and this seems even still unbalanced in a corner case as
      Intel DRM CI has been intermittently reporting.  This patch is a big
      surgery for addressing the complexity and the possible unbalance.
      
      Basically the patch changes the display PM in the following ways:
      
      - Both HD-audio controller and codec drivers call a single helper,
        snd_hdac_display_power().  (Formerly, the display power control from
        a codec was done indirectly via link_power bus ops.)
      
      - snd_hdac_display_power() receives the codec address index.  For
        turning on/off from the controller, pass HDA_CODEC_IDX_CONTROLLER.
      
      - snd_hdac_display_power() doesn't manage refcounts any longer, but
        keeps the power status in bitmap.  If any of controller or codecs is
        turned on, the function updates the DRM power state via get_power()
        or put_power().
      
      Also this refactor allows us more cleanup:
      
      - The link_power bus ops is dropped, so there is no longer indirect
        management, as mentioned in the above.
      
      - hdac_device link_power_control flag is moved to hda_codec
        display_power_control flag, as it's only for HDA legacy.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106525Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      029d92c2
  15. 10 12月, 2018 3 次提交
  16. 09 12月, 2018 2 次提交
  17. 07 12月, 2018 4 次提交
  18. 05 12月, 2018 4 次提交
  19. 03 12月, 2018 2 次提交