An error occurred fetching the project authors.
  1. 23 Feb, 2024 1 commit
  2. 13 Feb, 2024 1 commit
  3. 08 Feb, 2024 1 commit
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Fix deadlock in ASP1 mixer register initialization · c14f09f0
      Richard Fitzgerald authored
      Rewrite the handling of ASP1 TX mixer mux initialization to prevent a
      deadlock during component_remove().
      
      The firmware can overwrite the ASP1 TX mixer registers with
      system-specific settings. This is mainly for hardware that uses the
      ASP as a chip-to-chip link controlled by the firmware. Because of this
      the driver cannot know the starting state of the ASP1 mixer muxes until
      the firmware has been downloaded and rebooted.
      
      The original workaround for this was to queue a work function from the
      dsp_work() job. This work then read the register values (populating the
      regmap cache the first time around) and then called
      snd_soc_dapm_mux_update_power(). The problem with this is that it was
      ultimately triggered by cs35l56_component_probe() queueing dsp_work,
      which meant that it would be running in parallel with the rest of the
      ASoC component and card initialization. To prevent accessing DAPM before
      it was fully initialized the work function took the card mutex. But this
      would deadlock if cs35l56_component_remove() was called before the work job
      had completed, because ASoC calls component_remove() with the card mutex
      held.
      
      This new version removes the work function. Instead the regmap cache and
      DAPM mux widgets are initialized the first time any of the associated ALSA
      controls is read or written.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: 07f7d6e7 ("ASoC: cs35l56: Fix for initializing ASP1 mixer registers")
      Link: https://lore.kernel.org/r/20240208123742.1278104-1-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c14f09f0
  4. 05 Feb, 2024 1 commit
  5. 01 Feb, 2024 8 commits
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Load tunings for the correct speaker models · 245eeff1
      Richard Fitzgerald authored
      If the "spk-id-gpios" property is present it points to GPIOs whose
      value must be used to select the correct bin file to match the
      speakers.
      
      Some manufacturers use multiple sources of speakers, which need
      different tunings for best performance. On these models the type of
      speaker fitted is indicated by the values of one or more GPIOs. The
      number formed by the GPIOs identifies the tuning required.
      
      The speaker ID must be used in combination with the subsystem ID
      (either from PCI SSID or cirrus,firmware-uid property), because the
      GPIOs can only indicate variants of a specific model.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: 1a1c3d79 ("ASoC: cs35l56: Use PCI SSID as the firmware UID")
      Link: https://msgid.link/r/20240129162737.497-14-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      245eeff1
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Firmware file must match the version of preloaded firmware · f4ef5149
      Richard Fitzgerald authored
      Check during initialization whether the firmware is already patched.
      If so, include the firmware version in the wm_adsp fwf_name string.
      
      If the firmware has already been patched by the BIOS the driver
      can only replace it if it has control of hard RESET.
      
      If the driver cannot replace the firmware, it can still load a wmfw
      (for ALSA control definitions) and/or a bin (for additional tunings).
      But these must match the version of firmware that is running on the
      CS35L56.
      
      The firmware is pre-patched if FIRMWARE_MISSING == 0.
      
      Including the firmware version in the fwf_name string will
      qualify the firmware file name:
      
      Normal (unpatched or replaceable firmware):
        cs35l56-rev-dsp1-misc[-system_name].[wmfw|bin]
      
      Preloaded firmware:
        cs35l56-rev[-s]-VVVVVV-dsp1-misc[-system_name].[wmfw|bin]
      
      Where:
         [-s] is an optional -s added into the name for a secured CS35L56
         VVVVVV is the 24-bit firmware version in hexadecimal.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: 608f1b0d ("ASoC: cs35l56: Move DSP part string generation so that it is done only once")
      Link: https://msgid.link/r/20240129162737.497-13-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      f4ef5149
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Fix misuse of wm_adsp 'part' string for silicon revision · f6c96794
      Richard Fitzgerald authored
      Put the silicon revision and secured flag in the wm_adsp fwf_name
      string instead of including them in the part string.
      
      This changes the format of the firmware name string from
      
       cs35l56[s]-rev-misc[-system_name]
      
      to
       cs35l56-rev[-s]-misc[-system_name]
      
      No firmware files have been published, so this doesn't cause a
      compatibility break.
      
      Silicon revision and secured flag are included in the firmware
      filename to pick a firmware compatible with the part. These strings
      were being added to the part string, but that is a misuse of the
      string. The correct place for these is the fwf_name string, which
      is specifically intended to select between multiple firmware files
      for the same part.
      
      Backport note:
      This won't apply to kernels older than v6.6.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: 608f1b0d ("ASoC: cs35l56: Move DSP part string generation so that it is done only once")
      Link: https://msgid.link/r/20240129162737.497-12-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      f6c96794
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Fix for initializing ASP1 mixer registers · 07f7d6e7
      Richard Fitzgerald authored
      Defer initializing the state of the ASP1 mixer registers until
      the firmware has been downloaded and rebooted.
      
      On a SoundWire system the ASP is free for use as a chip-to-chip
      interconnect. This can be either for the firmware on multiple
      CS35L56 to share reference audio; or as a bridge to another
      device. If it is a firmware interconnect it is owned by the
      firmware and the Linux driver should avoid writing the registers.
      However, if it is a bridge then Linux may take over and handle
      it as a normal codec-to-codec link. Even if the ASP is used
      as a firmware-firmware interconnect it is useful to have
      ALSA controls for the ASP mixer. They are at least useful for
      debugging.
      
      CS35L56 is designed for SDCA and a generic SDCA driver would
      know nothing about these chip-specific registers. So if the
      ASP is being used on a SoundWire system the firmware sets up the
      ASP mixer registers. This means that we can't assume the default
      state of these registers. But we don't know the initial state
      that the firmware set them to until after the firmware has been
      downloaded and booted, which can take several seconds when
      downloading multiple amps.
      
      DAPM normally reads the initial state of mux registers during
      probe() but this would mean blocking probe() for several seconds
      until the firmware has initialized them. To avoid this, the
      mixer muxes are set SND_SOC_NOPM to prevent DAPM trying to read
      the register state. Custom get/set callbacks are implemented for
      ALSA control access, and these can safely block waiting for the
      firmware download.
      
      After the firmware download has completed, the state of the
      mux registers is known so a work job is queued to call
      snd_soc_dapm_mux_update_power() on each of the mux widgets.
      
      Backport note:
      This won't apply cleanly to kernels older than v6.6.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: e4961125 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
      Link: https://msgid.link/r/20240129162737.497-11-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      07f7d6e7
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Fix to ensure ASP1 registers match cache · 72a77d76
      Richard Fitzgerald authored
      Add a dummy SUPPLY widget connected to the ASP that forces the
      chip registers to match the regmap cache when the ASP is
      powered-up.
      
      On a SoundWire system the ASP is free for use as a chip-to-chip
      interconnect. This can be either for the firmware on multiple
      CS35L56 to share reference audio; or as a bridge to another
      device. If it is a firmware interconnect it is owned by the
      firmware and the Linux driver should avoid writing the registers.
      However. If it is a bridge then Linux may take over and handle
      it as a normal codec-to-codec link.
      
      CS35L56 is designed for SDCA and a generic SDCA driver would
      know nothing about these chip-specific registers. So if the
      ASP is being used on a SoundWire system the firmware sets up the
      ASP registers. This means that we can't assume the default
      state of the ASP registers. But we don't know the initial state
      that the firmware set them to until after the firmware has been
      downloaded and booted, which can take several seconds when
      downloading multiple amps.
      
      To avoid blocking probe() for several seconds waiting for the
      firmware, the silicon defaults are assumed. This allows the machine
      driver to setup the ASP configuration during probe() without being
      blocked. If the ASP is hooked up and used, the SUPPLY widget
      ensures that the chip registers match what was configured in the
      regmap cache.
      
      If the machine driver does not hook up the ASP, it is assumed that
      it won't call any functions to configure the ASP DAI. Therefore
      the regmap cache will be clean for these registers so a
      regcache_sync() will not overwrite the chip registers. If the
      DAI is not hooked up, the dummy SUPPLY widget will not be
      invoked so it will never force-overwrite the chip registers.
      
      Backport note:
      This won't apply cleanly to kernels older than v6.6.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: e4961125 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
      Link: https://msgid.link/r/20240129162737.497-8-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      72a77d76
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Don't add the same register patch multiple times · 07687cd0
      Richard Fitzgerald authored
      Move the call to cs35l56_set_patch() earlier in cs35l56_init() so
      that it only adds the register patch on first-time initialization.
      
      The call was after the post_soft_reset label, so every time this
      function was run to re-initialize the hardware after a reset it would
      call regmap_register_patch() and add the same reg_sequence again.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: 898673b9 ("ASoC: cs35l56: Move shared data into a common data structure")
      Link: https://msgid.link/r/20240129162737.497-6-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      07687cd0
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: cs35l56_component_remove() must clean up wm_adsp · cd38ccbe
      Richard Fitzgerald authored
      cs35l56_component_remove() must call wm_adsp_power_down() and
      wm_adsp2_component_remove().
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: e4961125 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
      Link: https://msgid.link/r/20240129162737.497-5-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      cd38ccbe
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: cs35l56_component_remove() must clear cs35l56->component · ae861c46
      Richard Fitzgerald authored
      The cs35l56->component pointer is used by the suspend-resume handling to
      know whether the driver is fully instantiated. This is to prevent it
      queuing dsp_work which would result in calling wm_adsp when the driver
      is not an instantiated ASoC component. So this pointer must be cleared
      by cs35l56_component_remove().
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Fixes: e4961125 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
      Link: https://msgid.link/r/20240129162737.497-4-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      ae861c46
  6. 09 Oct, 2023 2 commits
  7. 14 Sep, 2023 2 commits
  8. 12 Sep, 2023 1 commit
  9. 11 Sep, 2023 1 commit
  10. 17 Aug, 2023 1 commit
  11. 15 Aug, 2023 2 commits
  12. 08 Aug, 2023 4 commits
  13. 23 Jul, 2023 8 commits
  14. 18 Jul, 2023 1 commit
  15. 01 Jun, 2023 1 commit
  16. 19 May, 2023 3 commits
  17. 15 May, 2023 1 commit
  18. 20 Apr, 2023 1 commit