1. 16 1月, 2017 1 次提交
  2. 15 1月, 2017 1 次提交
    • T
      ALSA: hda - Make single_cmd option to stop the fallback mechanism · 41438f13
      Takashi Iwai 提交于
      HD-audio driver has a mechanism to fall back to the single cmd mode as
      a last resort if the CORB/RIRB communication goes wrong even after
      switching to the polling mode.  The switching has worked in the past
      well, but Enrico Mioso reported that his system crashes when this
      happens.
      
      Although the actual cause of the crash isn't still fully analyzed yet,
      it'd be in anyway good to provide an option to turn off the fallback
      mode.  Now this patch extends the behavior of the existing single_cmd
      option for that.  Namely,
      
      - The option is changed from bool to bint.
      - As default, it is the mode allowing the fallback to single cmd.
      - Once when either true/false value is given to the option, the driver
        explicitly turns on/off the single cmd mode, but without the
        fallback.
      
      That is, if you want to disable the fallback, just pass single_cmd=0
      option.  Passing single_cmd=1 will keep working like before.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      41438f13
  3. 12 1月, 2017 1 次提交
    • A
      ALSA: hda/ca0132 - fix possible NULL pointer use · 46a049da
      Arnd Bergmann 提交于
      gcc-7 caught what it considers a NULL pointer dereference:
      
      sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop':
      sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null expected [-Werror=nonnull]
      
      This is plausible from looking at the function, as we compare 'reply'
      to NULL earlier in it. I have not tried to analyze if there are constraints
      that make it impossible to hit the bug, but adding another NULL check in
      the end kills the warning and makes the function more robust.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      46a049da
  4. 04 1月, 2017 2 次提交
    • T
      ALSA: hda - Fix deadlock of controller device lock at unbinding · ab949d51
      Takashi Iwai 提交于
      Imre Deak reported a deadlock of HD-audio driver at unbinding while
      it's still in probing.  Since we probe the codecs asynchronously in a
      work, the codec driver probe may still be kicked off while the
      controller itself is being unbound.  And, azx_remove() tries to
      process all pending tasks via cancel_work_sync() for fixing the other
      races (see commit [0b8c8219: ALSA: hda - Cancel probe work instead
      of flush at remove]), now we may meet a bizarre deadlock:
      
      Unbind snd_hda_intel via sysfs:
        device_release_driver() ->
          device_lock(snd_hda_intel) ->
            azx_remove() ->
              cancel_work_sync(azx_probe_work)
      
      azx_probe_work():
        codec driver probe() ->
           __driver_attach() ->
             device_lock(snd_hda_intel)
      
      This deadlock is caused by the fact that both device_release_driver()
      and driver_probe_device() take both the device and its parent locks at
      the same time.  The codec device sets the controller device as its
      parent, and this lock is taken before the probe() callback is called,
      while the controller remove() callback gets called also with the same
      lock.
      
      In this patch, as an ugly workaround, we unlock the controller device
      temporarily during cancel_work_sync() call.  The race against another
      bind call should be still suppressed by the parent's device lock.
      Reported-by: NImre Deak <imre.deak@intel.com>
      Fixes: 0b8c8219 ("ALSA: hda - Cancel probe work instead of flush at remove")
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ab949d51
    • K
      ALSA: hda/realtek - Add new codec ID ALC299 · 28f1f9b2
      Kailang Yang 提交于
      ALC299 was similar as ALC225.
      Add headset support for ALC299.
      ALC3271 was for Dell rename.
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      28f1f9b2
  5. 28 12月, 2016 2 次提交
  6. 06 12月, 2016 2 次提交
  7. 29 11月, 2016 1 次提交
  8. 25 11月, 2016 1 次提交
  9. 24 11月, 2016 2 次提交
  10. 11 11月, 2016 1 次提交
    • T
      ALSA: hda - Fix mic regression by ASRock mobo fixup · 9a254191
      Takashi Iwai 提交于
      The commit [1a3f0991: ALSA: hda - Fix surround output pins for
      ASRock B150M mobo] introduced a fixup of pin configs for ASRock
      mobos to fix the surround outputs.  However, this overrides the pin
      configs of the mic pins as if they are outputs-only, effectively
      disabling the mic inputs.  Of course, it's a regression wrt mic
      functionality.
      
      Actually the pins 0x18 and 0x1a don't need to be changed; we just need
      to disable the bogus pins 0x14 and 0x15.  Then the auto-parser will
      pick up mic pins as switchable and assign the surround outputs there.
      
      This patch removes the incorrect pin overrides of NID 0x18 and 0x1a
      from the ASRock fixup.
      
      Fixes: 1a3f0991 ('ALSA: hda - Fix surround output pins for ASRock...')
      Reported-and-tested-by: NVitor Antunes <vitor.hda@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=187431
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9a254191
  11. 10 11月, 2016 1 次提交
  12. 08 11月, 2016 1 次提交
  13. 25 10月, 2016 1 次提交
  14. 20 10月, 2016 1 次提交
  15. 18 10月, 2016 2 次提交
    • H
      ALSA: hda - Adding a new group of pin cfg into ALC295 pin quirk table · f771d5bb
      Hui Wang 提交于
      We have a new Dell laptop model which uses ALC295, the pin definition
      is different from the existing ones in the pin quirk table, to fix the
      headset mic detection and mic mute led's problem, we need to add the
      new pin defintion into the pin quirk table.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f771d5bb
    • A
      ALSA: hda - allow 40 bit DMA mask for NVidia devices · 3ab7511e
      Ard Biesheuvel 提交于
      Commit 49d9e77e ("ALSA: hda - Fix system panic when DMA > 40 bits
      for Nvidia audio controllers") simply disabled any DMA exceeding 32
      bits for NVidia devices, even though they are capable of performing
      DMA up to 40 bits. On some architectures (such as arm64), system memory
      is not guaranteed to be 32-bit addressable by PCI devices, and so this
      change prevents NVidia devices from working on platforms such as AMD
      Seattle.
      
      Since the original commit already mentioned that up to 40 bits of DMA
      is supported, and given that the code has been updated in the meantime
      to support a 40 bit DMA mask on other devices, revert commit 49d9e77e
      and explicitly set the DMA mask to 40 bits for NVidia devices.
      
      Fixes: 49d9e77e ('ALSA: hda - Fix system panic when DMA > 40 bits...')
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3ab7511e
  16. 13 10月, 2016 1 次提交
    • H
      ALSA: hda - Fix a failure of micmute led when having multi adcs · 4875a5f7
      Hui Wang 提交于
      On a Dell laptop, there is no global adcs for all input devices, so
      the input devices use the different adc, as a result, dyn_adc_switch
      is set to true.
      
      In this situation, it is safe to control the micmute led according to
      user's choice of muting/unmuting the current input device, since only
      current input device path is active, while other input device paths
      are inactive and powered down.
      
      Fixes: 00ef9940 ('ALSA: hda - add mic mute led hook for dell machines')
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4875a5f7
  17. 27 9月, 2016 1 次提交
  18. 26 9月, 2016 1 次提交
  19. 23 9月, 2016 1 次提交
    • P
      drm/i915/dp: DP audio API changes for MST · f9318941
      Pandiyan, Dhinakaran 提交于
      DP MST provides the capability to send multiple video and audio streams
      through a single port. This requires the API's between i915 and audio
      drivers to distinguish between multiple audio capable displays that can be
      connected to a port. Currently only the port identity is shared in the
      APIs. This patch adds support for MST with an additional parameter
      'int pipe'. The existing parameter 'port' does not change it's meaning.
      
      pipe =
      	MST	: display pipe that the stream originates from
      	Non-MST	: -1
      
      Affected APIs:
      struct i915_audio_component_ops
      -       int (*sync_audio_rate)(struct device *, int port, int rate);
      +	int (*sync_audio_rate)(struct device *, int port, int pipe,
      +	     int rate);
      
      -       int (*get_eld)(struct device *, int port, bool *enabled,
      -                       unsigned char *buf, int max_bytes);
      +       int (*get_eld)(struct device *, int port, int pipe,
      +		       bool *enabled, unsigned char *buf, int max_bytes);
      
      struct i915_audio_component_audio_ops
      -       void (*pin_eld_notify)(void *audio_ptr, int port);
      +       void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
      
      This patch makes dummy changes in the audio drivers (thanks Libin) for
      build to succeed. The audio side drivers will send the right 'pipe' values
      for MST in patches that will follow.
      
      v2:
      Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
      Included Asoc driver API compatibility changes from Jeeja.
      Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
      Added comment for av_enc_map[] definition. (Takashi)
      
      v3:
      Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
      Renamed get_saved_encoder() to get_saved_enc() to reduce line length
      
      v4:
      Rebased.
      Parameter check for pipe < -1 values in get_saved_enc() (Ville)
      Switched to for_each_pipe() in get_saved_enc() (Ville)
      Renamed 'pipe' to 'dev_id' in audio side code (Takashi)
      
      v5:
      Included a comment for the dev_id arg. (Libin)
      Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1474488168-2343-1-git-send-email-dhinakaran.pandiyan@intel.com
      f9318941
  20. 12 9月, 2016 1 次提交
    • J
      ALSA: pci: constify local structures · 071f1344
      Julia Lawall 提交于
      For structure types defined in the same file or local header files, find
      top-level static structure declarations that have the following
      properties:
      1. Never reassigned.
      2. Address never taken
      3. Not passed to a top-level macro call
      4. No pointer or array-typed field passed to a function or stored in a
      variable.
      Declare structures having all of these properties as const.
      
      Done using Coccinelle.
      Based on a suggestion by Joe Perches <joe@perches.com>.
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      071f1344
  21. 11 9月, 2016 1 次提交
  22. 10 9月, 2016 1 次提交
    • T
      ALSA: hda - Skip Realtek SKU check for Lenovo machines · 09da111a
      Takashi Iwai 提交于
      Realtek codec driver expects an implicit rule where either the codec
      SSID or the pincfg NID 0x1d contains the some information encoded in
      some bits.  One of the expected information is there is the
      availability of PC beep, and the driver doesn't build up the PC beep
      control if this is *supposed* to be disabled there.
      
      Meanwhile, Lenovo doesn't seem to follow this requirement (yes it's
      non-standard after all), and the BIOS sets just the normal SSID and
      the pincfg values.  This resulted in the lack of PC beep on a few
      machines, purely with a lucky or unlucky number.  It didn't bother
      most people, but some people still demand the PC beep, as found in bug
      reports.
      
      This patch just adds the fixup chain to Lenovo machines to skip the
      SKU checks.  Then the beep control will show up in the mixer, and user
      can still decide to enable / disable it via the standard mixer
      interface.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=156311Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      09da111a
  23. 02 9月, 2016 1 次提交
    • J
      ALSA: constify snd_pcm_ops structures · 6769e988
      Julia Lawall 提交于
      Check for snd_pcm_ops structures that are only stored in the ops field of a
      snd_soc_platform_driver structure or passed as the third argument to
      snd_pcm_set_ops.  The corresponding field or parameter is declared const,
      so snd_pcm_ops structures that have this property can be declared as const
      also.
      
      The semantic patch that makes this change is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @r disable optional_qualifier@
      identifier i;
      position p;
      @@
      static struct snd_pcm_ops i@p = { ... };
      
      @ok1@
      identifier r.i;
      struct snd_soc_platform_driver e;
      position p;
      @@
      e.ops = &i@p;
      
      @ok2@
      identifier r.i;
      expression e1, e2;
      position p;
      @@
      snd_pcm_set_ops(e1, e2, &i@p)
      
      @bad@
      position p != {r.p,ok1.p,ok2.p};
      identifier r.i;
      struct snd_pcm_ops e;
      @@
      e@i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r.i;
      @@
      static
      +const
       struct snd_pcm_ops i = { ... };
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6769e988
  24. 30 8月, 2016 2 次提交
  25. 24 8月, 2016 1 次提交
  26. 10 8月, 2016 1 次提交
    • T
      ALSA: hda - Manage power well properly for resume · a52ff34e
      Takashi Iwai 提交于
      For SKL and later Intel chips, we control the power well per codec
      basis via link_power callback since the commit [03b135ce: ALSA:
      hda - remove dependency on i915 power well for SKL].
      However, there are a few exceptional cases where the gfx registers are
      accessed from the audio driver: namely the wakeup override bit
      toggling at (both system and runtime) resume.  This seems causing a
      kernel warning when accessed during the power well down (and likely
      resulting in the bogus register accesses).
      
      This patch puts the proper power up / down sequence around the resume
      code so that the wakeup bit is fiddled properly while the power is
      up.  (The other callback, sync_audio_rate, is used only in the PCM
      callback, so it's guaranteed in the power-on.)
      
      Also, by this proper power up/down, the instantaneous flip of wakeup
      bit in the resume callback that was introduced by the commit
      [033ea349: ALSA: hda - Fix Skylake codec timeout] becomes
      superfluous, as snd_hdac_display_power() already does it.  So we can
      clean it up together.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214
      Fixes: 03b135ce ('ALSA: hda - remove dependency on i915 power well for SKL')
      Cc: <stable@vger.kernel.org> # v4.2+
      Tested-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a52ff34e
  27. 09 8月, 2016 2 次提交
  28. 04 8月, 2016 1 次提交
  29. 03 8月, 2016 1 次提交
  30. 01 8月, 2016 2 次提交
  31. 12 7月, 2016 2 次提交