1. 26 5月, 2020 2 次提交
  2. 19 5月, 2020 2 次提交
  3. 18 5月, 2020 2 次提交
    • C
      ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme · d9e8fe0c
      Christian Lachner 提交于
      The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec
      requires a similar workaround for Clevo laptops to enforce the
      DAC/mixer connection path. Set up a quirk entry for that.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275Signed-off-by: NChristian Lachner <gladiac@gmail.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200518053844.42743-2-gladiac@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      d9e8fe0c
    • B
      ALSA: pcm: fix incorrect hw_base increase · e7513c57
      Brent Lu 提交于
      There is a corner case that ALSA keeps increasing the hw_ptr but DMA
      already stop working/updating the position for a long time.
      
      In following log we can see the position returned from DMA driver does
      not move at all but the hw_ptr got increased at some point of time so
      snd_pcm_avail() will return a large number which seems to be a buffer
      underrun event from user space program point of view. The program
      thinks there is space in the buffer and fill more data.
      
      [  418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
      [  418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
      ...
      [  418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
      [  418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
      [  418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368
      
      This is because the hw_base will be increased by runtime->buffer_size
      frames unconditionally if the hw_ptr is not updated for over half of
      buffer time. As the hw_base increases, so does the hw_ptr increased
      by the same number.
      
      The avail value returned from snd_pcm_avail() could exceed the limit
      (buffer_size) easily becase the hw_ptr itself got increased by same
      buffer_size samples when the corner case happens. In following log,
      the buffer_size is 16368 samples but the avail is 21810 samples so
      CRAS server complains about it.
      
      [  418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
      [  418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810
      
      cras_server[1907]: pcm_avail returned frames larger than buf_size:
      sof-glkda7219max: :0,5: 21810 > 16368
      
      By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
      the hw_base will keep the same when buffer stall happens at long as
      the interval between each HWSYNC call is shorter than half of buffer
      time.
      
      Following is a log captured by a patched kernel. The hw_base/hw_ptr
      value is fixed in this corner case and user space program should be
      aware of the buffer stall and handle it.
      
      [  293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
      [  293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
      [  293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
      [  293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
      [  293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
      ...
      [  381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
      Signed-off-by: NBrent Lu <brent.lu@intel.com>
      Reviewed-by: NJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      e7513c57
  4. 15 5月, 2020 1 次提交
  5. 12 5月, 2020 4 次提交
  6. 10 5月, 2020 1 次提交
  7. 08 5月, 2020 1 次提交
  8. 04 5月, 2020 3 次提交
  9. 03 5月, 2020 1 次提交
    • T
      ALSA: firewire-lib: fix 'function sizeof not defined' error of tracepoints format · 10348721
      Takashi Sakamoto 提交于
      The snd-firewire-lib.ko has 'amdtp-packet' event of tracepoints. Current
      printk format for the event includes 'sizeof(u8)' macro expected to be
      extended in compilation time. However, this is not done. As a result,
      perf tools cannot parse the event for printing:
      
      $ mount -l -t debugfs
      debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
      $ cat /sys/kernel/debug/tracing/events/snd_firewire_lib/amdtp_packet/format
      ...
      print fmt: "%02u %04u %04x %04x %02d %03u %02u %03u %02u %01u %02u %s",
        REC->second, REC->cycle, REC->src, REC->dest, REC->channel,
        REC->payload_quadlets, REC->data_blocks, REC->data_block_counter,
        REC->packet_index, REC->irq, REC->index,
        __print_array(__get_dynamic_array(cip_header),
                      __get_dynamic_array_len(cip_header),
                      sizeof(u8))
      
      $ sudo perf record -e snd_firewire_lib:amdtp_packet
        [snd_firewire_lib:amdtp_packet] function sizeof not defined
        Error: expected type 5 but read 0
      
      This commit fixes it by obsoleting the macro with actual size.
      
      Cc: <stable@vger.kernel.org>
      Fixes: bde2bbdb ("ALSA: firewire-lib: use dynamic array for CIP header of tracing events")
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20200503045718.86337-1-o-takashi@sakamocchi.jpSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      10348721
  10. 01 5月, 2020 1 次提交
  11. 30 4月, 2020 2 次提交
    • T
      ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID · 547d2c9c
      Takashi Iwai 提交于
      The USB vendor ID of NuPrime DAC-10 is not 16b0 but 16d0.
      
      Fixes: f656891c ("ALSA: usb-audio: add more quirks for DSD interfaces")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200430124755.15940-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      547d2c9c
    • A
      ALSA: opti9xx: shut up gcc-10 range warning · 5ce00760
      Arnd Bergmann 提交于
      gcc-10 points out a few instances of suspicious integer arithmetic
      leading to value truncation:
      
      sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure':
      sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
        322 |   (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask)))
            |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
      sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask'
        351 |   snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
            |   ^~~~~~~~~~~~~~~~~~~~~~
      sound/isa/opti9xx/miro.c: In function 'snd_miro_configure':
      sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
        873 |   (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask)))
            |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
      sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask'
       1010 |   snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
            |   ^~~~~~~~~~~~~~~~~~~
      
      These are all harmless here as only the low 8 bit are passed down
      anyway. Change the macros to inline functions to make the code
      more readable and also avoid the warning.
      
      Strictly speaking those functions also need locking to make the
      read/write pair atomic, but it seems unlikely that anyone would
      still run into that issue.
      
      Fixes: 1841f613 ("[ALSA] Add snd-miro driver")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20200429190216.85919-1-arnd@arndb.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      5ce00760
  12. 29 4月, 2020 1 次提交
  13. 28 4月, 2020 1 次提交
  14. 27 4月, 2020 1 次提交
  15. 26 4月, 2020 1 次提交
  16. 25 4月, 2020 3 次提交
  17. 24 4月, 2020 1 次提交
    • T
      ALSA: hda: Match both PCI ID and SSID for driver blacklist · 977dfef4
      Takashi Iwai 提交于
      The commit 3c6fd1f0 ("ALSA: hda: Add driver blacklist") added a
      new blacklist for the devices that are known to have empty codecs, and
      one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f).
      However, it turned out that the very same PCI SSID is used for the
      previous model that does have the valid HD-audio codecs and the change
      broke the sound on it.
      
      Since the empty codec problem appear on the certain AMD platform (PCI
      ID 1022:1487), this patch changes the blacklist matching to both PCI
      ID and SSID using pci_match_id().  Also, the entry that was removed by
      the previous fix for ASUS ROG Zenigh II is re-added.
      
      Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      977dfef4
  18. 23 4月, 2020 3 次提交
  19. 22 4月, 2020 3 次提交
  20. 21 4月, 2020 3 次提交
  21. 20 4月, 2020 3 次提交
    • Y
      ASoC: wm89xx: Add missing dependency · 9bff3d30
      YueHaibing 提交于
      sound/soc/codecs/wm8900.o: In function `wm8900_i2c_probe':
      wm8900.c:(.text+0xa36): undefined reference to `__devm_regmap_init_i2c'
      sound/soc/codecs/wm8900.o: In function `wm8900_modinit':
      wm8900.c:(.init.text+0xb): undefined reference to `i2c_register_driver'
      sound/soc/codecs/wm8900.o: In function `wm8900_exit':
      wm8900.c:(.exit.text+0x8): undefined reference to `i2c_del_driver'
      sound/soc/codecs/wm8988.o: In function `wm8988_i2c_probe':
      wm8988.c:(.text+0x857): undefined reference to `__devm_regmap_init_i2c'
      sound/soc/codecs/wm8988.o: In function `wm8988_modinit':
      wm8988.c:(.init.text+0xb): undefined reference to `i2c_register_driver'
      sound/soc/codecs/wm8988.o: In function `wm8988_exit':
      wm8988.c:(.exit.text+0x8): undefined reference to `i2c_del_driver'
      sound/soc/codecs/wm8995.o: In function `wm8995_i2c_probe':
      wm8995.c:(.text+0x1c4f): undefined reference to `__devm_regmap_init_i2c'
      sound/soc/codecs/wm8995.o: In function `wm8995_modinit':
      wm8995.c:(.init.text+0xb): undefined reference to `i2c_register_driver'
      sound/soc/codecs/wm8995.o: In function `wm8995_exit':
      wm8995.c:(.exit.text+0x8): undefined reference to `i2c_del_driver'
      
      Add SND_SOC_I2C_AND_SPI dependency to fix this.
      
      Fixes: ea00d952 ("ASoC: Use imply for SND_SOC_ALL_CODECS")
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Acked-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20200420125343.20920-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>
      9bff3d30
    • M
      Merge series "ASoC: rsnd: multi-SSI setup fixes" from Matthias Blankertz... · bce32169
      Mark Brown 提交于
      Merge series "ASoC: rsnd: multi-SSI setup fixes" from Matthias Blankertz <matthias.blankertz@cetitec.com>:
      
      Fix rsnd_dai_call() operations being performed twice for the master SSI
      in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI
      setups.
      The only visible effect of these issues was some "status check failed"
      spam when the rsnd_ssi_stop was called, but overall the code is cleaner
      now, and some questionable writes to the SSICR register which did not
      lead to any observable misbehaviour but were contrary to the datasheet
      are fixed.
      
      Mark:
      The first patch kind of reverts my "ASoC: rsnd: Fix parent SSI
      start/stop in multi-SSI mode" from a few days ago and achieves the same
      effect in a simpler fashion, if you would prefer a clean patch series
      based on v5.6 drop me a note.
      
      Greetings,
      	Matthias
      
      Matthias Blankertz (2):
        ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent
        ASoC: rsnd: Fix "status check failed" spam for multi-SSI
      
       sound/soc/sh/rcar/ssi.c | 18 +++++++++++++-----
       1 file changed, 13 insertions(+), 5 deletions(-)
      
      base-commit: 15a5760c
      --
      2.26.1
      bce32169
    • M
      Merge series "ASoC: meson: fix codec-to-codec link setup" from Jerome Brunet... · 036889b2
      Mark Brown 提交于
      Merge series "ASoC: meson: fix codec-to-codec link setup" from Jerome Brunet <jbrunet@baylibre.com>:
      
      This patchset fixes the problem reported by Marc in this thread [0]
      The problem was due to an error in the meson card drivers which had
      the "no_pcm" dai_link property set on codec-to-codec links
      
      [0]: https://lore.kernel.org/r/20200417122732.GC5315@sirena.org.uk
      
      Jerome Brunet (2):
        ASoC: meson: axg-card: fix codec-to-codec link setup
        ASoC: meson: gx-card: fix codec-to-codec link setup
      
       sound/soc/meson/axg-card.c | 4 +++-
       sound/soc/meson/gx-card.c  | 4 +++-
       2 files changed, 6 insertions(+), 2 deletions(-)
      
      --
      2.25.2
      036889b2