Skip to content

L
linux
Switch branch/tag
  1. 29 May, 2020 1 commit
  3. 28 May, 2020 2 commits
  5. 27 May, 2020 2 commits
  7. 26 May, 2020 3 commits
  9. 25 May, 2020 1 commit
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: add support for MOTU UltraLite-mk3 (FireWire only model) · e0b2db35
      Takashi Sakamoto authored 
      UltraLite-mk3 was shipped 2008 by MOTU. This model has two lineups;
FireWire-only and FireWire/USB2.0 Hybrid model. Additionally, the latter
has two variants in respect of the type of IEEE 1394 connector; alpha
and beta connector.

This commit adds support for the FireWire-only model, which is already
discontinued.

$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  0410353a  bus_info_length 4, crc_length 16, crc 13626
404  31333934  bus_name "1394"
408  20ff7000  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c  0001f200  company_id 0001f2     |
410  000902c7  device_id 00000902c7  | EUI-64 0001f200000902c7

               root directory
               -----------------------------------------------------------------
414  0004ef04  directory_length 4, crc 61188
418  030001f2  vendor
41c  0c0083c0  node capabilities per IEEE 1394
420  d1000002  --> unit directory at 428
424  8d000005  --> eui-64 leaf at 438

               unit directory at 428
               -----------------------------------------------------------------
428  00035556  directory_length 3, crc 21846
42c  120001f2  specifier id
430  13000019  version
434  17100800  model

               eui-64 leaf at 438
               -----------------------------------------------------------------
438  0002f3c5  leaf_length 2, crc 62405
43c  0001f200  company_id 0001f2     |
440  000902c7  device_id 00000902c7  | EUI-64 0001f200000902c7
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200523071733.170129-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e0b2db35
  11. 22 May, 2020 14 commits
  13. 19 May, 2020 1 commit
  15. 18 May, 2020 3 commits
    • Scott Bahling's avatar
      ALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option · b0cb0990
      Scott Bahling authored 
      The ST Audio ADCIII is an STDSP24 card plus extension box. With commit
e8a91ae1 ("ALSA: ice1712: Add support for STAudio ADCIII") we
enabled the ADCIII ports using the model=staudio option but forgot
this part to ensure the STDSP24 card is initialized properly.

Fixes: e8a91ae1 ("ALSA: ice1712: Add support for STAudio ADCIII")
Signed-off-by: default avatarScott Bahling <sbahling@suse.com>
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1048934
Link: https://lore.kernel.org/r/20200518175728.28766-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b0cb0990
    • Christian Lachner's avatar
      ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme · d9e8fe0c
      Christian Lachner authored 
      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: default avatarChristian Lachner <gladiac@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200518053844.42743-2-gladiac@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d9e8fe0c
    • Brent Lu's avatar
      ALSA: pcm: fix incorrect hw_base increase · e7513c57
      Brent Lu authored 
      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: default avatarBrent Lu <brent.lu@intel.com>
Reviewed-by: default avatarJaroslav 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: default avatarTakashi Iwai <tiwai@suse.de>
      e7513c57
  17. 16 May, 2020 3 commits
  19. 15 May, 2020 2 commits
  21. 14 May, 2020 1 commit
  23. 12 May, 2020 4 commits
  25. 11 May, 2020 1 commit
  27. 10 May, 2020 2 commits
    • Takashi Sakamoto's avatar
      ALSA: fireface: add support for RME Fireface UFX (untested) · 1f65e668
      Takashi Sakamoto authored 
      Fireface UFX was shipped by RME GmbH in 2010, and now discontinued.
Although this model has some enhanced feature which Fireface 802
doesn't have (e.g. on-board USB mass storage device class, configuration
interface with color display), the functionality relevant to
packet communication on IEEE 1394 bus seems to be the same as
Fireface 802 (e.g. available number of channels for PCM frame in
each sampling transfer frequency).

With the assumption, this commit adds support for Fireface UFX. In ALSA
fireface driver, these two models are handled as the same one.
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-7-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1f65e668
    • Takashi Sakamoto's avatar
      ALSA: fireface: add support for RME FireFace 802 · 062bb452
      Takashi Sakamoto authored 
      Fireface 802 was shipped by RME GmbH in 2014. This model supports later
protocol for management of isochronous communication and synchronization
of sampling transmission frequency.

This model consists of below ICs:
 * TI TSB41AB2
 * Xilinx Spartan-6 FPGA XC6SLX16
 * TI TMS320 C6747
 * SMSC USB3250

Especially, this model just supports IEEE 1394a, against its name which
evokes Fireface 800.

This commit adds support for Fireface 802 (tested). Userspace applications
can transfer PCM frames and MIDI messages via ALSA PCM/Rawmidi interface.
I note that 4 channels for ADAt1 and ADAT2 are disabled at higher sampling
transfer frequency since isochronous resources reservation fails due to
bandwidth limitation of IEEE 1394a.

The value read from LATTER_SYNC_STATUS register is slightly different
from the one of Fireface UCX. The higher 4 bits and lower 4 bits are
swapped within the same byte.

Without any assist of userspace application, transmitted MIDI messages
from the device are not going to be processed. For detail, please refer
to my comment in code of latter protocol.

$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  0404ffff  bus_info_length 4, crc_length 4, crc 65535 (should be 26805)
404  31333934  bus_name "1394"
408  20008000  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 8 (512)
40c  000a3504  company_id 000a35     |
410  38077423  device_id 0438077423  | EUI-64 000a350438077423

               root directory
               -----------------------------------------------------------------
414  0005ffff  directory_length 5, crc 65535 (should be 9514)
418  0c0083c0  node capabilities per IEEE 1394
41c  03000a35  vendor
420  8100000b  --> descriptor leaf at 44c
424  8d000007  --> eui-64 leaf at 440
428  d1000001  --> unit directory at 42c

               unit directory at 42c
               -----------------------------------------------------------------
42c  0004ffff  directory_length 4, crc 65535 (should be 45134)
430  12000a35  specifier id
434  13000005  version
438  17101800  model
43c  81000008  --> descriptor leaf at 45c

               eui-64 leaf at 440
               -----------------------------------------------------------------
440  0002ffff  leaf_length 2, crc 65535 (should be 60131)
444  000a3504  company_id 000a35     |
448  38077423  device_id 0438077423  | EUI-64 000a350438077423

               descriptor leaf at 44c
               -----------------------------------------------------------------
44c  0003ffff  leaf_length 3, crc 65535 (should be 469)
450  00000000  textual descriptor
454  00000000  minimal ASCII
458  524d4521  "RME!"

               descriptor leaf at 45c
               -----------------------------------------------------------------
45c  0005ffff  leaf_length 5, crc 65535 (should be 10561)
460  00000000  textual descriptor
464  00000000  minimal ASCII
468  46697265  "Fire"
46c  66616365  "face"
470  20383032  " 802"
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-6-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      062bb452
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7