1. 02 Nov, 2021 2 commits
  2. 01 Nov, 2021 4 commits
  3. 29 Oct, 2021 29 commits
  4. 28 Oct, 2021 5 commits
    • Takashi Sakamoto's avatar
      ALSA: oxfw: fix functional regression for Mackie Onyx 1640i in v5.14 or later · cddcd547
      Takashi Sakamoto authored
      A user reports functional regression for Mackie Onyx 1640i that the device
      generates slow sound with ALSA oxfw driver which supports media clock
      recovery. Although the device is based on OXFW971 ASIC, it does not
      transfer isochronous packet with own event frequency as expected. The
      device seems to adjust event frequency according to events in received
      isochronous packets in the beginning of packet streaming. This is
      unknown quirk.
      
      This commit fixes the regression to turn the recovery off in driver
      side. As a result, nominal frequency is used in duplex packet streaming
      between device and driver. For stability of sampling rate in events of
      transferred isochronous packet, 4,000 isochronous packets are skipped
      in the beginning of packet streaming.
      
      Reference: https://github.com/takaswie/snd-firewire-improve/issues/38
      Fixes: 029ffc42 ("ALSA: oxfw: perform sequence replay for media clock recovery")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20211028130325.45772-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cddcd547
    • Nathan Chancellor's avatar
      ASoC: qdsp6: audioreach: Fix clang -Wimplicit-fallthrough · c6c203bc
      Nathan Chancellor authored
      Clang warns:
      
      sound/soc/qcom/qdsp6/topology.c:465:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
                      default:
                      ^
      sound/soc/qcom/qdsp6/topology.c:465:3: note: insert 'break;' to avoid fall-through
                      default:
                      ^
                      break;
      1 warning generated.
      
      Clang is a little more pedantic than GCC, which permits implicit
      fallthroughs to cases that contain just break or return. Clang's version
      is more in line with the kernel's own stance in deprecated.rst, which
      states that all switch/case blocks must end in either break,
      fallthrough, continue, goto, or return. Add the missing break to fix
      the warning.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/1495Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Link: https://lore.kernel.org/r/20211027190823.4057382-1-nathan@kernel.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c6c203bc
    • Julian Braha's avatar
      ASoC: fix unmet dependencies on GPIOLIB for SND_SOC_DMIC · 5c7dee44
      Julian Braha authored
      When SND_SOC_AMD_RENOIR_MACH or SND_SOC_AMD_RV_RT5682_MACH
      are selected, and GPIOLIB is not selected, Kbuild gives
      the following warnings, respectively:
      
      WARNING: unmet direct dependencies detected for SND_SOC_DMIC
        Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n]
        Selected by [y]:
        - SND_SOC_AMD_RENOIR_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AMD_RENOIR [=y]
      
      and
      
      WARNING: unmet direct dependencies detected for SND_SOC_MAX98357A
        Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n]
        Selected by [y]:
        - SND_SOC_AMD_RV_RT5682_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AMD_ACP3x [=y] && I2C [=y] && CROS_EC [=y]
      
      This is because SND_SOC_DMIC and SND_SOC_MAX98357A are
      selected by SND_SOC_AMD_RV_RT5682_MACH and SND_SOC_AMD_RENOIR_MACH,
      respectively. However, neither of the selectors depend on or select GPIOLIB,
      despite their selectees depending on GPIOLIB.
      
      These unmet dependency bugs were detected by Kismet,
      a static analysis tool for Kconfig. Please advise if this
      is not the appropriate solution.
      Signed-off-by: default avatarJulian Braha <julianbraha@gmail.com>
      Link: https://lore.kernel.org/r/20211027184835.112916-1-julianbraha@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      5c7dee44
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: export meter information to userspace as float value · 407359d4
      Takashi Sakamoto authored
      In command DSP models, one meter information consists of 4 bytes for
      IEEE 764 floating point (binary32). In previous patch, it is exported
      to userspace as 32 bit storage since the storage is also handled in
      ALSA firewire-motu driver as well in kernel space in which floating point
      arithmetic is not preferable. On the other hand, ALSA firewire-motu driver
      doesn't perform floating point calculation. The driver just gather meter
      information from isochronous packets and fill structure fields for
      userspace.
      
      In 'header' target of Kbuild, UAPI headers are processed before installed.
      In this timing, #ifdef macro with __KERNEL__ is removed. This mechanism
      is useful in the case so that the 32 bit storage can be accessible as u32
      type in kernel space and float type in user space. We can see the same
      usage in ''struct acct_v3' in 'include/uapi/linux/acct.h'.
      
      This commit is for the above idea. Additionally, due to message
      protocol, meter information is filled with 0xffffffff in the end of
      period but 0xffffffff is invalid as binary32. To avoid confusion in
      userspace application, the last two elements are left without any
      assignment.
      Suggested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20211027125529.54295-4-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      407359d4
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: refine parser for meter information in register DSP models · 0f166e12
      Takashi Sakamoto authored
      After further investigation, I realize that the total number of elements
      in array is not enough to store all of related messages from device.
      This commit refines meter array and message parser.
      
      In terms of channel identifier, register DSP models are classified to
      two categories:
      
      1. the target of output is selectable
      
      828mk2, 896hd, and Traveler are in the category. They transfer messages
      with channel identifier between 0x00 and 0x13 for input meters,
      therefore 20 elements are needed to store.
      
      On the other hand, they transfer messages with channel identifier for one
      pair of output meters. The selection is done by asynchronous write
      transaction to offset 0x'ffff'f000'0b2c. The table for relationship
      between written value and available identifiers is below:
      
      =============  ===============
      written value  identifier pair
      =============  ===============
      0x00000b00     0x80/0x81
      0x00000b01     0x82/0x83
      ...            ...
      0x00000b0b     0x96/0x97
      ...            ...
      0x00000b10     0xa0/0xa1
      ...            ...
      0x00000b3f     0xfe/0xff
      ...            ...
      greater        0xfe/0xff
      =============  ===============
      
      Actually in the above three models, 0x96/0x97 pair is the maximum. Thus
      the number of available output meter is 24.
      
      2. all of output is available
      
      8 pre, Ultralite, Audio Express, and 4 pre are in the category. They
      transfer messages for output meters without any selection. The table for
      available identifier for each direction is below:
      
      ==============  =========  ==========
      model           input      output
      ==============  =========  ==========
      8 pre           0x00-0x0f  0x82-0x8d
      Ultralite       0x00-0x09  0x82-0x8f
      Audio Express   0x00-0x09  0x80-0x8d
      4 pre           0x00-0x09  0x80-0x8d
      ==============  =========  ==========
      
      Some of available identifiers might not be used for actual output meters.
      
      Anyway, 24 plus 24 elements accommodate the input/output meters.
      
      I note that isochronous packet from V3HD/V4HD deliver no message.
      Notification by asynchronous transaction to registered address seems to be
      used for the purpose as well as for change of mixer parameter.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20211027125529.54295-3-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0f166e12