Skip to content
Snippets Groups Projects
Select Git revision
  • 6.6/linux default protected
  • lts-pre-prod-v5.15.161-android_u-cve-241018T060950Z
  • lts-v5.15.161-android_t-cve-241017T225452Z
  • lts-pre-prod-v5.15.161-android_u-241018T060950Z
  • lts-v5.15.161-android_t-241017T225452Z
  • lts-v6.6.53-rt44-preempt-rt-241016T031527Z
  • lts-v6.6.53-linux-241016T015643Z
  • lts-v6.6.53-linux-cve-241016T015643Z
  • lts-v6.6.52-rt43-preempt-rt-241011T142630Z
  • lts-v6.6.52-linux-241011T090312Z
  • lts-v6.6.52-linux-cve-241011T090312Z
  • lts-pre-prod-v5.15.161-android_u-cve-241009T230053Z
  • lts-v6.6.50-rt42-preempt-rt-241002T180333Z
  • lts-v5.15.161-android_t-cve-240930T120437Z
  • lts-v6.6.50-linux-240930T011355Z
  • lts-v6.6.50-linux-cve-240930T011355Z
  • lts-pre-prod-v5.15.161-android_u-241009T230053Z
  • lts-v5.15.161-android_t-240930T120437Z
  • lts-v6.6.50-rt42-preempt-rt-240925T173613Z
  • lts-v6.6.50-linux-240925T091328Z
  • lts-v6.6.50-linux-cve-240925T091328Z
21 results
Search by author
  • Any Author
  • Nicola Sparnacci Nicola Sparnacci nicola.sparnacci
1 author
  1. Feb 09, 2023
  3. Jan 31, 2023
    • Richard Fitzgerald's avatar
      ASoC: cs42l42: Add SoundWire support · 90f6a2a2
      Richard Fitzgerald authored 
      
This adds support for using CS42L42 as a SoundWire device.

SoundWire-specifics are kept separate from the I2S implementation as
much as possible, aiming to limit the risk of breaking the I2C+I2S
support.

There are some important differences in the silicon behaviour between
I2S and SoundWire mode that are reflected in the implementation:

- ASP (I2S) most not be used in SoundWire mode because the two interfaces
  share pins.

- The SoundWire capture (record) port only supports 1 channel. It does
  not have left-to-right duplication like the ASP.

- DP2 can only be prepared if the HP has powered-up. DP1 can only be
  prepared if the ADC has powered-up. (This ordering restriction does
  not exist for ASPs.) The SoundWire core port-prepare step is
  triggered by the DAI-link prepare(). This happens before the
  codec DAI prepare() or the DAPM sequence so these cannot be used
  to enable HP/ADC. Instead the HP/ADC enable/disable are done during
  the port_prep callback.

- The SRCs are an integral part of the audio chain but in silicon their
  power control is linked to the ASP. There is no equivalent power link
  to SoundWire DPs so the driver must take "manual" control of SRC power.

- The SoundWire control registers occupy the lower part of the SoundWire
  address space so cs42l42 registers are offset by 0x8000 (non-paged) in
  SoundWire mode.

- Register addresses are 8-bit paged in I2C mode but 16-bit unpaged in
  SoundWire.

- Special procedures are needed on register read/writes to (a) ensure
  that the previous internal bus transaction has completed, and
  (b) handle delayed read results, when the read value could not be
  returned within the SoundWire read command.

There are also some differences in driver implementation between I2S
and SoundWire operation:

- CS42L42 I2S does not runtime_suspend, but runtime_suspend/resume support
  has been added into the driver in SoundWire mode as the most convenient
  way to power-up the bus manager and to handle the unattach_request
  condition, though the CS42L42 chip does not itself suspend or resume.

- Intel SoundWire host controllers have a low-power clock-stop mode that
  requires resetting all peripherals when resuming. This means that the
  interrupt registers will be reset in between the interrupt being
  generated and the interrupt being handled, and since the interrupt
  status is debounced, these values may not be accurate immediately,
  and may cause spurious unplug events before settling.

