Skip to content

L
linux
Switch branch/tag
  1. 05 Jun, 2023 20 commits
  3. 02 Jun, 2023 4 commits
  5. 01 Jun, 2023 5 commits
  7. 31 May, 2023 7 commits
  9. 30 May, 2023 4 commits
    • Mark Brown's avatar
      ES8316 audio codec fixes on Rock5B · b48aa6a3
      Mark Brown authored 
      Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:

This patch series handles a few issues related to the ES8316 audio
codec, discovered while doing some testing on the Rock 5B board.
      b48aa6a3
    • Cristian Ciocaltea's avatar
      ASoC: es8316: Do not set rate constraints for unsupported MCLKs · 60413129
      Cristian Ciocaltea authored 
      When using the codec through the generic audio graph card, there are at
least two calls of es8316_set_dai_sysclk(), with the effect of limiting
the allowed sample rates according to the MCLK/LRCK ratios supported by
the codec:

1. During audio card setup, to set the initial MCLK - see
   asoc_simple_init_dai().

2. Before opening a stream, to update MCLK, according to the stream
   sample rate and the multiplication factor - see
   asoc_simple_hw_params().

In some cases the initial MCLK might be set to a frequency that doesn't
match any of the supported ratios, e.g. 12287999 instead of 12288000,
which is only 1 Hz below the supported clock, as that is what the
hardware reports. This creates an empty list of rate constraints, which
is further passed to snd_pcm_hw_constraint_list() via
es8316_pcm_startup(), and causes the following error on the very first
access of the sound card:

  $ speaker-test -D hw:Analog,0 -F S16_LE -c 2 -t wav
  Broken configuration for playback: no configurations available: Invalid argument
  Setting of hwparams failed: Invalid argument

Note that all subsequent retries succeed thanks to the updated MCLK set
at point 2 above, which uses a computed frequency value instead of a
reading from the hardware registers. Normally this would have mitigated
the issue, but es8316_pcm_startup() executes before the 2nd call to
es8316_set_dai_sysclk(), hence it cannot make use of the updated
constraints.

Since es8316_pcm_hw_params() performs anyway a final validation of MCLK
against the stream sample rate and the supported MCLK/LRCK ratios, fix
the issue by ensuring that sysclk_constraints list is only set when at
least one supported sample rate is autodetected by the codec.

Fixes: b8b88b70 ("ASoC: add es8316 codec driver")
Signed-off-by: default avatarCristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230530181140.483936-3-cristian.ciocaltea@collabora.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      60413129
    • Cristian Ciocaltea's avatar
      ASoC: es8316: Increment max value for ALC Capture Target Volume control · 6f073429
      Cristian Ciocaltea authored 
      The following error occurs when trying to restore a previously saved
ALSA mixer state (tested on a Rock 5B board):

  $ alsactl --no-ucm -f /tmp/asound.state store hw:Analog
  $ alsactl --no-ucm -I -f /tmp/asound.state restore hw:Analog
  alsactl: set_control:1475: Cannot write control '2:0:0:ALC Capture Target Volume:0' : Invalid argument

According to ES8316 datasheet, the register at address 0x2B, which is
related to the above mixer control, contains by default the value 0xB0.
Considering the corresponding ALC target bits (ALCLVL) are 7:4, the
control is initialized with 11, which is one step above the maximum
value allowed by the driver:

 ALCLVL | dB gain
 -------+--------
  0000  |  -16.5
  0001  |  -15.0
  0010  |  -13.5
  ....  |  .....
  0111  |   -6.0
  1000  |   -4.5
  1001  |   -3.0
  1010  |   -1.5
  ....  |  .....
  1111  |   -1.5

The tests performed using the VU meter feature (--vumeter=TYPE) of
arecord/aplay confirm the specs are correct and there is no measured
gain if the 1011-1111 range would have been mapped to 0 dB:

 dB gain | VU meter %
 --------+-----------
   -6.0  |  30-31
   -4.5  |  35-36
   -3.0  |  42-43
   -1.5  |  50-51
    0.0  |  50-51

Increment the max value allowed for ALC Capture Target Volume control,
so that it matches the hardware default.  Additionally, update the
related TLV to prevent an artificial extension of the dB gain range.

Fixes: b8b88b70 ("ASoC: add es8316 codec driver")
Signed-off-by: default avatarCristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230530181140.483936-2-cristian.ciocaltea@collabora.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      6f073429
    • Mark Brown's avatar
      ASoC: topology: allow for partial dailink stream_name · f2d4aa7e
      Mark Brown authored 
      Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:

The topology file and the machine driver rely on common definitions
for the dailink stream_name.  To avoid any backwards-compatibility
problems, the machine driver stream names are set in stone and cannot
be modified.

This is problematic when we try to name some of the topology widgets
after the stream_name, since the widget name is limited to 44
characters

tools/include/uapi/sound/asound.h:#define SNDRV_CTL_ELEM_ID_NAME_MAXLEN 44

Existing examples include "Analog Playback and Capture" for HDaudio
dailinks, which leaves less than 20 chars to identify widgets/controls
with a meaningful name.

Since the 44-char limit is part of the UAPI definitions, we assumed
there is no way to increase it.

This patchset suggests instead a partial match which allows topology
files to use a shorter stream_name, which in turn allows for
self-explanatory widget names that comply with the 44-char limit.

This should not break any existing setup but with the introduction of
a partial match new dailinks should be named carefully to avoid
confusions between e.g. 'link1' and 'link10'. The last patch fixes
such an issue in the 'nocodec' test topology used by Intel.
      f2d4aa7e
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7