Skip to content
  1. Aug 04, 2021
  2. Aug 03, 2021
  3. Aug 02, 2021
  4. Jul 31, 2021
  5. Jul 30, 2021
  6. Jul 28, 2021
  7. Jul 27, 2021
  8. Jul 26, 2021
    • Mark Brown's avatar
      ASoC: tlv320aic31xx: Fix jack detection after suspend · 2c39ca68
      Mark Brown authored
      
      
      The tlv320aic31xx driver relies on regcache_sync() to restore the register
      contents after going to _BIAS_OFF, for example during system suspend. This
      does not work for the jack detection configuration since that is configured
      via the same register that status is read back from so the register is
      volatile and not cached. This can also cause issues during init if the jack
      detection ends up getting set up before the CODEC is initially brought out
      of _BIAS_OFF, we will reset the CODEC and resync the cache as part of that
      process.
      
      Fix this by explicitly reapplying the jack detection configuration after
      resyncing the register cache during power on.
      
      This issue was found by an engineer working off-list on a product
      kernel, I just wrote up the upstream fix.
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Link: https://lore.kernel.org/r/20210723180200.25105-1-broonie@kernel.org
      Cc: stable@vger.kernel.org
      2c39ca68
  9. Jul 22, 2021
  10. Jul 19, 2021
  11. Jul 16, 2021
  12. Jul 14, 2021
  13. Jul 12, 2021
    • Maxim Schwalm's avatar
      ASoC: rt5631: Fix regcache sync errors on resume · c71f78a6
      Maxim Schwalm authored
      The ALC5631 does not like multi-write accesses, avoid them. This fixes:
      
      rt5631 4-001a: Unable to sync registers 0x3a-0x3c. -121
      
      errors on resume from suspend (and all registers after the registers in
      the error not being synced).
      
      Inspired by commit 2d30e949
      
       ("ASoC: rt5651: Fix regcache sync errors
      on resume") from Hans de Geode, which fixed the same errors on ALC5651.
      
      Signed-off-by: default avatarMaxim Schwalm <maxim.schwalm@gmail.com>
      Link: https://lore.kernel.org/r/20210712005011.28536-1-digetx@gmail.com
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c71f78a6
    • Mark Brown's avatar
      Merge series "arm64: tegra: Enable audio IOMMU support on Tegra194" from... · 11169c6e
      Mark Brown authored
      Merge series "arm64: tegra: Enable audio IOMMU support on Tegra194" from Thierry Reding <thierry.reding@gmail.com>
      Thierry Reding <treding@nvidia.com>:
      
      From: Thierry Reding <treding@nvidia.com>
      
      This small series addresses a minor issue with how IOMMU support is
      wired up on various Tegra generations. Currently the virtual "card"
      device is used to allocate DMA memory for, but since that device does
      not actually exist, the path to memory cannot be correctly described.
      
      To address this, this series moves to using the ADMAIF as the DMA device
      for audio. This is a real device that can have a proper DMA mask set and
      with which a stream ID can be associated with in the SMMU. The memory
      accesses technically originate from the ADMA controller (that the ADMAIF
      uses), but DMA channel are dynamically allocated at runtime while DMA
      memory is allocated at driver load time, drivers won't have access to
      the ADMA device yet.
      
      Further patches will be required to correct this issue on Tegra186 and
      Tegra210, but I wanted to get feedback on this approach first.
      
      Changes in v2:
      - add backwards-compatibility fallback
      
      Thierry
      
      Thierry Reding (2):
        ASoC: tegra: Use ADMAIF component for DMA allocations
        arm64: tegra: Enable audio IOMMU support on Tegra194
      
       arch/arm64/boot/dts/nvidia/tegra194.dtsi |  4 ++++
       sound/soc/tegra/tegra_pcm.c              | 30 ++++++++++++++----------
       2 files changed, 22 insertions(+), 12 deletions(-)
      
      --
      2.32.0
      11169c6e
    • Mark Brown's avatar
      ASoC: tlv320aic31xx: Make regmap cache only on probe() · 6c621b81
      Mark Brown authored
      
      
      Currently the tlv320aic31xx driver has regulator support but does not
      enable the regulators during probe, deferring this until something causes
      ASoC to make the card active. It does put the device into cache only mode
      but only when the component level probe is called, however if interrupts
      are in use the driver will access the regmap before then which if the
      regulators are not powered on would cause I/O problems.
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Link: https://lore.kernel.org/r/20210707160234.16253-1-broonie@kernel.org
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      6c621b81
    • Marek Vasut's avatar
      ASoC: tlv320aic32x4: Fix TAS2505 volume controls · 2169d6a0
      Marek Vasut authored
      None of the TAS2505 outputs are stereo, do not pretend they are by
      implementing them using SOC*DOUBLE* macros referencing the same
      register twice, use SOC*SINGLE* instead. Fix volume ranges and mute
      control for the codec according to datasheet.
      
      Fixes: b4525b61
      
       ("ASoC: tlv320aic32x4: add support for TAS2505")
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Claudius Heine <ch@denx.de>
      Cc: Mark Brown <broonie@kernel.org>
      Link: https://lore.kernel.org/r/20210708091255.56502-1-marex@denx.de
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      2169d6a0
    • Thierry Reding's avatar
      ASoC: tegra: Use ADMAIF component for DMA allocations · 0dfc21c1
      Thierry Reding authored
      
      
      DMA memory is currently allocated for the soundcard device, which is a
      virtual device added for the sole purpose of "stitching" together the
      audio device. It is not a real device and therefore doesn't have a DMA
      mask or a description of the path to and from memory of accesses.
      
      Memory accesses really originate from the ADMA controller that provides
      the DMA channels used by the PCM component. However, since the DMA
      memory is allocated up-front and the DMA channels aren't known at that
      point, there is no way of knowing the DMA channel provider at allocation
      time.
      
      The next best physical device in the memory path is the ADMAIF. Use it
      as the device to allocate DMA memory to. iommus and interconnects device
      tree properties can thus be added to the ADMAIF device tree node to
      describe the memory access path for audio.
      
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Link: https://lore.kernel.org/r/20210708103432.1690385-2-thierry.reding@gmail.com
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      0dfc21c1
  14. Jul 01, 2021