1. 03 Apr, 2019 1 commit
    • Kailang Yang's avatar
      ALSA: hda/realtek - Move to ACT_INIT state · 8983eb60
      Kailang Yang authored
      It will be lose Mic JD state when Chrome OS boot and headset was plugged.
      Just Implement of reset combo jack JD verb for ACT_PRE_PROBE state.
      Intel test result was also failed.
      It test passed until changed the initial state to ACT_INIT.
      Mic JD will show every time.
      This patch also changed the model name as 'alc-chrome-book' for
      application of Chrome OS.
      
      Fixes: 10f5b1b8 ("ALSA: hda/realtek - Fixed Headset Mic JD not stable")
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8983eb60
  2. 02 Apr, 2019 2 commits
  3. 26 Mar, 2019 1 commit
  4. 25 Mar, 2019 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Don't suspend stream in unrecoverable PCM state · 113ce081
      Takashi Iwai authored
      Currently PCM core sets each opened stream forcibly to SUSPENDED state
      via snd_pcm_suspend_all() call, and the user-space is responsible for
      re-triggering the resume manually either via snd_pcm_resume() or
      prepare call.  The scheme works fine usually, but there are corner
      cases where the stream can't be resumed by that call: the streams
      still in OPEN state before finishing hw_params.  When they are
      suspended, user-space cannot perform resume or prepare because they
      haven't been set up yet.  The only possible recovery is to re-open the
      device, which isn't nice at all.  Similarly, when a stream is in
      DISCONNECTED state, it makes no sense to change it to SUSPENDED
      state.  Ditto for in SETUP state; which you can re-prepare directly.
      
      So, this patch addresses these issues by filtering the PCM streams to
      be suspended by checking the PCM state.  When a stream is in either
      OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend
      action is skipped.
      
      To be noted, this problem was originally reported for the PCM runtime
      PM on HD-audio.  And, the runtime PM problem itself was already
      addressed (although not intended) by the code refactoring commits
      3d21ef0b ("ALSA: pcm: Suspend streams globally via device type PM
      ops") and 17bc4815 ("ALSA: pci: Remove superfluous
      snd_pcm_suspend*() calls").  These commits eliminated the
      snd_pcm_suspend*() calls from the runtime PM suspend callback code
      path, hence the racy OPEN state won't appear while runtime PM.
      (FWIW, the race window is between snd_pcm_open_substream() and the
      first power up in azx_pcm_open().)
      
      Although the runtime PM issue was already "fixed", the same problem is
      still present for the system PM, hence this patch is still needed.
      And for stable trees, this patch alone should suffice for fixing the
      runtime PM problem, too.
      Reported-and-tested-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      113ce081
  5. 22 Mar, 2019 5 commits
  6. 21 Mar, 2019 5 commits
  7. 19 Mar, 2019 2 commits
    • Hui Wang's avatar
      ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec · b5a236c1
      Hui Wang authored
      Recently we found the audio jack detection stop working after suspend
      on many machines with Realtek codec. Sometimes the audio selection
      dialogue didn't show up after users plugged headhphone/headset into
      the headset jack, sometimes after uses plugged headphone/headset, then
      click the sound icon on the upper-right corner of gnome-desktop, it
      also showed the speaker rather than the headphone.
      
      The root cause is that before suspend, the codec already call the
      runtime_suspend since this codec is not used by any apps, then in
      resume, it will not call runtime_resume for this codec. But for some
      realtek codec (so far, alc236, alc255 and alc891) with the specific
      BIOS, if it doesn't run runtime_resume after suspend, all codec
      functions including jack detection stop working anymore.
      
      This problem existed for a long time, but it was not exposed, that is
      because when problem happens, if users play sound or open
      sound-setting to check audio device, this will trigger calling to
      runtime_resume (via snd_hda_power_up), then the codec starts working
      again before users notice this problem.
      
      Since we don't know how many codec and BIOS combinations have this
      problem, to fix it, let the driver call runtime_resume for all codecs
      in pm_resume, maybe for some codecs, this is not needed, but it is
      harmless. After a codec is runtime resumed, if it is not used by any
      apps, it will be runtime suspended soon and furthermore we don't run
      suspend frequently, this change will not add much power consumption.
      
      Fixes: cc72da7d ("ALSA: hda - Use standard runtime PM for codec power-save control")
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b5a236c1
    • Hui Wang's avatar
      ALSA: hda - Don't trigger jackpoll_work in azx_resume · 744c67ff
      Hui Wang authored
      The commit 3baffc4a (ALSA: hda/intel: Refactoring PM code) changed
      the behaviour of azx_resume(), it triggers the jackpoll_work after
      applying this commit.
      
      This change introduced a new issue, all codecs are runtime active
      after S3, and will not call runtime_suspend() automatically.
      
      The root cause is the jackpoll_work calls snd_hda_power_up/down_pm,
      and it calls up_pm before snd_hdac_enter_pm is called, while calls
      the down_pm in the middle of enter_pm and leave_pm is called. This
      makes the dev->power.usage_count unbalanced after S3.
      
      To fix it, let azx_resume() don't trigger jackpoll_work as before
      it did.
      
      Fixes: 3baffc4a ("ALSA: hda/intel: Refactoring PM code")
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      744c67ff
  8. 18 Mar, 2019 2 commits
  9. 17 Mar, 2019 1 commit
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: use 'version' field of unit directory to identify model · 2d012c65
      Takashi Sakamoto authored
      Current ALSA firewire-motu driver uses the value of 'model' field
      of unit directory in configuration ROM for modalias for MOTU
      FireWire models. However, as long as I checked, Pre8 and
      828mk3(Hybrid) have the same value for the field (=0x100800).
      
      unit            | version   | model
      --------------- | --------- | ----------
      828mkII         | 0x000003  | 0x101800
      Traveler        | 0x000009  | 0x107800
      Pre8            | 0x00000f  | 0x100800 <-
      828mk3(FW)      | 0x000015  | 0x106800
      AudioExpress    | 0x000033  | 0x104800
      828mk3(Hybrid)  | 0x000035  | 0x100800 <-
      
      When updating firmware for MOTU 8pre FireWire from v1.0.0 to v1.0.3,
      I got change of the value from 0x100800 to 0x103800. On the other
      hand, the value of 'version' field is fixed to 0x00000f. As a quick
      glance, the higher 12 bits of the value of 'version' field represent
      firmware version, while the lower 12 bits is unknown.
      
      By induction, the value of 'version' field represents actual model.
      
      This commit changes modalias to match the value of 'version' field,
      instead of 'model' field. For degug, long name of added sound card
      includes hexadecimal value of 'model' field.
      
      Fixes: 6c5e1ac0 ("ALSA: firewire-motu: add support for Motu Traveler")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2d012c65
  10. 16 Mar, 2019 2 commits
  11. 14 Mar, 2019 3 commits
  12. 13 Mar, 2019 8 commits
  13. 28 Feb, 2019 2 commits
    • Manuel Reinhardt's avatar
      ALSA: usb-audio: Add quirk for MOTU MicroBook II · a634090a
      Manuel Reinhardt authored
      Add an entry to the quirks-table to for usb-audio to recognize the
      Microbook II (although it only exposes vendor interfaces). A simple boot
      quirk is also implemented to set up the sample rate and  make sure that
      no audio urbs are sent before the device is ready.
      
      This patch only provides audio playback and capture at 96kHz sample
      rate. Notice the following shortcomings:
      
      - The sample rate is currently hardcoded to 96k although the device also
        supports 48k and 44.1k.
      
      - The various mixer controls of the MicroBook are not made available.
      
      - The keep-iface control should be on by default because the device
        shuts down whenever the altsetting is reset which is usually unwanted.
        (I don't know the best way to do this)
      
      - The communication format used by the MicroBook for sample rate setting
        and also other setup has been reverse engineered by looking at the
        usbmon output while running the windows driver through virtualbox. In
        this patch the first byte of every message is set to \0 while in the
        observed communications the first byte acts as a "message-counter"
        increasing its value with every message sent. Leaving it at \0 does
        not seem to affect the device.
      Signed-off-by: default avatarManuel Reinhardt <manuel.rhdt@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a634090a
    • Takashi Iwai's avatar
      Merge tag 'asoc-v5.1-2' of... · 70395a96
      Takashi Iwai authored
      Merge tag 'asoc-v5.1-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
      
      ASoC: More changes for v5.1
      
      Another batch of changes for ASoC, no big core changes - it's mainly
      small fixes and improvements for individual drivers.
      
       - A big refresh and cleanup of the Samsung drivers, fixing a number of
         issues which allow the driver to be used with a wider range of
         userspaces.
       - Fixes for the Intel drivers to make them more standard so less likely
         to get bitten by core issues.
       - New driver for Cirrus Logic CS35L26.
      70395a96
  14. 26 Feb, 2019 5 commits