- As in I2S mode, the PLL is only used while audio is active because
  of clocking quirks in the silicon. For SoundWire the cs42l42_pll_config()
  is deferred until the DAI prepare(), to allow the cs42l42_bus_config()
  callback to set the SCLK.

Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: default avatarStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230127165111.3010960-7-sbinding@opensource.cirrus.com


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      90f6a2a2
  5. Jan 30, 2023
  7. Jan 28, 2023
  9. Nov 16, 2022
  11. Sep 19, 2022
  13. Aug 16, 2022
  15. Aug 15, 2022
  17. Jul 08, 2022
  19. Jun 29, 2022
  21. Jun 06, 2022
    • Cezary Rojewski's avatar
      ASoC: codecs: Add HD-Audio codec driver · b5df2a7d
      Cezary Rojewski authored 
      
Add generic ASoC equivalent of ALSA HD-Audio codec. This codec is
designed to follow HDA_DEV_LEGACY convention. Driver wrapps existing
hda_codec.c handlers to prevent code duplication within the newly added
code. Number of DAIs created is dependent on capabilities exposed by the
codec itself. Because of this, single solution can be applied to support
every single HD-Audio codec type.

At the same time, through the ASoC topology, platform drivers may limit
the number of endpoints available to the userspace as codec driver
exposes BE DAIs only.

Both hda_codec_probe() and hda_codec_remove() declare their expectations
on device's usage_count and suspended-status. This is to catch any
unexpected behavior as PM-related code for HD-Audio has been changing
quite a bit throughout the years.

In order for codec DAI list to reflect its actual PCM capabilities, PCMs
need to be built and that can only happen once codec device is
constructed. To do that, a valid component->card->snd_card pointer is
needed. Said pointer will be provided by the framework once all card
components are accounted for and their probing can begin. Usage of
"binder" BE DAI solves the problem - codec can be listed as one of
HD-Audio card components without declaring any actual BE DAIs
statically.

Relation with hdac_hda:

Addition of parallel solution is motivated by behavioral differences
between hdac_hda.c and its legacy equivalent found in sound/pci/hda
e.g.: lack of dynamic, based on codec capabilities, resource allocation
and high cost of removing such differences on actively used targets.
Major goal of codec driver presented here is to follow HD-Audio legacy
behavior in 1:1 fashion by becoming a wrapper. Doing so increases code
coverage of the legacy code and reduces the maintenance cost for both
solutions.

Signed-off-by: default avatarCezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220511162403.3987658-3-cezary.rojewski@intel.com


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      b5df2a7d
  23. Apr 26, 2022
  25. Apr 06, 2022
  27. Apr 05, 2022
  29. Apr 04, 2022
  31. Mar 07, 2022
  33. Feb 28, 2022
  35. Jan 24, 2022
  37. Dec 31, 2021
  39. Dec 21, 2021
  41. Dec 20, 2021
  43. Nov 26, 2021
  45. Oct 27, 2021
  47. Oct 13, 2021
  49. Oct 08, 2021
  51. Oct 02, 2021
  53. Sep 13, 2021
  55. Jul 22, 2021
    • Arnd Bergmann's avatar
      ASoC: codecs: wcd938x: fix wcd module dependency · b9a4b57f
      Arnd Bergmann authored 
      
With SND_SOC_ALL_CODECS=y and SND_SOC_WCD938X_SDW=m, there is a link
error from a reverse dependency, since the built-in codec driver calls
into the modular soundwire back-end:

x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_codec_free':
wcd938x.c:(.text+0x2c0): undefined reference to `wcd938x_sdw_free'
x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_codec_hw_params':
wcd938x.c:(.text+0x2f6): undefined reference to `wcd938x_sdw_hw_params'
x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_codec_set_sdw_stream':
wcd938x.c:(.text+0x332): undefined reference to `wcd938x_sdw_set_sdw_stream'
x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_tx_swr_ctrl':
wcd938x.c:(.text+0x23de): undefined reference to `wcd938x_swr_get_current_bank'
x86_64-linux-ld: sound/soc/codecs/wcd938x.o: in function `wcd938x_bind':
wcd938x.c:(.text+0x2579): undefined reference to `wcd938x_sdw_device_get'
x86_64-linux-ld: wcd938x.c:(.text+0x25a1): undefined reference to `wcd938x_sdw_device_get'
x86_64-linux-ld: wcd938x.c:(.text+0x262a): undefined reference to `__devm_regmap_init_sdw'

Work around this using two small hacks: An added Kconfig dependency
prevents the main driver from being built-in when soundwire support
itself is a loadable module to allow calling devm_regmap_init_sdw(),
and a Makefile trick links the wcd938x-sdw backend as built-in
if needed to solve the dependency between the two modules.

