1. 05 Dec, 2022 13 commits
  2. 04 Dec, 2022 1 commit
    • Mark Brown's avatar
      ASoC/tda998x: Fix reporting of nonexistent capture streams · f19a2caa
      Mark Brown authored
      Merge series from Mark Brown <broonie@kernel.org>:
      
      The recently added pcm-test selftest has pointed out that systems with
      the tda998x driver end up advertising that they support capture when in
      reality as far as I can see the tda998x devices are transmit only.  The
      DAIs registered through hdmi-codec are bidirectional, meaning that for
      I2S systems when combined with a typical bidrectional CPU DAI the
      overall capability of the PCM is bidirectional.  In most cases the I2S
      links will clock OK but no useful audio will be returned which isn't so
      bad but we should still not advertise the useless capability, and some
      systems may notice problems for example due to pinmux management.
      
      This is happening due to the hdmi-codec helpers not providing any
      mechanism for indicating unidirectional audio so add one and use it in
      the tda998x driver.  It is likely other hdmi-codec users are also
      affected but I don't have those systems to hand.
      
      Mark Brown (2):
        ASoC: hdmi-codec: Allow playback and capture to be disabled
        drm: tda99x: Don't advertise non-existent capture support
      
       drivers/gpu/drm/i2c/tda998x_drv.c |  2 ++
       include/sound/hdmi-codec.h        |  4 ++++
       sound/soc/codecs/hdmi-codec.c     | 30 +++++++++++++++++++++++++-----
       3 files changed, 31 insertions(+), 5 deletions(-)
      
      base-commit: f0c4d9fc
      --
      2.30.2
      f19a2caa
  3. 02 Dec, 2022 2 commits
  4. 01 Dec, 2022 1 commit
  5. 30 Nov, 2022 2 commits
  6. 29 Nov, 2022 19 commits
  7. 28 Nov, 2022 2 commits
    • Ricardo Ribalda's avatar
      ASoC: mediatek: mt8173: Enable IRQ when pdata is ready · 4cbb264d
      Ricardo Ribalda authored
      If the device does not come straight from reset, we might receive an IRQ
      before we are ready to handle it.
      
      Fixes:
      
      [    2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4
      [    2.522601] Call trace:
      [    2.525040]  regmap_read+0x1c/0x80
      [    2.528434]  mt8173_afe_irq_handler+0x40/0xf0
      ...
      [    2.598921]  start_kernel+0x338/0x42c
      Signed-off-by: default avatarRicardo Ribalda <ribalda@chromium.org>
      Fixes: ee0bcaff ("ASoC: mediatek: Add AFE platform driver")
      Link: https://lore.kernel.org/r/20221128-mt8173-afe-v1-0-70728221628f@chromium.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      4cbb264d
    • Mark Brown's avatar
      ASoC: dt-bindings: Rework Qualcomm APR/GPR Sound nodes for SM8450 · cecf8179
      Mark Brown authored
      Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>:
      
      Adding sound support for Qualcomm SM8450 SoC (and later for SC8280XP) brought
      some changes to APR/GPR services bindings.  These bindings are part of
      qcom,apr.yaml:
      
        apr-or-gpr-device-node <- qcom,apr.yaml
          apr-gpr-service@[0-9] <- qcom,apr.yaml
            service-specific-components <- /schemas/sound/qcom,q6*.yaml
      
      The schema for services (apr-gpr-service@[0-9]) was not complete and is still
      quite not specific.  It allows several incorrect combinations, like adding a
      clock-controller to a APM device.  Restricting it would complicate the schema
      even more.  Bringing new support for sound on Qualcomm SM8450 and SC8280XP SoC
      would grow it as well.
      
      Refactor the bindings before extending them for Qualcomm SM8450 SoC.
      cecf8179