summaryrefslogtreecommitdiff
path: root/include/sound
AgeCommit message (Collapse)Author
2023-10-09ASoC: soc-dapm: Add helper for comparing widget nameKrzysztof Kozlowski
Some drivers use one event callback for multiple widgets but still need to perform a bit different actions based on actual widget. This is done by comparing widget name, however drivers tend to miss possible name prefix. Add a helper to solve common mistakes. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231003155710.821315-2-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-06ALSA: hda: Add code_loading parameter to stream setupCezary Rojewski
AudioDSP firmware is the one who kicks SDxFIFOS calculation when a stream is decoupled mode. During firmware bring up procedure, there is no firmware running and the code-loading stream is always a decoupled one. So, there is none to trigger the calculation and we end up with false-positive timeout (-110) messages. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20231006102857.749143-4-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-10-06ASoC: cs35l56: Wake transactions need to be issued twiceSimon Trimmer
As the dummy wake is a toggling signal (either I2C or SPI activity) it is not guaranteed to meet the minimum asserted hold time for a wake signal. In this case the wake must guarantee rising edges separated by at least the minimum hold time. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20231006111039.101914-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-06ALSA: hda: Introduce HOST stream setup mechanismCezary Rojewski
HDAudio stream setup procedure differs between revisions of the controller device. Currently the differences are handled directly within AudioDSP platform drivers with if-statements. Implement a more generic approach and expose a function that a platform driver may use to ensure the correct procedure is followed each time. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20230926080623.43927-3-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-10-06ALSA: hda: Poll SDxFIFOS after programming SDxFMTCezary Rojewski
Software shall read SDxFIFOS calculated by the hardware and notify if invalid value is programmed before continuing the stream preparation. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20230926080623.43927-2-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-10-04ASoC: soc-dapm: Annotate struct snd_soc_dapm_widget_list with __counted_byKees Cook
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct snd_soc_dapm_widget_list. Additionally, since the element count member must be set before accessing the annotated flexible array member, move its initialization earlier. Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: alsa-devel@alsa-project.org Cc: linux-hardening@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20231003232852.work.257-kees@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-03ASoC: cs35l56: Remove unused hibernate wake constantsSimon Trimmer
The two CS35L56_HIBERNATE_WAKE_* constants in cs35l56.h aren't used by any of the driver code. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20231003093418.21600-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-02ASoC: tas2781: fixed compiling issue in m68kShenghao Ding
fixed m68k compiling issue: mapping table can save code field; storing the dev_idx as a member of block can reduce unnecessary time and system resource comsumption of dev_idx mapping every time the block data writing to the dsp. Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://lore.kernel.org/r/20231002090434.1896-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-29ASoC: core: Do not call link_exit() on uninitialized rtd objectsAmadeusz Sławiński
On init we have sequence: for_each_card_prelinks(card, i, dai_link) { ret = snd_soc_add_pcm_runtime(card, dai_link); ret = init_some_other_things(...); if (ret) goto probe_end: for_each_card_rtds(card, rtd) { ret = soc_init_pcm_runtime(card, rtd); probe_end: while on exit: for_each_card_rtds(card, rtd) snd_soc_link_exit(rtd); If init_some_other_things() step fails due to error we end up with not fully setup rtds and try to call snd_soc_link_exit on them, which depending on contents on .link_exit handler, can end up dereferencing NULL pointer. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20230929103243.705433-2-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-26ASoC: remove asoc_xxx() compatible macroKuninori Morimoto
No driver is using asoc_xxx() any more. This patch removes compatible macro for asoc_xxx(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/878r8tfo06.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-25ASoC: simple_card_utils.h: convert not to use asoc_xxx()Kuninori Morimoto
ASoC is using 2 type of prefix (asoc_xxx() vs snd_soc_xxx()), but these are unified into snd_soc_xxx(). simple_card / audio_graph drivers are historically using asoc_xxx() prefix too. simple_card / audio_graph are not ASoC framework, so let's use simple_card_xxx_() / audio_graph_xxx() for global function prefix. This patch has asoc_xxx() as define to keep compatible. It will be removed if all drivers were switched to new style. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87edj4s26a.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-25ASoC: soc.h: convert asoc_xxx() to snd_soc_xxx()Kuninori Morimoto
ASoC is using 2 type of prefix (asoc_xxx() vs snd_soc_xxx()), but there is no particular reason about that [1]. To reduce confusing, standarding these to snd_soc_xxx() is sensible. This patch adds asoc_xxx() macro to keep compatible for a while. It will be removed if all drivers were switched to new style. Link: https://lore.kernel.org/r/87h6td3hus.wl-kuninori.morimoto.gx@renesas.com [1] Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87fs3ks26i.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-19ASoC: SOF: ipc4/Intel: Support for firmware exceptionMark Brown
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: When a firmware crashes it creats a panic information into a telemetry slot. The panic format is defined by Zephyr, includes stack and additional information to help to identify the reason for the crash. Part of the firmware exception handling the firmware also sends an EXCEPTION_CAUGHT notification. This series implements the kernel side handling of the exception: print information into the kernel log export the whole telemetry slot to user space for tools extract additional information from the panic dump.
2023-09-19ASoC: SOF: Drop unused IPC type definesPeter Ujfalusi
The SOF stack now uses the generic names for the IPC type, the defines can be dropped. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230919104226.32239-10-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-19ASoC: SOF: Introduce generic names for IPC typesPeter Ujfalusi
Change the enum names for the IPC types to be more descriptive and drop tying the IPC4 to Intel SoCs. Add defines to avoid build breakage while the related code is modified to use the new enum names. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230919104226.32239-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-19ASoC: SOF: ipc4-mtrace: move debug slot related definitions to header.hRander Wang
The macro definitions of debug slot can be used by gdb, telemetry and mtrace log, so move these definitions to header.h from mtrace. Then these macro definitions can be shared Signed-off-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230919092416.4137-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-16ASoC: Intel: common: add ACPI matching tables for Arrow LakeArun T
Initial support for ARL w/ RT711 Signed-off-by: Arun T <arun.t@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230915080635.1619942-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-15ASoC: SOF: ipc4: Add new message type: SOF_IPC4_GLB_LOAD_LIBRARY_PREPAREPeter Ujfalusi
On Intel platforms there is a strict order requirement for the DMA programming: DSP side configures the buffer and sets the GEN bit Host side sets the RUN bit. In order to follow this flow, a new global message type has been added to prepare the DSP side of the DMA: host sends LOAD_LIBRARY_PREPARE with the dma_id DSP side sets its buffer and sets the GEN bit Host sets the RUN bit Host sends LOAD_LIBRARY with dma_id and lib_id DSP receives the library data. It is up to the platform code to use the new prepare stage message and how to handle the reply to it from the firmware, which can indicate that the message type is not supported/handled. In this case the kernel should proceed to the LOAD_LIBRARY stage assuming a single stage library loading: host sends LOAD_LIBRARY_PREPARE with the dma_id DSP replies that the message type is not supported/handled Host acknowledges the return code and sets the RUN bit Host sends LOAD_LIBRARY with dma_id and lib_id DSP receives the library data. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Link: https://lore.kernel.org/r/20230915114018.1701-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-12ASoC: SOF: Pass PCI SSID to machine driverRichard Fitzgerald
Pass the PCI SSID of the audio interface through to the machine driver. This allows the machine driver to use the SSID to uniquely identify the specific hardware configuration and apply any platform-specific configuration. struct snd_sof_pdata is passed around inside the SOF code, but it then passes configuration information to the machine driver through struct snd_soc_acpi_mach and struct snd_soc_acpi_mach_params. So SSID information has been added to both snd_sof_pdata and snd_soc_acpi_mach_params. PCI does not define 0x0000 as an invalid value so we can't use zero to indicate that the struct member was not written. Instead a flag is included to indicate that a value has been written to the subsystem_vendor and subsystem_device members. sof_pci_probe() creates the struct snd_sof_pdata. It is passed a struct pci_dev so it can fill in the SSID value. sof_machine_check() finds the appropriate struct snd_soc_acpi_mach. It copies the SSID information across to the struct snd_soc_acpi_mach_params. This done before calling any custom set_mach_params() so that it could be used by the set_mach_params() callback to apply variant params. The machine driver receives the struct snd_soc_acpi_mach as its platform_data. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230912163207.3498161-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-12ASoC: soc-card: Add storage for PCI SSIDRichard Fitzgerald
Add members to struct snd_soc_card to store the PCI subsystem ID (SSID) of the soundcard. The PCI specification provides two registers to store a vendor-specific SSID that can be read by drivers to uniquely identify a particular "soundcard". This is defined in the PCI specification to distinguish products that use the same silicon (and therefore have the same silicon ID) so that product-specific differences can be applied. PCI only defines 0xFFFF as an invalid value. 0x0000 is not defined as invalid. So the usual pattern of zero-filling the struct and then assuming a zero value unset will not work. A flag is included to indicate when the SSID information has been filled in. Unlike DMI information, which has a free-format entirely up to the vendor, the PCI SSID has a strictly defined format and a registry of vendor IDs. It is usual in Windows drivers that the SSID is used as the sole identifier of the specific end-product and the Windows driver contains tables mapping that to information about the hardware setup, rather than using ACPI properties. This SSID is important information for ASoC components that need to apply hardware-specific configuration on PCI-based systems. As the SSID is a generic part of the PCI specification and is treated as identifying the "soundcard", it is reasonable to include this information in struct snd_soc_card, instead of components inventing their own custom ways to pass this information around. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230912163207.3498161-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-11ASoC: Convert some Maxim codecs to use GPIOMark Brown
Merge series from Linus Walleij <linus.walleij@linaro.org>: The Maxim devices are pretty straight-forward to convert over to use GPIO descriptors, so let's do it.
2023-09-11Improve CS35l41-based audio codec driversMark Brown
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>: This patch series contains several fixes and improvements to drivers based on the CS35l41 audio codec. It has been verified on Valve's Steam Deck, except the HDA related patches.
2023-09-11ASoC: cs35l41: Fix broken shared boost activationCristian Ciocaltea
Enabling the active/passive shared boosts requires setting SYNC_EN, but *not* before receiving the PLL Lock signal. Due to improper error handling, it was not obvious that waiting for the completion operation times out and, consequently, the shared boost is never activated. Further investigations revealed the signal is triggered while snd_pcm_start() is executed, right after receiving the SNDRV_PCM_TRIGGER_START command, which happens long after the SND_SOC_DAPM_PRE_PMU event handler is invoked as part of snd_pcm_prepare(). That is where cs35l41_global_enable() is called from. Increasing the wait duration doesn't help, as it only causes an unnecessary delay in the invocation of snd_pcm_start(). Moving the wait and the subsequent regmap operations to the SNDRV_PCM_TRIGGER_START callback is not a solution either, since they would be executed in an IRQ-off atomic context. Solve the issue by setting the SYNC_EN bit in PWR_CTRL3 register right after receiving the PLL Lock interrupt. Additionally, drop the unnecessary writes to PWR_CTRL1 register, part of the original mdsync_up_seq, which would have toggled GLOBAL_EN with unwanted consequences on PLL locking behavior. Fixes: f5030564938b ("ALSA: cs35l41: Add shared boost feature") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: David Rhodes <david.rhodes@cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-5-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-11ASoC: max9768: Convert to use GPIO descriptorsLinus Walleij
The MAX9768 is pretty straight forward to convert to GPIO descriptors. To name the GPIO properties, I looke at the bindings in maxim,max9759.yaml which names these GPIO "mute" and "shutdown" respectively. No board files using platform data exist in the kernel, new users can use GPIO descriptor tables if desired. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230911-descriptors-asoc-max-v2-1-b9d793fb768e@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-11ASoC: soc.h: replace custom COUNT_ARGS() & CONCATENATE() implementationsAndy Shevchenko
Replace custom implementation of the macros from args.h. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20230904111524.1740930-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-01ASoC: Name iov_iter argument as iterator instead of bufferTakashi Iwai
While transitioning ASoC code for iov_iter usages, I kept the argument name as "buf" as the original code. But, iov_iter is an iterator, and using the name "buf" may be misleading: the crucial difference is that iov_iter can be proceeded after the operation, hence it can't be passed twice, while a simple "buffer" sounds as if reusable. To make the usage clearer, rename the argument from "buf" to "iter". There is no functional changes, just names. Fixes: 66201cacc33d ("ASoC: component: Add generic PCM copy ops") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/CAHk-=wje+VkXjjfVTmK-uJdG_M5=ar14QxAwK+XDiq07k_pzBg@mail.gmail.com Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230831130457.8180-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-09-01ASoC: dmaengine: Drop unused iov_iter for process callbackTakashi Iwai
Passing the iov_iter to the process callback is rather buggy, as the iterator has been already processed for playback. Similarly, it makes the copy for capture buggy after the process callback reading the iterator out. Moreover, all existing process callbacks don't refer to the passed iterator at all. So, it's better to drop the argument from the process callback. Fixes: 9bebd65443c1 ("ASoC: dmaengine: Use iov_iter for process callback, too") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/CAHk-=wje+VkXjjfVTmK-uJdG_M5=ar14QxAwK+XDiq07k_pzBg@mail.gmail.com Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230831130457.8180-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-28Merge tag 'asoc-v6.6' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v6.6 The rest of the updates for v6.6, some of the highlights include: - A big API cleanup from Morimoto-san, rationalising the places we put functions. - Lots of work on the SOF framework, AMD and Intel drivers, including a lot of cleanup and new device support. - Standardisation of the presentation of jacks from drivers. - Provision of some generic sound card DT properties. - Conversion oof more drivers to the maple tree register cache. - New drivers for AMD Van Gogh, AWInic AW88261, Cirrus Logic cs42l43, various Intel platforms, Mediatek MT7986, RealTek RT1017 and StarFive JH7110.
2023-08-24ALSA: ump: Don't create unused substreams for static blocksTakashi Iwai
When the UMP Endpoint is declared as "static", that is, no dynamic reassignment of UMP Groups, it makes little sense to expose always all 16 groups with 16 substreams. Many of those substreams are disabled groups, hence they are useless, but applications don't know it and try to open / access all those substreams unnecessarily. This patch limits the number of UMP legacy rawmidi substreams only to the active groups. The behavior is changed only for the static endpoint (i.e. devices without UMP v1.1 feature implemented or with the static block flag is set). Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support") Link: https://lore.kernel.org/r/20230824075108.29958-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-23Add I2S support for the StarFive JH7110 SoCMark Brown
Merge series from Xingyu Wu <xingyu.wu@starfivetech.com>: This patch series adds I2S support for the StarFive JH7110 RISC-V SoC based on Designware I2S controller. There has three I2S channels (RX/TX0/TX1) on the JH7110 SoC, one of which is for record(RX) and two for playback(TX). The first patch adds support for the StarFive JH7110 SoC in the Designware I2S bindings. The second patch adds the ops to get data from platform bus in the I2S driver. The third patch adds support for the StarFive JH7110 SoC in the Designware I2S driver. The fourth patch fixes the name of I2STX1 pinmux. The last patch adds device node of I2S RX/TX0/TX1 in JH7110 dts. This patch series is based on Linux-next(20230818) which is merge clock, syscon and dma nodes for the StarFive JH7110 SoC. The series has been tested and works normally on the VisionFive 2 board by plugging an audio expansion board.
2023-08-23ASoC: dwc: i2s: Add StarFive JH7110 SoC supportXingyu Wu
Add StarFive JH7110(TX0/TX1/RX channels) SoC support in the designware I2S driver and a flag to check if it is on the JH7110 SoC. These channels need to enable clocks, resets and syscon register on the JH7110 SoC. So add init ops in platform data for the JH7110 SoC to do this. Their resets should be deassert before changing the parent of clocks so these are done in the init ops of platform data. The I2S controllers use DMA controller by platform data on the JH7110 and their settings about snd_dmaengine_dai_dma_data() should be added in the dw_configure_dai_by_pd(). And use dmaengine PCM registration if these do not have IRQ on the JH7110 SoC. Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com> Link: https://lore.kernel.org/r/20230821144151.207339-4-xingyu.wu@starfivetech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-23ASoC: Delete UDA134x/L3 audio codecLinus Walleij
This codec was used by the deleted S3C board sound/soc/samsung/s3c24xx_uda134x.c. Fixes: 503278c12701 ("ASoC: samsung: remove unused drivers") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230822-delete-l3-v2-1-b3ffc07348af@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-22Add cs42l43 PC focused SoundWire CODECMark Brown
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>: This patch chain adds support for the Cirrus Logic cs42l43 PC focused SoundWire CODEC. The chain is currently based of Lee's for-mfd-next branch. This series is mostly just a resend keeping pace with the kernel under it, except for a minor fixup in the ASoC stuff. Thanks, Charles Charles Keepax (4): dt-bindings: mfd: cirrus,cs42l43: Add initial DT binding mfd: cs42l43: Add support for cs42l43 core driver pinctrl: cs42l43: Add support for the cs42l43 ASoC: cs42l43: Add support for the cs42l43 Lucas Tanure (2): soundwire: bus: Allow SoundWire peripherals to register IRQ handlers spi: cs42l43: Add SPI controller support .../bindings/sound/cirrus,cs42l43.yaml | 313 +++ MAINTAINERS | 4 + drivers/mfd/Kconfig | 23 + drivers/mfd/Makefile | 3 + drivers/mfd/cs42l43-i2c.c | 98 + drivers/mfd/cs42l43-sdw.c | 239 ++ drivers/mfd/cs42l43.c | 1188 +++++++++ drivers/mfd/cs42l43.h | 28 + drivers/pinctrl/cirrus/Kconfig | 11 + drivers/pinctrl/cirrus/Makefile | 2 + drivers/pinctrl/cirrus/pinctrl-cs42l43.c | 609 +++++ drivers/soundwire/bus.c | 32 + drivers/soundwire/bus_type.c | 12 + drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/spi-cs42l43.c | 284 ++ include/linux/mfd/cs42l43-regs.h | 1184 +++++++++ include/linux/mfd/cs42l43.h | 102 + include/linux/soundwire/sdw.h | 9 + include/sound/cs42l43.h | 17 + sound/soc/codecs/Kconfig | 16 + sound/soc/codecs/Makefile | 4 + sound/soc/codecs/cs42l43-jack.c | 946 +++++++ sound/soc/codecs/cs42l43-sdw.c | 74 + sound/soc/codecs/cs42l43.c | 2278 +++++++++++++++++ sound/soc/codecs/cs42l43.h | 131 + 26 files changed, 7615 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml create mode 100644 drivers/mfd/cs42l43-i2c.c create mode 100644 drivers/mfd/cs42l43-sdw.c create mode 100644 drivers/mfd/cs42l43.c create mode 100644 drivers/mfd/cs42l43.h create mode 100644 drivers/pinctrl/cirrus/pinctrl-cs42l43.c create mode 100644 drivers/spi/spi-cs42l43.c create mode 100644 include/linux/mfd/cs42l43-regs.h create mode 100644 include/linux/mfd/cs42l43.h create mode 100644 include/sound/cs42l43.h create mode 100644 sound/soc/codecs/cs42l43-jack.c create mode 100644 sound/soc/codecs/cs42l43-sdw.c create mode 100644 sound/soc/codecs/cs42l43.c create mode 100644 sound/soc/codecs/cs42l43.h -- 2.30.2
2023-08-18ASoC: cs42l43: Add support for the cs42l43Charles Keepax
The CS42L43 is an audio CODEC with integrated MIPI SoundWire interface (Version 1.2.1 compliant), I2C, SPI, and I2S/TDM interfaces designed for portable applications. It provides a high dynamic range, stereo DAC for headphone output, two integrated Class D amplifiers for loudspeakers, and two ADCs for wired headset microphone input or stereo line input. PDM inputs are provided for digital microphones. The ASoC component provides the majority of the functionality of the device, all the audio functions. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230804104602.395892-7-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-18ALSA: pcm: Drop obsoleted PCM copy_user and copy_kernel opsTakashi Iwai
Finally all users have been converted to the new PCM copy ops, let's drop the obsoleted copy_kernel and copy_user ops completely. Link: https://lore.kernel.org/r/20230815190136.8987-26-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-18ASoC: pcm: Drop obsoleted PCM copy_user opsTakashi Iwai
Now all ASoC users have been replaced to use the new PCM copy ops, let's drop the obsoleted copy_user ops and its helper function. Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230815190136.8987-25-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-18ASoC: dmaengine: Use iov_iter for process callback, tooTakashi Iwai
Along with the conversion to PCM copy ops, use the iov_iter for the pointer to be passed to the dmaengine process callback, too. It avoids the direct reference of iter_iov_addr(), and it can potentially help for the drivers to access memory properly (although both atmel and stm drivers don't use the given buffer address at all for now). Reviewed-by: Mark Brown <broonie@kernel.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Olivier Moysan <olivier.moysan@foss.st.com> Cc: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230815190136.8987-23-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-18ASoC: component: Add generic PCM copy opsTakashi Iwai
For following the ALSA PCM core change, a new PCM copy ops is added toe ASoC component framework: snd_soc_component_driver receives the copy ops, and snd_soc_pcm_component_copy() helper is provided. This also fixes a long-standing potential bug where the ASoC driver covers only copy_user PCM callback and misses the copy from kernel pointers (such as OSS PCM layer), too. As of this patch, the old copy_user is still kept, but it'll be dropped later after all drivers are converted. Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230815190136.8987-19-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-18ALSA: core: Add memory copy helpers between iov_iter and iomemTakashi Iwai
Add two more helpers for copying memory between iov_iter and iomem, which will be used by the new PCM copy ops in a few drivers. The existing helpers became wrappers of those now. Note that copy_from/to_iter() returns the copied bytes, hence the error condition is adjusted accordingly. Link: https://lore.kernel.org/r/20230815190136.8987-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-18ALSA: pcm: Add copy ops with iov_iterTakashi Iwai
iov_iter is a universal interface to copy the data chunk from/to user-space and kernel in a unified manner. This API can fit for ALSA PCM copy ops, too; we had to split to copy_user and copy_kernel in the past, and those can be unified to a single ops with iov_iter. This patch adds a new PCM copy ops that passes iov_iter for copying both kernel and user-space in the same way. This patch touches only the ALSA PCM core part, and the actual users will be replaced in the following patches. The expansion of iov_iter is done in the PCM core right before calling each copy callback. It's a bit suboptimal, but I took this now as it's the most straightforward replacement. The more conversion to iov_iter in the caller side is a TODO for future. As of now, the old copy_user and copy_kernel ops are still kept. Once after all users are converted, we'll drop the old copy_user and copy_kernel ops, too. Link: https://lore.kernel.org/r/20230815190136.8987-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-17ASoC: rt5682s: Convert to use GPIO descriptorsLinus Walleij
Convert the RT5682S to use GPIO descriptors and drop the legacy GPIO headers. We remove the global GPIO number from the platform data, but it is still possible to create board files using GPIO descriptor tables, if desired. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-5-02fa2ca3e5b0@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-17ASoC: rt5682: Convert to use GPIO descriptorsLinus Walleij
Convert the RT5682 to use GPIO descriptors and drop the legacy GPIO headers. We remove the global GPIO number from the platform data, but it is still possible to create board files using GPIO descriptor tables, if desired. Make sure to make sure SDW devices can associate with an LDO1 EN descriptor too, if they so desire by putting the lookup into the common code. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-4-02fa2ca3e5b0@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-17ASoC: rt5668: Convert to use GPIO descriptorsLinus Walleij
Convert the RT5668 to use GPIO descriptors and drop the legacy GPIO headers. We remove the global GPIO number from the platform data, but it is still possible to create board files using GPIO descriptor tables, if desired. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-3-02fa2ca3e5b0@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-17ASoC: rt5665: Convert to use GPIO descriptorsLinus Walleij
The RT5665 driver has some stub support for GPIO descriptors going back to the initial driver commit, where there are two GPIO descriptors for the LDO and headphone detection defined in the device state. Well, let's make use of the descriptor properly. We remove the global GPIO number from the platform data, but it is still possible to create board files using GPIO descriptor tables, if desired. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-2-02fa2ca3e5b0@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-17ALSA: core: Drop snd_device_initialize()Takashi Iwai
Now all users of snd_device_intialize() are gone, let's drop it. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Tested-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20230816160252.23396-10-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-17ALSA: compress: Don't embed deviceTakashi Iwai
Embedding the struct device to snd_compr object may result in UAF when the delayed kobj release is used. Like other devices, let's detach the struct device from the snd_compr by allocating dynamically via snd_device_alloc(). Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Tested-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20230816160252.23396-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-17ALSA: rawmidi: Don't embed deviceTakashi Iwai
This patch detaches the struct device from the snd_rawmidi object by allocating via snd_device_alloc(), just like done for other devices. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Tested-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20230816160252.23396-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-17ALSA: hwdep: Don't embed deviceTakashi Iwai
Like control and PCM devices, it's better to avoid the embedded struct device for hwdep (although it's more or less well working), too. Change it to allocate via snd_device_alloc(), and free the memory at the common snd_hwdep_free(). Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Tested-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20230816160252.23396-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-17ALSA: pcm: Don't embed deviceTakashi Iwai
So far we use the embedded struct device for each PCM substreams in struct snd_pcm. This may result in UAF when the delayed kobj release is used; each corresponding struct device is still accessed at the (delayed) device release, while the snd_pcm object may be already gone. As a workaround, detach the struct device from the snd_pcm object by allocating via the new snd_device_alloc() helper. A caveat is that we store the PCM substream pointer to drvdata since the device resume and others require the access to it. This patch is based on the fix Curtis posted initially. In this patch, the changes are split and use the new helper function instead. Link: https://lore.kernel.org/r/20230801171928.1460120-1-cujomalainey@chromium.org Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Tested-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20230816160252.23396-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-08-17ALSA: control: Don't embed ctl_devTakashi Iwai
Embedding the ctl_dev in the snd_card object may result in UAF when the delayed kobj release is used; at the delayed kobj release, it still accesses the struct device itself while the card memory (that embeds the struct device) may be already gone. As a workaround, detach the struct device from the card object by allocating via the new snd_device_alloc() helper. The rest are just replacing ctl_dev access to the pointer. This is based on the fix Curtis posted initially. In this patch, the changes are split and use the new helper function instead. Link: https://lore.kernel.org/r/20230801171928.1460120-1-cujomalainey@chromium.org Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Tested-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20230816160252.23396-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit (git 2.34.1) at 2024-05-28 13:03:17 +0000