Fixes: 04544222 ("ASoC: codecs: wcd938x: add audio routing and Kconfig")
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210721150510.1837221-1-arnd@kernel.org


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      b9a4b57f
  57. Jul 14, 2021
    • Pierre-Louis Bossart's avatar
      ASoC: codecs: add SoundWire mockup device support · 81d3d3d0
      Pierre-Louis Bossart authored 
      
To test the host controller and bus management code, it is currently
required to have a physical SoundWire peripheral attached to the
bus. To help with pre-silicon or early hardware enablement, it would
be very useful to have a SoundWire 'mockup' device that is exposed in
platform firmware but does not drive any signal on the bus.

This is different to the existing ASoC 'dummy' codec uses for I2S/TDM,
the SoundWire spec makes it clear that a device that is not attached
to the bus is not permitted to interact with the bus, be it for
command/control or data.

This patch exposes a 'mockup' device, with a minimalist driver, with 4
partID values reserved by Intel for such test configurations. The
mockup device exposes one full-duplex DAI based on 2 ports (DP1 for
playback and DP8 for capture). The capture data port is just virtual,
such a mockup device is prevented by the SoundWire specification from
presenting any data generated by a Source port without being Attached.

All the callbacks exposed by the SoundWire Slave interface are
populated, even if they just return immediately. This is intentional
to describe what a minimal codec driver should do and implement and
help new codec vendors provide support for their devices.

Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: default avatarRander Wang <rander.wang@intel.com>
Signed-off-by: default avatarBard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20210714032209.11284-2-yung-chuan.liao@linux.intel.com


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      81d3d3d0
  59. Jun 14, 2021
  61. Jun 04, 2021
  63. Jun 01, 2021
  65. May 24, 2021
    • Stephan Gerhold's avatar
      ASoC: codecs: Add driver for NXP/Goodix TFA989x (TFA1) amplifiers · af00978a
      Stephan Gerhold authored 
      NXP's TFA98xx (now part of Goodix) are fairly popular speaker amplifiers
used in many smartphones and tablets. Most of them are sold as "smart
amplifiers" with built-in "CoolFlux DSP" that is used for volume control,
plus a "sophisticated speaker-boost and protection algorithm".

Unfortunately, they are also almost entirely undocumented. The short
datasheets (e.g. [1] for TFA9897) describe the available features,
but do not provide any information about the registers or how to use
the "CoolFlux DSP".

The amplifiers are most often configured through proprietary userspace
libraries. There are also some (rather complex) kernel drivers (e.g. [2])
but even those rely on obscure firmware blobs for configuration (so-called
"containers"). They seem to contain different "profiles" with tuned speaker
settings, sample rates and volume steps (which would be better exposed
as separate ALSA mixers).

The format of the firmware files seems to have changed a lot over the time,
so it's not even possible to simply re-use the firmware originally provided
by the vendor.

Overall, it seems close to impossible to develop a proper mainline driver
for these amplifiers that could make proper use of the built-in DSP.

This commit implements a compromise: At least the TFA1 family of the
TFA98xx amplifiers (usually called TFA989x) provide a way to *bypass*
the DSP using a special register sequence. The register sequence can be
found in similar variations in the kernel drivers from lots of vendors
e.g. in [3] and was probably mainly used for factory testing.

With the DSP bypassed, the amplifier acts mostly like a dumb standard
speaker amplifier, without (hardware) volume control. However, the setup
is much simpler and it works without any obscure firmware.

This driver implements the DSP bypass combined with chip-specific
initialization sequences adapted from [2]. Only TFA9895 is supported in
this initial commit. Except for the lack of volume control I can not hear
any difference with or without the DSP, it works just fine.

This driver allows the speaker to work on mainline Linux running on the
Samsung Galaxy A3/A5 (2015) [TFA9895] and Alcatel Idol 3 [TFA9897].
TFA9897 support will be added in separate patch set later.

[1]: https://product.goodix.com/en/docview/TFA9897%20SDS_Rev.3.1?objectId=47&objectType=document&version=78
[2]: https://source.codeaurora.org/external/mas/tfa98xx
[3]: https://github.com/sonyxperiadev/kernel/blob/57b5050e340f40a88e1ddb8d16fd9adb44418923/sound/soc/codecs/tfa98xx.c#L1422-L1462



Signed-off-by: default avatarStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210513104129.36583-2-stephan@gerhold.net


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      af00978a
  67. Apr 07, 2021
  69. Mar 25, 2021