- 17 Jul, 2023 7 commits
-
-
Kuninori Morimoto authored
If CPU/Codec driver keeps its DAI node, we can directly identify actual DAI by using snd_soc_get_dai_via_args(). This means we can use multi Component. This patch enables multi Component support for Simple Card Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/878rboo943.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
If CPU/Codec driver keeps its DAI node, we can directly identify actual DAI by using snd_soc_get_dai_via_args(). This means we can use multi Component. This patch enables multi Component support on Audio Graph Card/Card2. Signed-off-by:
-
Kuninori Morimoto authored
To use multi Component support, we need to check dai_args whether Card could get DAI from args (CPU/Codec needs set dai_args on DAI driver). If it could, we need to allocate dai_args for dlc. This patch adds snd_soc_copy_dai_args() for it. This is helper function for multi Component support. Signed-off-by:
-
Kuninori Morimoto authored
Current snd_soc_is_matching_component() checks "of_node" or "dai_args". Thus coping "of_node" only is not enough to use CPU as Platform. This patch adds snd_soc_dlc_use_cpu_as_platform() and help it. This is helper function for multi Component support. Signed-off-by:
-
Kuninori Morimoto authored
To enable multi Component, Card driver need to get DAI via dai_args to identify it. This patch adds snd_soc_get_dai_via_args() for it. This is helper function for multi Component support. Signed-off-by:
-
Kuninori Morimoto authored
Current ASoC Card is using dlc (snd_soc_dai_link_component) to find target DAI / Component to be used. Current dlc has below 3 items to identify DAI / Component (a) name for Component (b) of_node for Component (c) dai_name for DAI (a) or (b) is used to identify target Component, and (c) is used to identify DAI. One of the biggest issue on it today is dlc needs "name matching" for "dai_name" (c). It was not a big deal when we were using platform_device, because we could specify nessesary "dai_name" via its platform_data. But we need to find DAI name pointer from whole registered datas and/or each related driver somehow in case of DT, because we can't specify it. Therefore, Card driver parses DT and assumes the DAI, and find its name pointer. How to assume is based on each Component and/or Card. Next biggest issue is Component node (a)/(b). Basically, Component is registered when CPU/Codec driver was probed() (X). Here, 1 Component is possible to have some DAIs. int xxx_probe(struct platform_device *pdev) { ... (X) ret = devm_snd_soc_register_component(pdev->dev, &component_driver, &dai_driver, dai_driver_num); ... } The image of each data will be like below. One note here is "driver" is included for later explanation. +-driver------+ |+-component-+| || dai0|| || dai1|| || ...|| |+-----------+| +-------------+ The point here is 1 driver has 1 Component, because basically driver calles snd_soc_register_component() (= X) once. Here is the very basic CPU/Codec connection image. HW image SW image +-- Board ------------+ +-card--------------------------+ |+-----+ +------+| |+-driver------+ +-driver------+| || CPU | <--> |CodecA|| ||+-component-+| |+-component-+|| |+-----+ +------+| ||| dai|<=>|dai ||| +---------------------+ ||+-----------+| |+-----------+|| |+-------------+ +-------------+| +-------------------------------+ It will be very complex if it has multi DAIs. Here is intuitive easy to understandable HW / SW example. HW image SW image +-- Board ---------------+ +-card--------------------------+ |+--------+ +------+| |+-driver------+ +-driver------+| || CPU ch0| <--> |CodecA|| ||+-component-+| |+-component-+|| || | +------+| ||| ch0 dai|<=>|dai ||| || | +------+| ||| || |+-----------+|| || ch1| <--> |CodecB|| ||| || +-------------+| |+--------+ +------+| ||| || +-driver------+| +------------------------+ ||| || |+-component-+|| ||| ch1 dai|<=>|dai ||| ||+-----------+| |+-----------+|| |+-------------+ +-------------+| +-------------------------------+ It will be handled as multi interface as "one Card". card0,0: CPU-ch0 - CodecA card0,1: CPU-ch1 - CodecB ^ But, here is the HW image example which will be more complex +-- Basic Board ---------+ |+--------+ +------+| || CPU ch0| <--> |CodecA|| || ch1| <-+ +------+| |+--------+ | | +-------------|----------+ +-- expansion board -----+ | | +------+| | +->|CodecB|| | +------+| +------------------------+ We intuitively think we want to handle these as "2 Sound Cards". card0,0: CPU-ch0 - CodecA card1,0: CPU-ch1 - CodecB ^ But below image which we can register today doesn't allow it, because the same Component will be connected to both Card0/1, but it will be rejected by (Z). +-driver------+ |+-component-+| +-card0-------------------------+ ||| || +-driver------+| ||| || |+-component-+|| ||| ch0 dai|<=>|dai ||| ||| || |+-----------+|| ||| || +-------------+| +-------------------------------+ || || +-card1-------------------------+ ||| || +-driver------+| ||| || |+-component-+|| ||| ch1 dai|<=>|dai ||| ||| || |+-----------+|| ||| || +-------------+| +-------------------------------+ |+-----------+| +-------------+ static int soc_probe_component() { ... if (component->card) { (Z) if (component->card != card) { dev_err(component->dev, ...); return -ENODEV; } return 0; } ... } So, how about to call snd_soc_register_component() (= X) multiple times on probe() to avoid buplicated component->card limitation, to be like below ? +-driver------+ +-card0-------------------------+ || | +-driver------+| ||+-component-+| |+-component-+|| ||| ch0 dai|<=>|dai ||| ||+-----------+| |+-----------+|| || | +-------------+| +-------------------------------+ | | +-card1-------------------------+ || | +-driver------+| ||+-component-+| |+-component-+|| ||| ch1 dai|<=>|dai ||| ||+-----------+| |+-----------+|| || | +-------------+| +-------------------------------+ +-------------+ Yes, looks good. But unfortunately it doesn't help us for now. Let's see soc_component_to_node() and snd_soc_is_matching_component() static struct device_node *soc_component_to_node(struct snd_soc_component *component) { ... (A) of_node = component->dev->of_node; ... } static int snd_soc_is_matching_component(...) { ... (B) if (dlc->of_node && component_of_node != dlc->of_node) ... } dlc checkes "of_node" to identify target component (B), but this "of_node" came from component->dev (A) which is added by snd_soc_register_component() (X) on probe(). This means we can have different "component->card", but have same "component->dev" in this case. Even though we calls snd_soc_register_component() (= X) multiple times, all Components have same driver's dev, thus it is impossible to identified the Component. And if it was impossible to identify Component, it is impossible to identify DAI on current implementation. So, how to handle above complex HW image today is 2 patterns. One is handles it as "1 big sound card". The SW image is like below. SW image +-card--------------------------+ |+-driver------+ +-driver------+| ||+-component-+| |+-component-+|| ||| ch0 dai|<=>|dai ||| ||| || |+-----------+|| ||| || +-------------+| ||| || +-driver------+| ||| || |+-component-+|| ||| ch1 dai|<->|dai ||| ||+-----------+| |+-----------+|| |+-------------+ +-------------+| +-------------------------------+ But the problem is not intuitive. We want to handle it as "2 Cards". 2nd pattern is like below. SW image +-card0-------------------------+ |+-driver------+ +-driver------+| ||+-component-+| |+-component-+|| ||| ch0 dai|<=>|dai ||| ||+-----------+| |+-----------+|| |+-------------+ +-------------+| +-------------------------------+ +-card1-------------------------+ |+-driver------+ +-driver------+| ||+-component-+| |+-component-+|| ||| ch1 dai|<=>|dai ||| ||+-----------+| |+-----------+|| |+-------------+ +-------------+| +-------------------------------+ It handles as "2 Cards", but CPU part needs to be probed as 2 drivers. It is also not intuitive. To solve this issue, we need to have multi Component support. In current implementation, we need to identify Component first to identify DAI, and it is using name matching to identify DAI. But how about to be enable to directly identify DAI by unique way instead of name matching ? In such case, we can directly identify DAI, then it can identify Component from DAI. For example Simple-Card / Audio-Graph-Card case, it is specifying DAI via its node. Simple-Card sound-dai = <&cpu-sound>; Audio-Graph-Card dais = <&cpu-sound>; If each CPU/Codec driver keeps this property when probing, we can identify DAI directly from Card. Being able to identify DAI directly means being able to identify its Component as well even though Component has same dev (= B). This patch adds new "dai_node" for it. To keeping compatibility, it checks "dai_node" first if it has, otherwise, use existing method (name matching). Link: https://lore.kernel.org/r/87fskz5yrr.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: -
Kuninori Morimoto authored
Current ASoC is specifying and checking DAI name. But where it came from and how to check was ambiguous. This patch adds snd_soc_dai_name_get() / snd_soc_dlc_dai_is_match() and makes it clear. Signed-off-by:
-
- 14 Jul, 2023 1 commit
-
-
Zhu Ning authored
The internal analog power and hp Vref of es8326 should always be on to reduce pop noise. The HP_VOL and HP_CAL are moved to es8326_mute function so they are turned on at last and turned off at first. Also, the calibration should be done manually once during start-up to reduce DC offset on headphone. Signed-off-by:
Zhu Ning <zhuning0077@gmail.com> Link: https://lore.kernel.org/r/20230714032453.3334-1-zhuning0077@gmail.comSigned-off-by:
-
- 13 Jul, 2023 13 commits
-
-
Mark Brown authored
Merge series from Mark Brown <broonie@kernel.org>: The maple tree register cache has now got to feature parity with the rbtree cache, there are some different tradeoffs made and it should be a better choice for most modern systems. Convert the Analog Devices drivers to use the more modern data structure. Signed-off-by:
-
Min-Hua Chen authored
This patch fixes the following sprse warning: sound/soc/qcom/qdsp6/q6apm.c:30:14: sparse: warning: symbol 'g_apm' was not declared. Should it be static? No functional change intended Signed-off-by:
Min-Hua Chen <minhuadotchen@gmail.com> Link: https://lore.kernel.org/r/20230713151744.86072-1-minhuadotchen@gmail.comSigned-off-by:
-
Yang Li authored
sound/soc/amd/acp/acp-rembrandt.c:283 rmb_pcm_resume() warn: inconsistent indenting Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5863Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20230713065106.21564-1-yang.lee@linux.alibaba.comSigned-off-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adav80x driver to use the more modern data structure. Reviewed-by:
Nuno Sa <nuno.sa@analog.com> Signed-off-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adau7118 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adau1977 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adau1781 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adau1761 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adau1701 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adau1373 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the adau1382 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the ad1980 driver to use the more modern data structure. Reviewed-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. In v6.5 it has also acquired the ability to generate multi-register writes in sync operations, bringing performance up to parity with the rbtree cache there. Update the ad1836 driver to use the more modern data structure. Reviewed-by:
-
- 12 Jul, 2023 10 commits
-
-
Brent Lu authored
This configuration supports JSL boards which implement ALC5650 dual I2S interface codec. Two DAI links are added: AIF1 (on codec side) for headphone and AIF2 for speakers. Signed-off-by:
Brent Lu <brent.lu@intel.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230712191423.443765-1-brent.lu@intel.comSigned-off-by:
-
Mark Brown authored
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: Two more drivers were added during the current merge window that are users of the original .remove callback that I plan to get rid of. Convert them to .remove_new.
-
Mark Brown authored
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>: The code can be simplified with refactored GPIO parts and with use of device_get_match_data(). Besides that couple of additional changes, one for maintenance and one for making IRQ domain agnostic (not being pinned to OF).
-
Mark Brown authored
Merge series from Syed Saba Kareem <Syed.SabaKareem@amd.com>: This patch series to refactor acp leagacy driver and add pm ops support for rembrandt platforms.
-
Mark Brown authored
Merge series from Venkata Prasad Potturu <venkataprasad.potturu@amd.com>: This patch series is to add acpi machine id's for vangogh platform and add new dmi entries and machine driver support for nau8821 and max98388 codecs.
-
Mark Brown authored
Merge series from Trevor Wu <trevor.wu@mediatek.com>: This series introduces support for memory-region, allowing afe memif to utilize the region specified in dts.
-
Mark Brown authored
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>: This patch series extends the Vangogh machine driver to support a variant based on the Nuvoton NAU88L21 Codec and the Analog Devices MAX98388 Speaker Amplifier.
-
Mark Brown authored
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>: Series adds support for two boards: es8336 and rt5663. The former is utilized by some KBL-based tablets whereas the latter unlocks Chromebooks with rt5663 i2c codecs. As existing implementation of es8336 (es8316.c) codec driver is not prepared to cope with KBL-based platforms, couple of small, clock-related changes precede anything avs-driver related. The tail of patchset cleans up existing implementation of rt5682.
-
Mark Brown authored
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>: The first three patches moves intlog10() to be available in entire kernel. The last one removes copy of it in one driver. Besides already good Lines of Code (LoC) statistics the upcoming users, if any, can utilize the exported functions. The series can be routed via ASoC tree (as Mauro suggested). Note, int_log.h is separated from math.h due to licensing. I dunno if we can mix two in a single header file. In any case we may do it later on.
-
Mark Brown authored
Merge series from Herve Codina <herve.codina@bootlin.com>: Several weeks ago, I sent a series [1] for adding a potentiometer as an auxiliary device in ASoC. The feedback was that the potentiometer should be directly handled in IIO (as other potentiometers) and something more generic should be present in ASoC in order to have a binding to import some IIO devices into sound cards. The series related to the IIO potentiometer device is already applied. This series introduces audio-iio-aux. Its goal is to offer the binding between IIO and ASoC. It exposes attached IIO devices as ASoC auxiliary devices and allows to control them through mixer controls. On my system, the IIO device is a potentiometer and it is present in an amplifier design present in the audio path.
-
- 09 Jul, 2023 9 commits
-
-
Shuming Fan authored
This patch handles the regmap settings and re-detects the jack when the system level suspend/resume. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20230705042931.24950-1-shumingf@realtek.comSigned-off-by:
-
Randy Dunlap authored
Select REGMAP_AC97 to fix these build errors: ERROR: modpost: "regmap_ac97_default_volatile" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! ERROR: modpost: "__regmap_init_ac97" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! Fixes: 6bbf787b ("ASoC: stac9766: Convert to regmap") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20230701044836.18789-1-rdunlap@infradead.orgSigned-off-by:
-
Konrad Dybcio authored
Convert the PM8916 analog WCD codec bindings to YAML. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230627-topic-more_bindings-v1-5-6b4b6cd081e5@linaro.orgSigned-off-by:
-
Maxim Kochetkov authored
Depending on hardware implementaion of DWC I2S controller may support TDM mode if enabled in SoC at design time. Unfortunately there is no way to detect TDM capability for DWC by reading registers. Anyway, if such capability enabled, TDM mode can be enabled and configured by dai-tdm-slot-* DT options. Signed-off-by:
Maxim Kochetkov <fido_max@inbox.ru> Link: https://lore.kernel.org/r/20230622200031.120168-1-fido_max@inbox.ruSigned-off-by:
-
Yang Li authored
Remove .owner field if calls are used which set it automatically. to silence the warning: ./sound/soc/codecs/tas2781-i2c.c:746:3-8: No need to set .owner here. The core will do it. Reported-by:
-
Seven Lee authored
Convert the NAU8821 audio CODEC bindings to DT schema. Signed-off-by:
Seven Lee <wtli@nuvoton.com> Reviewed-by:
-
Jack Yu authored
Remove redundant sdca mask for clear code. Signed-off-by:
Jack Yu <jack.yu@realtek.com> Link: https://lore.kernel.org/r/20230621080750.13511-1-jack.yu@realtek.comSigned-off-by:
-
Kuninori Morimoto authored
dlc->of_node will be set on snd_soc_get_dlc(), but we want 1) protect it by mutex, 2) set only when successed. This patch do it. Signed-off-by:
-
Chancel Liu authored
Different PCM devices may have different PCM hardware parameters. It requires PCM hardware parameters set separately if there is more than one rpmsg sound card. Signed-off-by:
Chancel Liu <chancel.liu@nxp.com> Acked-by:
Shengjiu Wang <shengjiu.wang@gmail.com> Link: https://lore.kernel.org/r/20230625065412.651870-1-chancel.liu@nxp.comSigned-off-by:
-
