- 18 Jul, 2023 3 commits
-
-
Mark Brown authored
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: On below HW case, we would like to use it as "2 Cards", but unfortunately it is impossible in intuitive way, or possible but not intuitive way. In reality, it is handled as "1 big Card" today. +-- basic board --------+ |+--------+ | || CPU ch0| <--> CodecA | || ch1| <-+ | |+--------+ | | +-------------|---------+ +-- expansion board ----+ | | | | +-> CodecB| +-----------------------+ To handling it as intuitive "2 Cards", this patch-set adds multi Component support. To enable this patch-set, I included [01/15] patch into this patch-set which is posted but not yet accepted.
-
Dan Carpenter authored
The list iterator can't be NULL. Delete the check and pull the code in one tab. Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/b0c5b0ca-68da-47e6-a8b0-e0714f0de119@moroto.mountainSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from V sujith kumar Reddy <vsujithkumar.reddy@amd.corp-partner.google.com>: The Patch series consists of probe functionality support for amd platforms.
-
- 17 Jul, 2023 25 commits
-
-
Frank Li authored
The wm8960 codec is not readable, resulting in a NACK for address 0x3d (8-bit). This can partially indicate it. For example: wm8962 codec use the same address but is readable. This additional probe check will help prevent loading the wm8960 module incorrectly on wm8962 hardware. Signed-off-by:
Frank Li <Frank.Li@nxp.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230713222513.1636591-1-Frank.Li@nxp.comSigned-off-by:
-
Mark Brown authored
Merge series from Chancel Liu <chancel.liu@nxp.com>: Support rpmsg sound card on i.MX93 platform.
-
Mark Brown authored
Merge series from Mark Brown <broonie@kernel.org>: The maple tree register cache should now be a good replacement for the rbtree cache in almost all situations, update the Qualcomm CODEC drivers to use the newer cache.
-
Rob Herring authored
The example in audio-graph-card2 binding is incomplete, uses undocumented compatibles strings, and doesn't follow typical .dts formatting. Rather than try to fix with what would probably be a lengthy example, just drop the example. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230707221725.1071292-1-robh@kernel.orgSigned-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Yangtao Li <frank.li@vivo.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20230711034846.69437-5-frank.li@vivo.comSigned-off-by:
-
Yangtao Li authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
-
Yangtao Li authored
Use devm_platform_ioremap_resource_byname() to simplify code. Signed-off-by:
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
-
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:
-
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:
-
V sujith kumar Reddy authored
Add Probe register offset for renoir and rembrandt platform to get position update. Signed-off-by:
V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com> Link: https://lore.kernel.org/r/20230713125709.418851-4-vsujithkumar.reddy@amd.corp-partner.google.comSigned-off-by:
-
V sujith kumar Reddy authored
This patch adds acp-probe id as a match id to support probe functionality for amd platforms. Signed-off-by:
-
V sujith kumar Reddy authored
This patch consist of probe client device registration,stream tag and dma channel configuration for SOF firmware. Signed-off-by:
-
Chancel Liu authored
Add compatible string and specific soc data to support rpmsg sound card on i.MX93 platform. Signed-off-by:
Chancel Liu <chancel.liu@nxp.com> Link: https://lore.kernel.org/r/20230714092913.1591195-3-chancel.liu@nxp.comSigned-off-by:
-
Chancel Liu authored
Add compatible string for i.MX93 platform which supports audio function through rpmsg channel between Cortex-A and Cortex-M core. 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 wsa883x driver to use the more modern data structure. 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 wsa881x driver to use the more modern data structure. 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 wcd938x driver to use the more modern data structure. 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 wcd9335 driver to use the more modern data structure. 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 11 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:
-
