1. 10 May, 2022 3 commits
    • Zheyu Ma's avatar
      ASoC: tlv320adcx140: Register a callback to disable the regulator_disable · e1c9f68a
      Zheyu Ma authored
      The driver should register a callback that will deal with the disabling
      when it fails to probe.
      Signed-off-by: default avatarZheyu Ma <zheyuma97@gmail.com>
      Link: https://lore.kernel.org/r/20220510053031.1685337-1-zheyuma97@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      e1c9f68a
    • Pierre-Louis Bossart's avatar
      ASoC: codecs: rt715-sdca: remove useless assignment of ops · 5118da41
      Pierre-Louis Bossart authored
      The ops are already part of the 'struct sdw_driver', it's unclear why
      this was copied into the 'slave' structure - no other driver does so.
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/20220509185729.59884-1-pierre-louis.bossart@linux.intel.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      5118da41
    • Mark Brown's avatar
      Clean up usage of the endianness flag · 795dd8d3
      Mark Brown authored
      Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
      
      Before componentisation any part registered as a CODEC would have
      automatically supported both little and big endian, ie. the core
      would duplicate any supported LE or BE PCM format to support the other
      endian as well. As componentisation removed the distinction between
      CODEC drivers and platform drivers, a flag was added to specify
      if this behaviour is required for a particular component. However,
      as most systems tend to use little endian the absence of the flag
      is rarely noticed. Also the naming of the flag "endianness" is a
      little unobvious as to if it should be applied to a particular
      component.
      
      This series adds a comment to better explain the meaning of the
      flag and then tidys up the usage of the flag. A couple of uses
      of the flag are removed where is has been used inappropriately
      on the CPU side of the DAI link, this is clearly not valid in the
      cases it has been used, and I suspect never would be valid. Then
      some redundant formats are removed, since they would be covered by
      existing endianness flags. And finally a bunch of devices that are
      missing the flag have it added.
      
      It is worth noting that since componenisation there are now a couple
      of cases where it is not entire clear to me that the flag should
      be applied to all CODECs as it was before. In those cases I haven't
      updated the driver to add the flag and they are outlined here:
      
      1) Build into the AP CODECs, these are actual silicon inside the main
      processor and they typically receive audio directly from an internal
      bus. It is not obvious to me that these can happily ignore endian. On
      the CODEC side these include: jz4725b.c, jz4760.c, jz4770.c,
      rk3328_codec.c, lpass-va-macro.c, lpass-rx-macro.c, lpass-tx-macro.c,
      lpass-wsa-macro.c. There are also some examples of this scattered
      around the various platform support directories in sound/soc.
      
      2) Devices behind non-audio buses, SPI just moves bits and doesn't
      really define an endian for audio data on the bus. Thus it seems the
      CODEC probably can care about the endian. The only devices that fall
      into this group (mostly for AoV) are: rt5514-spi.c, rt5677-spi.c,
      cros_ec_codec.c (only the AoV).
      
      3) CODECs with no DAIs, these could specify the flag and plenty of
      them do; CODECs from the initial conversion to componentisation. But
      the flag makes no difference here since there is nothing for it to
      apply to. This includes purely analogue CODECs: aw8738.c, ssm2305.c,
      tpa6130a2.c, tda7419.c, max9759.c, max9768.c, max9877.c, lm4857.c,
      simple-mux.c, simple-amplifier.c. And devices that only do jack
      detection: ts3a227e.c, mt6359-accdet.c.
      
      If there are any opinions on adding the flag to any of those three
      groups they would be greatfully received. But I am leaning towards
      leaving 1,2 without endianness flags since it feels inappropriate,
      and removing the endian flag from devices in catagory 3 that already
      have it. Assuming no one objects to that I will do a follow up
      series for that.
      795dd8d3
  2. 09 May, 2022 37 commits