Skip to content
Snippets Groups Projects
  1. Jan 16, 2020
  2. Jan 14, 2020
  3. Jan 13, 2020
  4. Jan 11, 2020
    • Takashi Iwai's avatar
      ALSA: hda: Rename back to dmic_detect option · 7fba6aea
      Takashi Iwai authored
      We've got quite a few bug reports showing the SOF driver being loaded
      unintentionally recently, and the reason seems to be that users didn't
      know the module option change: with the recent kernel, a new option
      dsp_driver=1 has to be passed to a new module snd-intel-dspcfg
      instead of snd_hda_intel.dmic_detect=0 option.
      
      That is, actually there are two tricky things here:
      - We changed the whole detection in another module and another
        option semantics.
      - The existing option for skipping the DSP probe was also renamed.
      
      For avoiding the confusion and giving user more hint, this patch
      reverts the renamed option dsp_driver back to dmic_detect for
      snd-hda-intel module, and show the warning about the module option
      change when the non-default value is passed.
      
      Fixes: 82d9d54a ("ALSA: hda: add Intel DSP configuration / probe code")
      Link: https://lore.kernel.org/r/20200109082000.26729-1-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7fba6aea
  5. Jan 10, 2020
    • Olivier Moysan's avatar
      ASoC: stm32: dfsdm: fix 16 bits record · 8e55ea19
      Olivier Moysan authored
      
      In stm32_afsdm_pcm_cb function, the transfer size is provided in bytes.
      However, samples are copied as 16 bits words from iio buffer.
      Divide by two the transfer size, to copy the right number of samples.
      
      Fixes: 1e7f6e1c ("ASoC: stm32: dfsdm: add 16 bits audio record support")
      
      Signed-off-by: default avatarOlivier Moysan <olivier.moysan@st.com>
      Link: https://lore.kernel.org/r/20200110131131.3191-1-olivier.moysan@st.com
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      8e55ea19
    • Olivier Moysan's avatar
      ASoC: stm32: sai: fix possible circular locking · a14bf98c
      Olivier Moysan authored
      
      In current driver, locks can be taken as follows:
      - Register access: take a lock on regmap config and then on clock.
      - Master clock provider: take a lock on clock and then on regmap config.
      This can lead to the circular locking summarized below.
      
      Remove peripheral clock management through regmap framework, and manage
      peripheral clock in driver instead. On register access, lock on clock
      is taken first, which allows to avoid possible locking issue.
      
      [ 6696.561513] ======================================================
      [ 6696.567670] WARNING: possible circular locking dependency detected
      [ 6696.573842] 4.19.49 #866 Not tainted
      [ 6696.577397] ------------------------------------------------------
      [ 6696.583566] pulseaudio/6439 is trying to acquire lock:
      [ 6696.588697] 87b0a25b (enable_lock){..-.}, at: clk_enable_lock+0x64/0x128
      [ 6696.595377]
      [ 6696.595377] but task is already holding lock:
      [ 6696.601197] d858f825 (stm32_sai_sub:1342:(sai->regmap_config)->lock){....}
      ...
      [ 6696.812513]  Possible unsafe locking scenario:
      [ 6696.812513]
      [ 6696.818418]        CPU0                    CPU1
      [ 6696.822935]        ----                    ----
      [ 6696.827451]   lock(stm32_sai_sub:1342:(sai->regmap_config)->lock);
      [ 6696.833618]                                lock(enable_lock);
      [ 6696.839350]                                lock(stm32_sai_sub:1342:
                                                    (sai->regmap_config)->lock);
      [ 6696.848035]   lock(enable_lock);
      
      Fixes: 03e78a24 ("ASoC: stm32: sai: add h7 support")
      
      Signed-off-by: default avatarOlivier Moysan <olivier.moysan@st.com>
      Link: https://lore.kernel.org/r/20200109083254.478-1-olivier.moysan@st.com
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      a14bf98c
  6. Jan 09, 2020
  7. Jan 08, 2020
  8. Jan 07, 2020
  9. Jan 04, 2020
  10. Jan 03, 2020
  11. Dec 30, 2019
  12. Dec 29, 2019
  13. Dec 27, 2019
  14. Dec 25, 2019
  15. Dec 24, 2019
    • Takashi Iwai's avatar
      ALSA: hda - Apply sync-write workaround to old Intel platforms, too · c366b3db
      Takashi Iwai authored
      
      Klaus Ethgen reported occasional high CPU usages in his system that
      seem caused by HD-audio driver.  The perf output revealed that it's
      in the unsolicited event handling in the workqueue, and the problem
      seems triggered by some communication stall between the controller and
      the codec at the runtime or system resume.
      
      Actually a similar phenomenon was seen in the past for other Intel
      platforms, and we already applied the workaround to enforce sync-write
      for CORB/RIRB verbs for Skylake and newer chipsets (commit
      2756d914 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel
      chips").  Fortunately, the same workaround is applicable to the old
      chipset, and the experiment showed the positive effect.
      
      Based on the experiment result, this patch enables the sync-write
      workaround for all Intel chipsets.  The only reason I hesitated to
      apply this workaround was about the possibly slightly higher CPU usage.
      But if the lack of sync causes a much severer problem even for quite
      old chip, we should think this would be necessary for all Intel chips.
      
      Reported-by: default avatarKlaus Ethgen <Klaus@ethgen.ch>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191223171833.GA17053@chua
      Link: https://lore.kernel.org/r/20191223221816.32572-1-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c366b3db
  16. Dec 21, 2019