* Re: [PATCH 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
From: Marek Szyprowski @ 2023-04-21 11:25 UTC (permalink / raw)
To: Adam Ford, dri-devel
Cc: marex, aford, Rob Herring, Krzysztof Kozlowski, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Inki Dae, Jagan Teki, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, David Airlie, Daniel Vetter, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20230415104104.5537-3-aford173@gmail.com>
On 15.04.2023 12:41, Adam Ford wrote:
> Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> having an entry in the device tree for samsung,pll-clock-frequency.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
This one breaks DSI panel operation on my Exynos-based Trats, Trats2 and
TM2e boards. I've didn't check the details, but probably something is
missing in the dts to make it working properly. Surprisingly the display
is still working fine on Arndale board with DSI TC358764 bridge.
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9fec32b44e05..73f0c3fbbdf5 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1744,11 +1744,6 @@ static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
> struct device_node *node = dev->of_node;
> int ret;
>
> - ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
> - &dsi->pll_clk_rate);
> - if (ret < 0)
> - return ret;
> -
> ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
> &dsi->burst_clk_rate);
> if (ret < 0)
> @@ -1823,13 +1818,18 @@ int samsung_dsim_probe(struct platform_device *pdev)
> if (IS_ERR(dsi->clks[i])) {
> if (strcmp(clk_names[i], "sclk_mipi") == 0) {
> dsi->clks[i] = devm_clk_get(dev, OLD_SCLK_MIPI_CLK_NAME);
> - if (!IS_ERR(dsi->clks[i]))
> + if (!IS_ERR(dsi->clks[i])) {
> + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
> continue;
> + }
> }
>
> dev_info(dev, "failed to get the clock: %s\n", clk_names[i]);
> return PTR_ERR(dsi->clks[i]);
> }
> +
> + if (strcmp(clk_names[i], "sclk_mipi") == 0)
> + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
> }
>
> dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: mediatek: Enable all MT8192 clocks by default
From: Chen-Yu Tsai @ 2023-04-21 11:11 UTC (permalink / raw)
To: Stephen Boyd
Cc: Chen-Yu Tsai, Matthias Brugger, AngeloGioacchino Del Regno,
Nícolas F . R . A . Prado, linux-kernel, linux-mediatek,
linux-arm-kernel, linux-clk
Currently the base MT8192 clock drivers are enabled by default, but all
the other clock drivers need to be enabled by hand. This is extremely
confusing and inconvenient for end users. For the MT8192 platform to be
useful, most if not all the clock drivers driving the hardware blocks
need to be enabled.
Enable them by default whenever MT8192 base clock driver is enabled.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/clk/mediatek/Kconfig | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 99e67c07e638..48b42d11111c 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -781,72 +781,84 @@ config COMMON_CLK_MT8192
config COMMON_CLK_MT8192_AUDSYS
tristate "Clock driver for MediaTek MT8192 audsys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 audsys clocks.
config COMMON_CLK_MT8192_CAMSYS
tristate "Clock driver for MediaTek MT8192 camsys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 camsys and camsys_raw clocks.
config COMMON_CLK_MT8192_IMGSYS
tristate "Clock driver for MediaTek MT8192 imgsys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 imgsys and imgsys2 clocks.
config COMMON_CLK_MT8192_IMP_IIC_WRAP
tristate "Clock driver for MediaTek MT8192 imp_iic_wrap"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 imp_iic_wrap clocks.
config COMMON_CLK_MT8192_IPESYS
tristate "Clock driver for MediaTek MT8192 ipesys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 ipesys clocks.
config COMMON_CLK_MT8192_MDPSYS
tristate "Clock driver for MediaTek MT8192 mdpsys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 mdpsys clocks.
config COMMON_CLK_MT8192_MFGCFG
tristate "Clock driver for MediaTek MT8192 mfgcfg"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 mfgcfg clocks.
config COMMON_CLK_MT8192_MMSYS
tristate "Clock driver for MediaTek MT8192 mmsys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 mmsys clocks.
config COMMON_CLK_MT8192_MSDC
tristate "Clock driver for MediaTek MT8192 msdc"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 msdc and msdc_top clocks.
config COMMON_CLK_MT8192_SCP_ADSP
tristate "Clock driver for MediaTek MT8192 scp_adsp"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 scp_adsp clocks.
config COMMON_CLK_MT8192_VDECSYS
tristate "Clock driver for MediaTek MT8192 vdecsys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 vdecsys and vdecsys_soc clocks.
config COMMON_CLK_MT8192_VENCSYS
tristate "Clock driver for MediaTek MT8192 vencsys"
depends on COMMON_CLK_MT8192
+ default COMMON_CLK_MT8192
help
This driver supports MediaTek MT8192 vencsys clocks.
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] remoteproc: imx_dsp_rproc: use modern pm_ops
From: Iuliana Prodan @ 2023-04-21 10:34 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Andersson, Mathieu Poirier, Shawn Guo,
Sascha Hauer
Cc: Arnd Bergmann, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Shengjiu Wang, Daniel Baluta, Markus Elfring,
linux-remoteproc, linux-arm-kernel, linux-kernel
In-Reply-To: <20230420213610.2219080-1-arnd@kernel.org>
On 4/21/2023 12:36 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Without CONFIG_PM, the driver warns about unused functions:
>
> drivers/remoteproc/imx_dsp_rproc.c:1210:12: error: 'imx_dsp_runtime_suspend' defined but not used [-Werror=unused-function]
> 1210 | static int imx_dsp_runtime_suspend(struct device *dev)
> | ^~~~~~~~~~~~~~~~~~~~~~~
> drivers/remoteproc/imx_dsp_rproc.c:1178:12: error: 'imx_dsp_runtime_resume' defined but not used [-Werror=unused-function]
> 1178 | static int imx_dsp_runtime_resume(struct device *dev)
> | ^~~~~~~~~~~~~~~~~~~~~~
>
> Change the old SET_SYSTEM_SLEEP_PM_OPS()/SET_RUNTIME_PM_OPS()
> helpers to their modern replacements that avoid the warning,
> and remove the now unnecessary __maybe_unused annotations
> on the other PM helper functions.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Thanks,
Iulia
> ---
> drivers/remoteproc/imx_dsp_rproc.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
> index cab06dbf37fb..2d75dea43f20 100644
> --- a/drivers/remoteproc/imx_dsp_rproc.c
> +++ b/drivers/remoteproc/imx_dsp_rproc.c
> @@ -1243,7 +1243,7 @@ static void imx_dsp_load_firmware(const struct firmware *fw, void *context)
> release_firmware(fw);
> }
>
> -static __maybe_unused int imx_dsp_suspend(struct device *dev)
> +static int imx_dsp_suspend(struct device *dev)
> {
> struct rproc *rproc = dev_get_drvdata(dev);
> struct imx_dsp_rproc *priv = rproc->priv;
> @@ -1278,7 +1278,7 @@ static __maybe_unused int imx_dsp_suspend(struct device *dev)
> return pm_runtime_force_suspend(dev);
> }
>
> -static __maybe_unused int imx_dsp_resume(struct device *dev)
> +static int imx_dsp_resume(struct device *dev)
> {
> struct rproc *rproc = dev_get_drvdata(dev);
> int ret = 0;
> @@ -1312,9 +1312,8 @@ static __maybe_unused int imx_dsp_resume(struct device *dev)
> }
>
> static const struct dev_pm_ops imx_dsp_rproc_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(imx_dsp_suspend, imx_dsp_resume)
> - SET_RUNTIME_PM_OPS(imx_dsp_runtime_suspend,
> - imx_dsp_runtime_resume, NULL)
> + SYSTEM_SLEEP_PM_OPS(imx_dsp_suspend, imx_dsp_resume)
> + RUNTIME_PM_OPS(imx_dsp_runtime_suspend, imx_dsp_runtime_resume, NULL)
> };
>
> static const struct of_device_id imx_dsp_rproc_of_match[] = {
> @@ -1332,7 +1331,7 @@ static struct platform_driver imx_dsp_rproc_driver = {
> .driver = {
> .name = "imx-dsp-rproc",
> .of_match_table = imx_dsp_rproc_of_match,
> - .pm = &imx_dsp_rproc_pm_ops,
> + .pm = pm_ptr(&imx_dsp_rproc_pm_ops),
> },
> };
> module_platform_driver(imx_dsp_rproc_driver);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v3 6/6] ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards
From: Oleksii Moisieiev @ 2023-04-21 10:19 UTC (permalink / raw)
To: Gatien CHEVALLIER, Ahmad Fatoum, gregkh@linuxfoundation.org,
herbert@gondor.apana.org.au, davem@davemloft.net,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
alexandre.torgue@foss.st.com, vkoul@kernel.org, jic23@kernel.org,
olivier.moysan@foss.st.com, arnaud.pouliquen@foss.st.com,
mchehab@kernel.org, fabrice.gasnier@foss.st.com,
ulf.hansson@linaro.org, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
linux-iio@vger.kernel.org, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
linux-i2c@vger.kernel.org, dmaengine@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-serial@vger.kernel.org,
linux-phy@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org,
Pengutronix Kernel Team, Peng Fan
In-Reply-To: <f6b038d4-3524-f8eb-390f-11d90a8ac5b6@foss.st.com>
Hello,
I'm just wandering what is the status of the Patch Series?
Cc'ed Peng Fang as he also has an interest in the domain-controller
bindings.
Oleksii.
On 27.02.23 13:26, Gatien CHEVALLIER wrote:
> Hello Ahmad,
>
> Sorry for the delay :)
>
> On 2/13/23 12:27, Ahmad Fatoum wrote:
>> Hello Gatien,
>>
>> On 13.02.23 11:54, Gatien CHEVALLIER wrote:
>>> On 2/9/23 09:10, Ahmad Fatoum wrote:
>>>> On 09.02.23 08:46, Ahmad Fatoum wrote:
>>>>> Hello Gatien,
>>>>>
>>>>> On 27.01.23 17:40, Gatien Chevallier wrote:
>>>>>> The STM32 System Bus is an internal bus on which devices are
>>>>>> connected.
>>>>>> ETZPC is a peripheral overseeing the firewall bus that configures
>>>>>> and control access to the peripherals connected on it.
>>>>>>
>>>>>> For more information on which peripheral is securable, please read
>>>>>> the STM32MP13 reference manual.
>>>>>
>>>>> Diff is way too big. Please split up the alphabetic reordering
>>>>> into its
>>>>> own commit, so actual functional changes are apparent.
>>>>
>>>> Ah, I see now that you are moving securable peripherals into a new
>>>> bus.
>>>> I share Uwe's confusion of considering the ETZPC as bus.
>>>>
>>>> Does this configuration even change dynamically? Why can't you
>>>> implement
>>>> this binding in the bootloader and have Linux only see a DT where
>>>> unavailable
>>>> nodes are status = "disabled"; secure-status = "okay"?
>>>>
>>>> For inspiration, see barebox' device tree fixups when devices are
>>>> disabled
>>>> per fuse:
>>>>
>>>> https://urldefense.com/v3/__https://elixir.bootlin.com/barebox/v2023.01.0/source/drivers/base/featctrl.c*L122__;Iw!!GF_29dbcQIUBPA!2CT6VXNxfrLUg3mPkiAykgwwu8y8TVPaVa5FupuehHDyeuPvx4a2aNuMs-ayUCqP8q364P8u0GxYprlqwrvgvnXndYBmii57$
>>>> [elixir[.]bootlin[.]com]
>>>>
>>>> Cheers,
>>>> Ahmad
>>>
>>> This configuration can change dynamically. The binding will be
>>> implemented in the bootloader, where the ETZPC is already
>>> implemented as a bus in our downstream.
>>>
>>> I find the mentionned example valid.
>>>
>>> Now, why is it a bus? :D
>>>
>>> It is the result of the discussion on the previous submission by
>>> Benjamin (Sorry for the lack of link but I saw that you participated
>>> on these threads)+ we need the bus mechanism to control whether a
>>> subnode should be probed or not. You can see it as a firewall bus.
>>>
>>> The ETZPC relies on the ARM TrustZone extension to the AHB bus and
>>> propagation through bridges to the APB bus. Therefore, I find it
>>> relevant to consider it as a bus, what is your opinion?
>>>
>>> This patchset is a first step to the implementation of an API to
>>> control accesses dynamically.
>>
>> I still don't get what's dynamic about this. Either:
>>
>> - Configuration _can_ change while Linux is running: You'll need
>> to do
>> way more than what your current bus provides to somwhow
>> synchronize state
>> with the secure monitor; otherwise a newly secured device will
>> cause the driver
>> to trigger data aborts that you'll have to handle and unbind the
>> driver.
>> (like if a USB drive is yanked out).
>>
>> - Configuration _can't_ change while Linux is running: You can
>> have the bootloader
>> fixup the device tree and Linux need not care at all about
>> devices that the
>> ETZPC is securing.
>>
>> My understanding is that the latter is your use case, so I don't see
>> why we
>> even need the normal world to be aware of the partitioning.
>>
>> Cheers,
>> Ahmad
>>
> What about the case where we do not have a U-Boot/bootloader to fixup
> the device tree?
>
> On the other hand, ETZPC is a hardware firewall and is on the bus.
> Therefore, shouldn't it be represented as a bus in the file that
> describes the hardware?
>
> Best regards,
> Gatien
>
>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Ahmad
>>>>>
>>>>>>
>>>>>> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
>>>>>> ---
>>>>>>
>>>>>> No changes in V2.
>>>>>>
>>>>>> Changes in V3:
>>>>>> -Use appriopriate node name: bus
>>>>>>
>>>>>> arch/arm/boot/dts/stm32mp131.dtsi | 407
>>>>>> +++++++++++++++--------------
>>>>>> arch/arm/boot/dts/stm32mp133.dtsi | 51 ++--
>>>>>> arch/arm/boot/dts/stm32mp13xc.dtsi | 19 +-
>>>>>> arch/arm/boot/dts/stm32mp13xf.dtsi | 18 +-
>>>>>> 4 files changed, 258 insertions(+), 237 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/stm32mp131.dtsi
>>>>>> b/arch/arm/boot/dts/stm32mp131.dtsi
>>>>>> index accc3824f7e9..24462a647101 100644
>>>>>> --- a/arch/arm/boot/dts/stm32mp131.dtsi
>>>>>> +++ b/arch/arm/boot/dts/stm32mp131.dtsi
>>>>>> @@ -253,148 +253,6 @@ dmamux1: dma-router@48002000 {
>>>>>> dma-channels = <16>;
>>>>>> };
>>>>>> - adc_2: adc@48004000 {
>>>>>> - compatible = "st,stm32mp13-adc-core";
>>>>>> - reg = <0x48004000 0x400>;
>>>>>> - interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc ADC2>, <&rcc ADC2_K>;
>>>>>> - clock-names = "bus", "adc";
>>>>>> - interrupt-controller;
>>>>>> - #interrupt-cells = <1>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - status = "disabled";
>>>>>> -
>>>>>> - adc2: adc@0 {
>>>>>> - compatible = "st,stm32mp13-adc";
>>>>>> - #io-channel-cells = <1>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - reg = <0x0>;
>>>>>> - interrupt-parent = <&adc_2>;
>>>>>> - interrupts = <0>;
>>>>>> - dmas = <&dmamux1 10 0x400 0x80000001>;
>>>>>> - dma-names = "rx";
>>>>>> - status = "disabled";
>>>>>> -
>>>>>> - channel@13 {
>>>>>> - reg = <13>;
>>>>>> - label = "vrefint";
>>>>>> - };
>>>>>> - channel@14 {
>>>>>> - reg = <14>;
>>>>>> - label = "vddcore";
>>>>>> - };
>>>>>> - channel@16 {
>>>>>> - reg = <16>;
>>>>>> - label = "vddcpu";
>>>>>> - };
>>>>>> - channel@17 {
>>>>>> - reg = <17>;
>>>>>> - label = "vddq_ddr";
>>>>>> - };
>>>>>> - };
>>>>>> - };
>>>>>> -
>>>>>> - usbotg_hs: usb@49000000 {
>>>>>> - compatible = "st,stm32mp15-hsotg", "snps,dwc2";
>>>>>> - reg = <0x49000000 0x40000>;
>>>>>> - clocks = <&rcc USBO_K>;
>>>>>> - clock-names = "otg";
>>>>>> - resets = <&rcc USBO_R>;
>>>>>> - reset-names = "dwc2";
>>>>>> - interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - g-rx-fifo-size = <512>;
>>>>>> - g-np-tx-fifo-size = <32>;
>>>>>> - g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
>>>>>> - dr_mode = "otg";
>>>>>> - otg-rev = <0x200>;
>>>>>> - usb33d-supply = <&usb33>;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> - spi4: spi@4c002000 {
>>>>>> - compatible = "st,stm32h7-spi";
>>>>>> - reg = <0x4c002000 0x400>;
>>>>>> - interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc SPI4_K>;
>>>>>> - resets = <&rcc SPI4_R>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - dmas = <&dmamux1 83 0x400 0x01>,
>>>>>> - <&dmamux1 84 0x400 0x01>;
>>>>>> - dma-names = "rx", "tx";
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> - spi5: spi@4c003000 {
>>>>>> - compatible = "st,stm32h7-spi";
>>>>>> - reg = <0x4c003000 0x400>;
>>>>>> - interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc SPI5_K>;
>>>>>> - resets = <&rcc SPI5_R>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - dmas = <&dmamux1 85 0x400 0x01>,
>>>>>> - <&dmamux1 86 0x400 0x01>;
>>>>>> - dma-names = "rx", "tx";
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> - i2c3: i2c@4c004000 {
>>>>>> - compatible = "st,stm32mp13-i2c";
>>>>>> - reg = <0x4c004000 0x400>;
>>>>>> - interrupt-names = "event", "error";
>>>>>> - interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> - <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc I2C3_K>;
>>>>>> - resets = <&rcc I2C3_R>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - dmas = <&dmamux1 73 0x400 0x1>,
>>>>>> - <&dmamux1 74 0x400 0x1>;
>>>>>> - dma-names = "rx", "tx";
>>>>>> - st,syscfg-fmp = <&syscfg 0x4 0x4>;
>>>>>> - i2c-analog-filter;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> - i2c4: i2c@4c005000 {
>>>>>> - compatible = "st,stm32mp13-i2c";
>>>>>> - reg = <0x4c005000 0x400>;
>>>>>> - interrupt-names = "event", "error";
>>>>>> - interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> - <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc I2C4_K>;
>>>>>> - resets = <&rcc I2C4_R>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - dmas = <&dmamux1 75 0x400 0x1>,
>>>>>> - <&dmamux1 76 0x400 0x1>;
>>>>>> - dma-names = "rx", "tx";
>>>>>> - st,syscfg-fmp = <&syscfg 0x4 0x8>;
>>>>>> - i2c-analog-filter;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> - i2c5: i2c@4c006000 {
>>>>>> - compatible = "st,stm32mp13-i2c";
>>>>>> - reg = <0x4c006000 0x400>;
>>>>>> - interrupt-names = "event", "error";
>>>>>> - interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> - <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc I2C5_K>;
>>>>>> - resets = <&rcc I2C5_R>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - dmas = <&dmamux1 115 0x400 0x1>,
>>>>>> - <&dmamux1 116 0x400 0x1>;
>>>>>> - dma-names = "rx", "tx";
>>>>>> - st,syscfg-fmp = <&syscfg 0x4 0x10>;
>>>>>> - i2c-analog-filter;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> rcc: rcc@50000000 {
>>>>>> compatible = "st,stm32mp13-rcc", "syscon";
>>>>>> reg = <0x50000000 0x1000>;
>>>>>> @@ -431,34 +289,6 @@ mdma: dma-controller@58000000 {
>>>>>> dma-requests = <48>;
>>>>>> };
>>>>>> - sdmmc1: mmc@58005000 {
>>>>>> - compatible = "st,stm32-sdmmc2", "arm,pl18x",
>>>>>> "arm,primecell";
>>>>>> - arm,primecell-periphid = <0x20253180>;
>>>>>> - reg = <0x58005000 0x1000>, <0x58006000 0x1000>;
>>>>>> - interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc SDMMC1_K>;
>>>>>> - clock-names = "apb_pclk";
>>>>>> - resets = <&rcc SDMMC1_R>;
>>>>>> - cap-sd-highspeed;
>>>>>> - cap-mmc-highspeed;
>>>>>> - max-frequency = <130000000>;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> - sdmmc2: mmc@58007000 {
>>>>>> - compatible = "st,stm32-sdmmc2", "arm,pl18x",
>>>>>> "arm,primecell";
>>>>>> - arm,primecell-periphid = <0x20253180>;
>>>>>> - reg = <0x58007000 0x1000>, <0x58008000 0x1000>;
>>>>>> - interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc SDMMC2_K>;
>>>>>> - clock-names = "apb_pclk";
>>>>>> - resets = <&rcc SDMMC2_R>;
>>>>>> - cap-sd-highspeed;
>>>>>> - cap-mmc-highspeed;
>>>>>> - max-frequency = <130000000>;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> -
>>>>>> usbh_ohci: usb@5800c000 {
>>>>>> compatible = "generic-ohci";
>>>>>> reg = <0x5800c000 0x1000>;
>>>>>> @@ -486,29 +316,6 @@ iwdg2: watchdog@5a002000 {
>>>>>> status = "disabled";
>>>>>> };
>>>>>> - usbphyc: usbphyc@5a006000 {
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - #clock-cells = <0>;
>>>>>> - compatible = "st,stm32mp1-usbphyc";
>>>>>> - reg = <0x5a006000 0x1000>;
>>>>>> - clocks = <&rcc USBPHY_K>;
>>>>>> - resets = <&rcc USBPHY_R>;
>>>>>> - vdda1v1-supply = <®11>;
>>>>>> - vdda1v8-supply = <®18>;
>>>>>> - status = "disabled";
>>>>>> -
>>>>>> - usbphyc_port0: usb-phy@0 {
>>>>>> - #phy-cells = <0>;
>>>>>> - reg = <0>;
>>>>>> - };
>>>>>> -
>>>>>> - usbphyc_port1: usb-phy@1 {
>>>>>> - #phy-cells = <1>;
>>>>>> - reg = <1>;
>>>>>> - };
>>>>>> - };
>>>>>> -
>>>>>> rtc: rtc@5c004000 {
>>>>>> compatible = "st,stm32mp1-rtc";
>>>>>> reg = <0x5c004000 0x400>;
>>>>>> @@ -536,6 +343,220 @@ ts_cal2: calib@5e {
>>>>>> };
>>>>>> };
>>>>>> + etzpc: bus@5c007000 {
>>>>>> + compatible = "st,stm32mp13-sys-bus";
>>>>>> + reg = <0x5c007000 0x400>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <1>;
>>>>>> + feature-domain-controller;
>>>>>> + #feature-domain-cells = <1>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + adc_2: adc@48004000 {
>>>>>> + compatible = "st,stm32mp13-adc-core";
>>>>>> + reg = <0x48004000 0x400>;
>>>>>> + interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc ADC2>, <&rcc ADC2_K>;
>>>>>> + clock-names = "bus", "adc";
>>>>>> + interrupt-controller;
>>>>>> + #interrupt-cells = <1>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + feature-domains = <&etzpc 33>;
>>>>>> + status = "disabled";
>>>>>> +
>>>>>> + adc2: adc@0 {
>>>>>> + compatible = "st,stm32mp13-adc";
>>>>>> + #io-channel-cells = <1>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + reg = <0x0>;
>>>>>> + interrupt-parent = <&adc_2>;
>>>>>> + interrupts = <0>;
>>>>>> + dmas = <&dmamux1 10 0x400 0x80000001>;
>>>>>> + dma-names = "rx";
>>>>>> + status = "disabled";
>>>>>> +
>>>>>> + channel@13 {
>>>>>> + reg = <13>;
>>>>>> + label = "vrefint";
>>>>>> + };
>>>>>> + channel@14 {
>>>>>> + reg = <14>;
>>>>>> + label = "vddcore";
>>>>>> + };
>>>>>> + channel@16 {
>>>>>> + reg = <16>;
>>>>>> + label = "vddcpu";
>>>>>> + };
>>>>>> + channel@17 {
>>>>>> + reg = <17>;
>>>>>> + label = "vddq_ddr";
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + usbotg_hs: usb@49000000 {
>>>>>> + compatible = "st,stm32mp15-hsotg", "snps,dwc2";
>>>>>> + reg = <0x49000000 0x40000>;
>>>>>> + clocks = <&rcc USBO_K>;
>>>>>> + clock-names = "otg";
>>>>>> + resets = <&rcc USBO_R>;
>>>>>> + reset-names = "dwc2";
>>>>>> + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + g-rx-fifo-size = <512>;
>>>>>> + g-np-tx-fifo-size = <32>;
>>>>>> + g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
>>>>>> + dr_mode = "otg";
>>>>>> + otg-rev = <0x200>;
>>>>>> + usb33d-supply = <&usb33>;
>>>>>> + feature-domains = <&etzpc 34>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + spi4: spi@4c002000 {
>>>>>> + compatible = "st,stm32h7-spi";
>>>>>> + reg = <0x4c002000 0x400>;
>>>>>> + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc SPI4_K>;
>>>>>> + resets = <&rcc SPI4_R>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + dmas = <&dmamux1 83 0x400 0x01>,
>>>>>> + <&dmamux1 84 0x400 0x01>;
>>>>>> + dma-names = "rx", "tx";
>>>>>> + feature-domains = <&etzpc 18>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + spi5: spi@4c003000 {
>>>>>> + compatible = "st,stm32h7-spi";
>>>>>> + reg = <0x4c003000 0x400>;
>>>>>> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc SPI5_K>;
>>>>>> + resets = <&rcc SPI5_R>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + dmas = <&dmamux1 85 0x400 0x01>,
>>>>>> + <&dmamux1 86 0x400 0x01>;
>>>>>> + dma-names = "rx", "tx";
>>>>>> + feature-domains = <&etzpc 19>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + i2c3: i2c@4c004000 {
>>>>>> + compatible = "st,stm32mp13-i2c";
>>>>>> + reg = <0x4c004000 0x400>;
>>>>>> + interrupt-names = "event", "error";
>>>>>> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc I2C3_K>;
>>>>>> + resets = <&rcc I2C3_R>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + dmas = <&dmamux1 73 0x400 0x1>,
>>>>>> + <&dmamux1 74 0x400 0x1>;
>>>>>> + dma-names = "rx", "tx";
>>>>>> + st,syscfg-fmp = <&syscfg 0x4 0x4>;
>>>>>> + i2c-analog-filter;
>>>>>> + feature-domains = <&etzpc 20>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + i2c4: i2c@4c005000 {
>>>>>> + compatible = "st,stm32mp13-i2c";
>>>>>> + reg = <0x4c005000 0x400>;
>>>>>> + interrupt-names = "event", "error";
>>>>>> + interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc I2C4_K>;
>>>>>> + resets = <&rcc I2C4_R>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + dmas = <&dmamux1 75 0x400 0x1>,
>>>>>> + <&dmamux1 76 0x400 0x1>;
>>>>>> + dma-names = "rx", "tx";
>>>>>> + st,syscfg-fmp = <&syscfg 0x4 0x8>;
>>>>>> + i2c-analog-filter;
>>>>>> + feature-domains = <&etzpc 21>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + i2c5: i2c@4c006000 {
>>>>>> + compatible = "st,stm32mp13-i2c";
>>>>>> + reg = <0x4c006000 0x400>;
>>>>>> + interrupt-names = "event", "error";
>>>>>> + interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> + <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc I2C5_K>;
>>>>>> + resets = <&rcc I2C5_R>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + dmas = <&dmamux1 115 0x400 0x1>,
>>>>>> + <&dmamux1 116 0x400 0x1>;
>>>>>> + dma-names = "rx", "tx";
>>>>>> + st,syscfg-fmp = <&syscfg 0x4 0x10>;
>>>>>> + i2c-analog-filter;
>>>>>> + feature-domains = <&etzpc 22>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + sdmmc1: mmc@58005000 {
>>>>>> + compatible = "st,stm32-sdmmc2", "arm,pl18x",
>>>>>> "arm,primecell";
>>>>>> + arm,primecell-periphid = <0x20253180>;
>>>>>> + reg = <0x58005000 0x1000>, <0x58006000 0x1000>;
>>>>>> + interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc SDMMC1_K>;
>>>>>> + clock-names = "apb_pclk";
>>>>>> + resets = <&rcc SDMMC1_R>;
>>>>>> + cap-sd-highspeed;
>>>>>> + cap-mmc-highspeed;
>>>>>> + max-frequency = <130000000>;
>>>>>> + feature-domains = <&etzpc 50>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + sdmmc2: mmc@58007000 {
>>>>>> + compatible = "st,stm32-sdmmc2", "arm,pl18x",
>>>>>> "arm,primecell";
>>>>>> + arm,primecell-periphid = <0x20253180>;
>>>>>> + reg = <0x58007000 0x1000>, <0x58008000 0x1000>;
>>>>>> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc SDMMC2_K>;
>>>>>> + clock-names = "apb_pclk";
>>>>>> + resets = <&rcc SDMMC2_R>;
>>>>>> + cap-sd-highspeed;
>>>>>> + cap-mmc-highspeed;
>>>>>> + max-frequency = <130000000>;
>>>>>> + feature-domains = <&etzpc 51>;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>> +
>>>>>> + usbphyc: usbphyc@5a006000 {
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + #clock-cells = <0>;
>>>>>> + compatible = "st,stm32mp1-usbphyc";
>>>>>> + reg = <0x5a006000 0x1000>;
>>>>>> + clocks = <&rcc USBPHY_K>;
>>>>>> + resets = <&rcc USBPHY_R>;
>>>>>> + vdda1v1-supply = <®11>;
>>>>>> + vdda1v8-supply = <®18>;
>>>>>> + feature-domains = <&etzpc 5>;
>>>>>> + status = "disabled";
>>>>>> +
>>>>>> + usbphyc_port0: usb-phy@0 {
>>>>>> + #phy-cells = <0>;
>>>>>> + reg = <0>;
>>>>>> + };
>>>>>> +
>>>>>> + usbphyc_port1: usb-phy@1 {
>>>>>> + #phy-cells = <1>;
>>>>>> + reg = <1>;
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + };
>>>>>> +
>>>>>> /*
>>>>>> * Break node order to solve dependency probe issue
>>>>>> between
>>>>>> * pinctrl and exti.
>>>>>> diff --git a/arch/arm/boot/dts/stm32mp133.dtsi
>>>>>> b/arch/arm/boot/dts/stm32mp133.dtsi
>>>>>> index df451c3c2a26..be6061552683 100644
>>>>>> --- a/arch/arm/boot/dts/stm32mp133.dtsi
>>>>>> +++ b/arch/arm/boot/dts/stm32mp133.dtsi
>>>>>> @@ -33,35 +33,38 @@ m_can2: can@4400f000 {
>>>>>> bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
>>>>>> status = "disabled";
>>>>>> };
>>>>>> + };
>>>>>> +};
>>>>>> - adc_1: adc@48003000 {
>>>>>> - compatible = "st,stm32mp13-adc-core";
>>>>>> - reg = <0x48003000 0x400>;
>>>>>> - interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc ADC1>, <&rcc ADC1_K>;
>>>>>> - clock-names = "bus", "adc";
>>>>>> - interrupt-controller;
>>>>>> - #interrupt-cells = <1>;
>>>>>> +&etzpc {
>>>>>> + adc_1: adc@48003000 {
>>>>>> + compatible = "st,stm32mp13-adc-core";
>>>>>> + reg = <0x48003000 0x400>;
>>>>>> + interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc ADC1>, <&rcc ADC1_K>;
>>>>>> + clock-names = "bus", "adc";
>>>>>> + interrupt-controller;
>>>>>> + #interrupt-cells = <1>;
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + feature-domains = <&etzpc 32>;
>>>>>> + status = "disabled";
>>>>>> +
>>>>>> + adc1: adc@0 {
>>>>>> + compatible = "st,stm32mp13-adc";
>>>>>> + #io-channel-cells = <1>;
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> + reg = <0x0>;
>>>>>> + interrupt-parent = <&adc_1>;
>>>>>> + interrupts = <0>;
>>>>>> + dmas = <&dmamux1 9 0x400 0x80000001>;
>>>>>> + dma-names = "rx";
>>>>>> status = "disabled";
>>>>>> - adc1: adc@0 {
>>>>>> - compatible = "st,stm32mp13-adc";
>>>>>> - #io-channel-cells = <1>;
>>>>>> - #address-cells = <1>;
>>>>>> - #size-cells = <0>;
>>>>>> - reg = <0x0>;
>>>>>> - interrupt-parent = <&adc_1>;
>>>>>> - interrupts = <0>;
>>>>>> - dmas = <&dmamux1 9 0x400 0x80000001>;
>>>>>> - dma-names = "rx";
>>>>>> - status = "disabled";
>>>>>> -
>>>>>> - channel@18 {
>>>>>> - reg = <18>;
>>>>>> - label = "vrefint";
>>>>>> - �� };
>>>>>> + channel@18 {
>>>>>> + reg = <18>;
>>>>>> + label = "vrefint";
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>> diff --git a/arch/arm/boot/dts/stm32mp13xc.dtsi
>>>>>> b/arch/arm/boot/dts/stm32mp13xc.dtsi
>>>>>> index 4d00e7592882..a1a7a40c2a3e 100644
>>>>>> --- a/arch/arm/boot/dts/stm32mp13xc.dtsi
>>>>>> +++ b/arch/arm/boot/dts/stm32mp13xc.dtsi
>>>>>> @@ -4,15 +4,14 @@
>>>>>> * Author: Alexandre Torgue <alexandre.torgue@foss.st.com> for
>>>>>> STMicroelectronics.
>>>>>> */
>>>>>> -/ {
>>>>>> - soc {
>>>>>> - cryp: crypto@54002000 {
>>>>>> - compatible = "st,stm32mp1-cryp";
>>>>>> - reg = <0x54002000 0x400>;
>>>>>> - interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc CRYP1>;
>>>>>> - resets = <&rcc CRYP1_R>;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> +&etzpc {
>>>>>> + cryp: crypto@54002000 {
>>>>>> + compatible = "st,stm32mp1-cryp";
>>>>>> + reg = <0x54002000 0x400>;
>>>>>> + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc CRYP1>;
>>>>>> + resets = <&rcc CRYP1_R>;
>>>>>> + feature-domains = <&etzpc 42>;
>>>>>> + status = "disabled";
>>>>>> };
>>>>>> };
>>>>>> diff --git a/arch/arm/boot/dts/stm32mp13xf.dtsi
>>>>>> b/arch/arm/boot/dts/stm32mp13xf.dtsi
>>>>>> index 4d00e7592882..b9fb071a1471 100644
>>>>>> --- a/arch/arm/boot/dts/stm32mp13xf.dtsi
>>>>>> +++ b/arch/arm/boot/dts/stm32mp13xf.dtsi
>>>>>> @@ -4,15 +4,13 @@
>>>>>> * Author: Alexandre Torgue <alexandre.torgue@foss.st.com> for
>>>>>> STMicroelectronics.
>>>>>> */
>>>>>> -/ {
>>>>>> - soc {
>>>>>> - cryp: crypto@54002000 {
>>>>>> - compatible = "st,stm32mp1-cryp";
>>>>>> - reg = <0x54002000 0x400>;
>>>>>> - interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> - clocks = <&rcc CRYP1>;
>>>>>> - resets = <&rcc CRYP1_R>;
>>>>>> - status = "disabled";
>>>>>> - };
>>>>>> +&etzpc {
>>>>>> + cryp: crypto@54002000 {
>>>>>> + compatible = "st,stm32mp1-cryp";
>>>>>> + reg = <0x54002000 0x400>;
>>>>>> + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + clocks = <&rcc CRYP1>;
>>>>>> + resets = <&rcc CRYP1_R>;
>>>>>> + status = "disabled";
>>>>>> };
>>>>>> };
>>>>>
>>>>
>>>
>>> Regarding the patch itself, I can separate it in two patches.
>>> 1)Introduce ETZPC
>>> 2)Move peripherals under ETZPC
>>>
>>> Best regards,
>>> Gatien
>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 3/7] ASoC: mediatek: mt8188: revise ETDM control flow
From: Trevor Wu @ 2023-04-21 10:09 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20230421100905.28045-1-trevor.wu@mediatek.com>
Replace register controls in snd_soc_dai_ops with snd_soc_dapm_widgets.
startup, shutdown and trigger ops are removed, and create DAPM_SUPPLY
to handle mclk, clock gating and etdm enabling. Additionally, mclk setup
sequence is also updated because of new supply enabling sequence.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
---
sound/soc/mediatek/mt8188/mt8188-dai-etdm.c | 790 ++++++++++----------
sound/soc/mediatek/mt8188/mt8188-reg.h | 2 +
2 files changed, 406 insertions(+), 386 deletions(-)
diff --git a/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c b/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
index fddecf5bf7c6..fd6e39a1e4c1 100644
--- a/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
+++ b/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
@@ -21,6 +21,13 @@
#define ETDM_TO_DAI_ID(x) ((x) + MT8188_AFE_IO_ETDM_START)
#define ENUM_TO_STR(x) #x
+enum {
+ SUPPLY_SEQ_ETDM_MCLK,
+ SUPPLY_SEQ_ETDM_CG,
+ SUPPLY_SEQ_DPTX_EN,
+ SUPPLY_SEQ_ETDM_EN,
+};
+
enum {
MTK_DAI_ETDM_FORMAT_I2S = 0,
MTK_DAI_ETDM_FORMAT_LJ,
@@ -84,7 +91,6 @@ struct mtk_dai_etdm_rate {
};
struct mtk_dai_etdm_priv {
- unsigned int clock_mode;
unsigned int data_mode;
bool slave_mode;
bool lrck_inv;
@@ -100,8 +106,6 @@ struct mtk_dai_etdm_priv {
unsigned int cowork_slv_count;
int cowork_slv_id[MT8188_AFE_IO_ETDM_NUM - 1]; //dai_id
bool in_disable_ch[MT8188_ETDM_MAX_CHANNELS];
- unsigned int en_ref_cnt;
- bool is_prepared;
};
static const struct mtk_dai_etdm_rate mt8188_etdm_rates[] = {
@@ -345,14 +349,82 @@ static int mtk_dai_etdm_get_clkdiv_id_by_dai_id(int dai_id)
}
}
+static int get_etdm_id_by_name(struct mtk_base_afe *afe,
+ const char *name)
+{
+ if (!strncmp(name, "ETDM1_IN", strlen("ETDM1_IN")))
+ return MT8188_AFE_IO_ETDM1_IN;
+ else if (!strncmp(name, "ETDM2_IN", strlen("ETDM2_IN")))
+ return MT8188_AFE_IO_ETDM2_IN;
+ else if (!strncmp(name, "ETDM1_OUT", strlen("ETDM1_OUT")))
+ return MT8188_AFE_IO_ETDM1_OUT;
+ else if (!strncmp(name, "ETDM2_OUT", strlen("ETDM2_OUT")))
+ return MT8188_AFE_IO_ETDM2_OUT;
+ else
+ return -EINVAL;
+}
+
+static struct mtk_dai_etdm_priv *get_etdm_priv_by_name(struct mtk_base_afe *afe,
+ const char *name)
+{
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ int dai_id = get_etdm_id_by_name(afe, name);
+
+ if (dai_id < MT8188_AFE_IO_ETDM_START ||
+ dai_id >= MT8188_AFE_IO_ETDM_END)
+ return NULL;
+
+ return afe_priv->dai_priv[dai_id];
+}
+
static int mtk_dai_etdm_enable_mclk(struct mtk_base_afe *afe, int dai_id)
{
struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ struct mtk_dai_etdm_priv *etdm_data;
+ struct etdm_con_reg etdm_reg;
+ unsigned int val = 0;
+ unsigned int mask;
+ int clkmux_id = mtk_dai_etdm_get_clk_id_by_dai_id(dai_id);
int clkdiv_id = mtk_dai_etdm_get_clkdiv_id_by_dai_id(dai_id);
+ int apll_clk_id;
+ int apll;
+ int ret;
+
+ if (!is_valid_etdm_dai(dai_id))
+ return -EINVAL;
+ etdm_data = afe_priv->dai_priv[dai_id];
- if (clkdiv_id < 0)
+ apll = etdm_data->mclk_apll;
+ apll_clk_id = mt8188_afe_get_mclk_source_clk_id(apll);
+
+ if (clkmux_id < 0 || clkdiv_id < 0)
return -EINVAL;
+ if (apll_clk_id < 0)
+ return apll_clk_id;
+
+ ret = get_etdm_reg(dai_id, &etdm_reg);
+ if (ret < 0)
+ return ret;
+
+ mask = ETDM_CON1_MCLK_OUTPUT;
+ if (etdm_data->mclk_dir == SND_SOC_CLOCK_OUT)
+ val = ETDM_CON1_MCLK_OUTPUT;
+ regmap_update_bits(afe->regmap, etdm_reg.con1, mask, val);
+
+ /* enable parent clock before select apll*/
+ mt8188_afe_enable_clk(afe, afe_priv->clk[clkmux_id]);
+
+ /* select apll */
+ ret = mt8188_afe_set_clk_parent(afe, afe_priv->clk[clkmux_id],
+ afe_priv->clk[apll_clk_id]);
+ if (ret)
+ return ret;
+
+ /* set rate */
+ ret = mt8188_afe_set_clk_rate(afe, afe_priv->clk[clkdiv_id],
+ etdm_data->mclk_freq);
+
mt8188_afe_enable_clk(afe, afe_priv->clk[clkdiv_id]);
return 0;
@@ -361,12 +433,207 @@ static int mtk_dai_etdm_enable_mclk(struct mtk_base_afe *afe, int dai_id)
static int mtk_dai_etdm_disable_mclk(struct mtk_base_afe *afe, int dai_id)
{
struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ int clkmux_id = mtk_dai_etdm_get_clk_id_by_dai_id(dai_id);
int clkdiv_id = mtk_dai_etdm_get_clkdiv_id_by_dai_id(dai_id);
- if (clkdiv_id < 0)
+ if (clkmux_id < 0 || clkdiv_id < 0)
return -EINVAL;
mt8188_afe_disable_clk(afe, afe_priv->clk[clkdiv_id]);
+ mt8188_afe_disable_clk(afe, afe_priv->clk[clkmux_id]);
+
+ return 0;
+}
+
+static int mtk_etdm_mclk_connect(struct snd_soc_dapm_widget *source,
+ struct snd_soc_dapm_widget *sink)
+{
+ struct snd_soc_dapm_widget *w = sink;
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ struct mtk_dai_etdm_priv *etdm_priv;
+ int mclk_id;
+
+ mclk_id = get_etdm_id_by_name(afe, source->name);
+ if (mclk_id < 0) {
+ dev_dbg(afe->dev, "mclk_id < 0\n");
+ return 0;
+ }
+
+ etdm_priv = get_etdm_priv_by_name(afe, w->name);
+ if (!etdm_priv) {
+ dev_dbg(afe->dev, "etdm_priv == NULL\n");
+ return 0;
+ }
+
+ if (get_etdm_id_by_name(afe, sink->name) == mclk_id)
+ return !!(etdm_priv->mclk_freq > 0);
+
+ if (etdm_priv->cowork_source_id == mclk_id) {
+ etdm_priv = afe_priv->dai_priv[mclk_id];
+ return !!(etdm_priv->mclk_freq > 0);
+ }
+
+ return 0;
+}
+
+static int mtk_etdm_cowork_connect(struct snd_soc_dapm_widget *source,
+ struct snd_soc_dapm_widget *sink)
+{
+ struct snd_soc_dapm_widget *w = sink;
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ struct mtk_dai_etdm_priv *etdm_priv;
+ int source_id;
+ int i;
+
+ source_id = get_etdm_id_by_name(afe, source->name);
+ if (source_id < 0) {
+ dev_dbg(afe->dev, "%s() source_id < 0\n", __func__);
+ return 0;
+ }
+
+ etdm_priv = get_etdm_priv_by_name(afe, w->name);
+ if (!etdm_priv) {
+ dev_dbg(afe->dev, "%s() etdm_priv == NULL\n", __func__);
+ return 0;
+ }
+
+ if (etdm_priv->cowork_source_id != COWORK_ETDM_NONE) {
+ if (etdm_priv->cowork_source_id == source_id)
+ return 1;
+
+ etdm_priv = afe_priv->dai_priv[etdm_priv->cowork_source_id];
+ for (i = 0; i < etdm_priv->cowork_slv_count; i++) {
+ if (etdm_priv->cowork_slv_id[i] == source_id)
+ return 1;
+ }
+ } else {
+ for (i = 0; i < etdm_priv->cowork_slv_count; i++) {
+ if (etdm_priv->cowork_slv_id[i] == source_id)
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
+static int mtk_etdm_mclk_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+ int mclk_id = get_etdm_id_by_name(afe, w->name);
+
+ if (mclk_id < 0) {
+ dev_dbg(afe->dev, "%s() mclk_id < 0\n", __func__);
+ return 0;
+ }
+
+ dev_dbg(cmpnt->dev, "%s(), name %s, event 0x%x\n",
+ __func__, w->name, event);
+
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ mtk_dai_etdm_enable_mclk(afe, mclk_id);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ mtk_dai_etdm_disable_mclk(afe, mclk_id);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static int mtk_dptx_mclk_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+
+ dev_dbg(cmpnt->dev, "%s(), name %s, event 0x%x\n",
+ __func__, w->name, event);
+
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ mtk_dai_etdm_enable_mclk(afe, MT8188_AFE_IO_DPTX);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ mtk_dai_etdm_disable_mclk(afe, MT8188_AFE_IO_DPTX);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static int mtk_etdm_cg_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ int etdm_id;
+ int cg_id;
+
+ etdm_id = get_etdm_id_by_name(afe, w->name);
+ if (etdm_id < 0) {
+ dev_dbg(afe->dev, "%s() etdm_id < 0\n", __func__);
+ return 0;
+ }
+
+ cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(etdm_id);
+ if (cg_id < 0) {
+ dev_dbg(afe->dev, "%s() cg_id < 0\n", __func__);
+ return 0;
+ }
+
+ dev_dbg(cmpnt->dev, "%s(), name %s, event 0x%x\n",
+ __func__, w->name, event);
+
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ mt8188_afe_enable_clk(afe, afe_priv->clk[cg_id]);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ mt8188_afe_disable_clk(afe, afe_priv->clk[cg_id]);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static int mtk_etdm3_cg_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+
+ dev_dbg(cmpnt->dev, "%s(), name %s, event 0x%x\n",
+ __func__, w->name, event);
+
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ mt8188_afe_enable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_HDMI_OUT]);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ mt8188_afe_disable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_HDMI_OUT]);
+ break;
+ default:
+ break;
+ }
return 0;
}
@@ -906,11 +1173,141 @@ static const struct snd_soc_dapm_widget mtk_dai_etdm_widgets[] = {
SND_SOC_DAPM_MUX("HDMI_CH7_MUX", SND_SOC_NOPM, 0, 0,
&hdmi_ch7_mux_control),
+ /* mclk en */
+ SND_SOC_DAPM_SUPPLY_S("ETDM1_IN_MCLK", SUPPLY_SEQ_ETDM_MCLK,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_mclk_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("ETDM2_IN_MCLK", SUPPLY_SEQ_ETDM_MCLK,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_mclk_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("ETDM1_OUT_MCLK", SUPPLY_SEQ_ETDM_MCLK,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_mclk_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("ETDM2_OUT_MCLK", SUPPLY_SEQ_ETDM_MCLK,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_mclk_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("DPTX_MCLK", SUPPLY_SEQ_ETDM_MCLK,
+ SND_SOC_NOPM, 0, 0,
+ mtk_dptx_mclk_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+
+ /* cg */
+ SND_SOC_DAPM_SUPPLY_S("ETDM1_IN_CG", SUPPLY_SEQ_ETDM_CG,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_cg_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("ETDM2_IN_CG", SUPPLY_SEQ_ETDM_CG,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_cg_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("ETDM1_OUT_CG", SUPPLY_SEQ_ETDM_CG,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_cg_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("ETDM2_OUT_CG", SUPPLY_SEQ_ETDM_CG,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm_cg_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S("ETDM3_OUT_CG", SUPPLY_SEQ_ETDM_CG,
+ SND_SOC_NOPM, 0, 0,
+ mtk_etdm3_cg_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+
+ /* en */
+ SND_SOC_DAPM_SUPPLY_S("ETDM1_IN_EN", SUPPLY_SEQ_ETDM_EN,
+ ETDM_IN1_CON0, ETDM_CON0_EN_SHIFT, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY_S("ETDM2_IN_EN", SUPPLY_SEQ_ETDM_EN,
+ ETDM_IN2_CON0, ETDM_CON0_EN_SHIFT, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY_S("ETDM1_OUT_EN", SUPPLY_SEQ_ETDM_EN,
+ ETDM_OUT1_CON0, ETDM_CON0_EN_SHIFT, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY_S("ETDM2_OUT_EN", SUPPLY_SEQ_ETDM_EN,
+ ETDM_OUT2_CON0, ETDM_CON0_EN_SHIFT, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY_S("ETDM3_OUT_EN", SUPPLY_SEQ_ETDM_EN,
+ ETDM_OUT3_CON0, ETDM_CON0_EN_SHIFT, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY_S("DPTX_EN", SUPPLY_SEQ_DPTX_EN,
+ AFE_DPTX_CON, AFE_DPTX_CON_ON_SHIFT, 0, NULL, 0),
+
SND_SOC_DAPM_INPUT("ETDM_INPUT"),
SND_SOC_DAPM_OUTPUT("ETDM_OUTPUT"),
};
static const struct snd_soc_dapm_route mtk_dai_etdm_routes[] = {
+ /* mclk */
+ {"ETDM1_IN", NULL, "ETDM1_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM1_IN", NULL, "ETDM2_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM1_IN", NULL, "ETDM1_OUT_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM1_IN", NULL, "ETDM2_OUT_MCLK", mtk_etdm_mclk_connect},
+
+ {"ETDM2_IN", NULL, "ETDM1_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM2_IN", NULL, "ETDM2_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM2_IN", NULL, "ETDM1_OUT_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM2_IN", NULL, "ETDM2_OUT_MCLK", mtk_etdm_mclk_connect},
+
+ {"ETDM1_OUT", NULL, "ETDM1_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM1_OUT", NULL, "ETDM2_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM1_OUT", NULL, "ETDM1_OUT_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM1_OUT", NULL, "ETDM2_OUT_MCLK", mtk_etdm_mclk_connect},
+
+ {"ETDM2_OUT", NULL, "ETDM1_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM2_OUT", NULL, "ETDM2_IN_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM2_OUT", NULL, "ETDM1_OUT_MCLK", mtk_etdm_mclk_connect},
+ {"ETDM2_OUT", NULL, "ETDM2_OUT_MCLK", mtk_etdm_mclk_connect},
+
+ {"DPTX", NULL, "DPTX_MCLK"},
+
+ /* cg */
+ {"ETDM1_IN", NULL, "ETDM1_IN_CG"},
+ {"ETDM1_IN", NULL, "ETDM2_IN_CG", mtk_etdm_cowork_connect},
+ {"ETDM1_IN", NULL, "ETDM1_OUT_CG", mtk_etdm_cowork_connect},
+ {"ETDM1_IN", NULL, "ETDM2_OUT_CG", mtk_etdm_cowork_connect},
+
+ {"ETDM2_IN", NULL, "ETDM1_IN_CG", mtk_etdm_cowork_connect},
+ {"ETDM2_IN", NULL, "ETDM2_IN_CG"},
+ {"ETDM2_IN", NULL, "ETDM1_OUT_CG", mtk_etdm_cowork_connect},
+ {"ETDM2_IN", NULL, "ETDM2_OUT_CG", mtk_etdm_cowork_connect},
+
+ {"ETDM1_OUT", NULL, "ETDM1_IN_CG", mtk_etdm_cowork_connect},
+ {"ETDM1_OUT", NULL, "ETDM2_IN_CG", mtk_etdm_cowork_connect},
+ {"ETDM1_OUT", NULL, "ETDM1_OUT_CG"},
+ {"ETDM1_OUT", NULL, "ETDM2_OUT_CG", mtk_etdm_cowork_connect},
+
+ {"ETDM2_OUT", NULL, "ETDM1_IN_CG", mtk_etdm_cowork_connect},
+ {"ETDM2_OUT", NULL, "ETDM2_IN_CG", mtk_etdm_cowork_connect},
+ {"ETDM2_OUT", NULL, "ETDM1_OUT_CG", mtk_etdm_cowork_connect},
+ {"ETDM2_OUT", NULL, "ETDM2_OUT_CG"},
+
+ {"ETDM3_OUT", NULL, "ETDM3_OUT_CG"},
+ {"DPTX", NULL, "ETDM3_OUT_CG"},
+
+ /* en */
+ {"ETDM1_IN", NULL, "ETDM1_IN_EN"},
+ {"ETDM1_IN", NULL, "ETDM2_IN_EN", mtk_etdm_cowork_connect},
+ {"ETDM1_IN", NULL, "ETDM1_OUT_EN", mtk_etdm_cowork_connect},
+ {"ETDM1_IN", NULL, "ETDM2_OUT_EN", mtk_etdm_cowork_connect},
+
+ {"ETDM2_IN", NULL, "ETDM1_IN_EN", mtk_etdm_cowork_connect},
+ {"ETDM2_IN", NULL, "ETDM2_IN_EN"},
+ {"ETDM2_IN", NULL, "ETDM1_OUT_EN", mtk_etdm_cowork_connect},
+ {"ETDM2_IN", NULL, "ETDM2_OUT_EN", mtk_etdm_cowork_connect},
+
+ {"ETDM1_OUT", NULL, "ETDM1_IN_EN", mtk_etdm_cowork_connect},
+ {"ETDM1_OUT", NULL, "ETDM2_IN_EN", mtk_etdm_cowork_connect},
+ {"ETDM1_OUT", NULL, "ETDM1_OUT_EN"},
+ {"ETDM1_OUT", NULL, "ETDM2_OUT_EN", mtk_etdm_cowork_connect},
+
+ {"ETDM2_OUT", NULL, "ETDM1_IN_EN", mtk_etdm_cowork_connect},
+ {"ETDM2_OUT", NULL, "ETDM2_IN_EN", mtk_etdm_cowork_connect},
+ {"ETDM2_OUT", NULL, "ETDM1_OUT_EN", mtk_etdm_cowork_connect},
+ {"ETDM2_OUT", NULL, "ETDM2_OUT_EN"},
+
+ {"ETDM3_OUT", NULL, "ETDM3_OUT_EN"},
+ {"DPTX", NULL, "ETDM3_OUT_EN"},
+ {"DPTX", NULL, "DPTX_EN"},
+
{"I012", NULL, "ETDM2_IN"},
{"I013", NULL, "ETDM2_IN"},
{"I014", NULL, "ETDM2_IN"},
@@ -1163,64 +1560,6 @@ static const struct snd_soc_dapm_route mtk_dai_etdm_routes[] = {
{"ETDM2_IN", NULL, "ETDM_INPUT"},
};
-static int mt8188_afe_enable_etdm(struct mtk_base_afe *afe, int dai_id)
-{
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct mtk_dai_etdm_priv *etdm_data;
- struct etdm_con_reg etdm_reg;
- unsigned long flags;
- int ret = 0;
-
- if (!is_valid_etdm_dai(dai_id))
- return -EINVAL;
- etdm_data = afe_priv->dai_priv[dai_id];
-
- dev_dbg(afe->dev, "%s [%d]%d\n", __func__, dai_id, etdm_data->en_ref_cnt);
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
- etdm_data->en_ref_cnt++;
- if (etdm_data->en_ref_cnt == 1) {
- ret = get_etdm_reg(dai_id, &etdm_reg);
- if (ret < 0)
- goto out;
-
- regmap_set_bits(afe->regmap, etdm_reg.con0, ETDM_CON0_EN);
- }
-
-out:
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
- return ret;
-}
-
-static int mt8188_afe_disable_etdm(struct mtk_base_afe *afe, int dai_id)
-{
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct mtk_dai_etdm_priv *etdm_data;
- struct etdm_con_reg etdm_reg;
- unsigned long flags;
- int ret = 0;
-
- if (!is_valid_etdm_dai(dai_id))
- return -EINVAL;
- etdm_data = afe_priv->dai_priv[dai_id];
-
- dev_dbg(afe->dev, "%s [%d]%d\n", __func__, dai_id, etdm_data->en_ref_cnt);
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
- if (etdm_data->en_ref_cnt > 0) {
- etdm_data->en_ref_cnt--;
- if (etdm_data->en_ref_cnt == 0) {
- ret = get_etdm_reg(dai_id, &etdm_reg);
- if (ret < 0)
- goto out;
- regmap_clear_bits(afe->regmap, etdm_reg.con0,
- ETDM_CON0_EN);
- }
- }
-
-out:
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
- return ret;
-}
-
static int etdm_cowork_slv_sel(int id, int slave_mode)
{
if (slave_mode) {
@@ -1408,121 +1747,6 @@ static int mt8188_etdm_sync_mode_configure(struct mtk_base_afe *afe, int dai_id)
}
/* dai ops */
-static int mtk_dai_etdm_startup(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct mtk_dai_etdm_priv *mst_etdm_data;
- int mst_dai_id;
- int slv_dai_id;
- int cg_id;
- int i;
-
- if (is_cowork_mode(dai)) {
- mst_dai_id = get_etdm_cowork_master_id(dai);
- if (!is_valid_etdm_dai(mst_dai_id))
- return -EINVAL;
- mtk_dai_etdm_enable_mclk(afe, mst_dai_id);
-
- cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(mst_dai_id);
- if (cg_id >= 0)
- mt8188_afe_enable_clk(afe, afe_priv->clk[cg_id]);
-
- mst_etdm_data = afe_priv->dai_priv[mst_dai_id];
-
- for (i = 0; i < mst_etdm_data->cowork_slv_count; i++) {
- slv_dai_id = mst_etdm_data->cowork_slv_id[i];
- cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(slv_dai_id);
- if (cg_id >= 0)
- mt8188_afe_enable_clk(afe,
- afe_priv->clk[cg_id]);
- }
- } else {
- mtk_dai_etdm_enable_mclk(afe, dai->id);
-
- cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(dai->id);
- if (cg_id >= 0)
- mt8188_afe_enable_clk(afe, afe_priv->clk[cg_id]);
- }
-
- return 0;
-}
-
-static void mtk_dai_etdm_shutdown(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct mtk_dai_etdm_priv *mst_etdm_data;
- int mst_dai_id;
- int slv_dai_id;
- int cg_id;
- int ret;
- int i;
-
- if (!is_valid_etdm_dai(dai->id))
- return;
- mst_etdm_data = afe_priv->dai_priv[dai->id];
-
- dev_dbg(afe->dev, "%s(), dai id %d, prepared %d\n", __func__, dai->id,
- mst_etdm_data->is_prepared);
-
- if (mst_etdm_data->is_prepared) {
- mst_etdm_data->is_prepared = false;
-
- if (is_cowork_mode(dai)) {
- mst_dai_id = get_etdm_cowork_master_id(dai);
- if (!is_valid_etdm_dai(mst_dai_id))
- return;
- mst_etdm_data = afe_priv->dai_priv[mst_dai_id];
-
- ret = mt8188_afe_disable_etdm(afe, mst_dai_id);
- if (ret)
- dev_dbg(afe->dev, "%s disable %d failed\n",
- __func__, mst_dai_id);
-
- for (i = 0; i < mst_etdm_data->cowork_slv_count; i++) {
- slv_dai_id = mst_etdm_data->cowork_slv_id[i];
- ret = mt8188_afe_disable_etdm(afe, slv_dai_id);
- if (ret)
- dev_dbg(afe->dev, "%s disable %d failed\n",
- __func__, slv_dai_id);
- }
- } else {
- ret = mt8188_afe_disable_etdm(afe, dai->id);
- if (ret)
- dev_dbg(afe->dev, "%s disable %d failed\n",
- __func__, dai->id);
- }
- }
-
- if (is_cowork_mode(dai)) {
- mst_dai_id = get_etdm_cowork_master_id(dai);
- if (!is_valid_etdm_dai(mst_dai_id))
- return;
- cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(mst_dai_id);
- if (cg_id >= 0)
- mt8188_afe_disable_clk(afe, afe_priv->clk[cg_id]);
-
- mst_etdm_data = afe_priv->dai_priv[mst_dai_id];
- for (i = 0; i < mst_etdm_data->cowork_slv_count; i++) {
- slv_dai_id = mst_etdm_data->cowork_slv_id[i];
- cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(slv_dai_id);
- if (cg_id >= 0)
- mt8188_afe_disable_clk(afe,
- afe_priv->clk[cg_id]);
- }
- mtk_dai_etdm_disable_mclk(afe, mst_dai_id);
- } else {
- cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(dai->id);
- if (cg_id >= 0)
- mt8188_afe_disable_clk(afe, afe_priv->clk[cg_id]);
-
- mtk_dai_etdm_disable_mclk(afe, dai->id);
- }
-}
-
static int mtk_dai_etdm_fifo_mode(struct mtk_base_afe *afe,
int dai_id, unsigned int rate)
{
@@ -1759,60 +1983,6 @@ static int mtk_dai_etdm_out_configure(struct mtk_base_afe *afe,
return 0;
}
-static int mtk_dai_etdm_mclk_configure(struct mtk_base_afe *afe, int dai_id)
-{
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct mtk_dai_etdm_priv *etdm_data;
- struct etdm_con_reg etdm_reg;
- int clk_id = mtk_dai_etdm_get_clk_id_by_dai_id(dai_id);
- int clkdiv_id = mtk_dai_etdm_get_clkdiv_id_by_dai_id(dai_id);
- int apll_clk_id;
- int apll;
- int ret;
-
- if (clk_id < 0 || clkdiv_id < 0)
- return -EINVAL;
-
- if (!is_valid_etdm_dai(dai_id))
- return -EINVAL;
- etdm_data = afe_priv->dai_priv[dai_id];
-
- ret = get_etdm_reg(dai_id, &etdm_reg);
- if (ret < 0)
- return ret;
-
- if (etdm_data->mclk_dir == SND_SOC_CLOCK_OUT)
- regmap_set_bits(afe->regmap, etdm_reg.con1,
- ETDM_CON1_MCLK_OUTPUT);
- else
- regmap_clear_bits(afe->regmap, etdm_reg.con1,
- ETDM_CON1_MCLK_OUTPUT);
-
- if (etdm_data->mclk_freq) {
- apll = etdm_data->mclk_apll;
- apll_clk_id = mt8188_afe_get_mclk_source_clk_id(apll);
- if (apll_clk_id < 0)
- return apll_clk_id;
-
- /* select apll */
- ret = mt8188_afe_set_clk_parent(afe, afe_priv->clk[clk_id],
- afe_priv->clk[apll_clk_id]);
- if (ret)
- return ret;
-
- /* set rate */
- ret = mt8188_afe_set_clk_rate(afe, afe_priv->clk[clkdiv_id],
- etdm_data->mclk_freq);
- if (ret)
- return ret;
- } else {
- if (etdm_data->mclk_dir == SND_SOC_CLOCK_OUT)
- dev_dbg(afe->dev, "%s mclk freq = 0\n", __func__);
- }
-
- return 0;
-}
-
static int mtk_dai_etdm_configure(struct mtk_base_afe *afe,
unsigned int rate,
unsigned int channels,
@@ -1839,10 +2009,10 @@ static int mtk_dai_etdm_configure(struct mtk_base_afe *afe,
if (ret < 0)
return ret;
- dev_dbg(afe->dev, "%s fmt %u data %u lrck %d-%u bck %d, clock %u slv %u\n",
+ dev_dbg(afe->dev, "%s fmt %u data %u lrck %d-%u bck %d, slv %u\n",
__func__, etdm_data->format, etdm_data->data_mode,
etdm_data->lrck_inv, etdm_data->lrck_width, etdm_data->bck_inv,
- etdm_data->clock_mode, etdm_data->slave_mode);
+ etdm_data->slave_mode);
dev_dbg(afe->dev, "%s rate %u channels %u bitwidth %u, id %d\n",
__func__, rate, channels, bit_width, dai_id);
@@ -1913,10 +2083,6 @@ static int mtk_dai_etdm_hw_params(struct snd_pcm_substream *substream,
if (mst_etdm_data->slots)
channels = mst_etdm_data->slots;
- ret = mtk_dai_etdm_mclk_configure(afe, mst_dai_id);
- if (ret)
- return ret;
-
ret = mtk_dai_etdm_configure(afe, rate, channels,
bit_width, mst_dai_id);
if (ret)
@@ -1940,10 +2106,6 @@ static int mtk_dai_etdm_hw_params(struct snd_pcm_substream *substream,
if (mst_etdm_data->slots)
channels = mst_etdm_data->slots;
- ret = mtk_dai_etdm_mclk_configure(afe, dai->id);
- if (ret)
- return ret;
-
ret = mtk_dai_etdm_configure(afe, rate, channels,
bit_width, dai->id);
if (ret)
@@ -1953,66 +2115,6 @@ static int mtk_dai_etdm_hw_params(struct snd_pcm_substream *substream,
return 0;
}
-static int mtk_dai_etdm_prepare(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct mtk_dai_etdm_priv *mst_etdm_data;
- int mst_dai_id;
- int slv_dai_id;
- int ret;
- int i;
-
- if (!is_valid_etdm_dai(dai->id))
- return -EINVAL;
- mst_etdm_data = afe_priv->dai_priv[dai->id];
-
- dev_dbg(afe->dev, "%s(), dai id %d, prepared %d\n", __func__, dai->id,
- mst_etdm_data->is_prepared);
-
- if (mst_etdm_data->is_prepared)
- return 0;
-
- mst_etdm_data->is_prepared = true;
-
- if (is_cowork_mode(dai)) {
- mst_dai_id = get_etdm_cowork_master_id(dai);
- if (!is_valid_etdm_dai(mst_dai_id))
- return -EINVAL;
- mst_etdm_data = afe_priv->dai_priv[mst_dai_id];
-
- for (i = 0; i < mst_etdm_data->cowork_slv_count; i++) {
- slv_dai_id = mst_etdm_data->cowork_slv_id[i];
- ret = mt8188_afe_enable_etdm(afe, slv_dai_id);
- if (ret) {
- dev_dbg(afe->dev, "%s enable %d failed\n",
- __func__, slv_dai_id);
-
- return ret;
- }
- }
-
- ret = mt8188_afe_enable_etdm(afe, mst_dai_id);
- if (ret) {
- dev_dbg(afe->dev, "%s enable %d failed\n",
- __func__, mst_dai_id);
-
- return ret;
- }
- } else {
- ret = mt8188_afe_enable_etdm(afe, dai->id);
- if (ret) {
- dev_dbg(afe->dev, "%s enable %d failed\n",
- __func__, dai->id);
-
- return ret;
- }
- }
-
- return 0;
-}
-
static int mtk_dai_etdm_cal_mclk(struct mtk_base_afe *afe, int freq, int dai_id)
{
struct mt8188_afe_private *afe_priv = afe->platform_priv;
@@ -2166,53 +2268,6 @@ static int mtk_dai_etdm_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
return 0;
}
-static int mtk_dai_hdmitx_dptx_startup(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- int cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(dai->id);
-
- if (cg_id >= 0)
- mt8188_afe_enable_clk(afe, afe_priv->clk[cg_id]);
-
- mtk_dai_etdm_enable_mclk(afe, dai->id);
-
- return 0;
-}
-
-static void mtk_dai_hdmitx_dptx_shutdown(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- int cg_id = mtk_dai_etdm_get_cg_id_by_dai_id(dai->id);
- struct mtk_dai_etdm_priv *etdm_data;
- int ret;
-
- if (!is_valid_etdm_dai(dai->id))
- return;
- etdm_data = afe_priv->dai_priv[dai->id];
-
- if (etdm_data->is_prepared) {
- etdm_data->is_prepared = false;
- /* disable etdm_out3 */
- ret = mt8188_afe_disable_etdm(afe, dai->id);
- if (ret)
- dev_dbg(afe->dev, "%s disable failed\n", __func__);
-
- /* disable dptx interface */
- if (dai->id == MT8188_AFE_IO_DPTX)
- regmap_clear_bits(afe->regmap, AFE_DPTX_CON,
- AFE_DPTX_CON_ON);
- }
-
- mtk_dai_etdm_disable_mclk(afe, dai->id);
-
- if (cg_id >= 0)
- mt8188_afe_disable_clk(afe, afe_priv->clk[cg_id]);
-}
-
static unsigned int mtk_dai_get_dptx_ch_en(unsigned int channel)
{
switch (channel) {
@@ -2280,42 +2335,11 @@ static int mtk_dai_hdmitx_dptx_hw_params(struct snd_pcm_substream *substream,
etdm_data->data_mode = MTK_DAI_ETDM_DATA_MULTI_PIN;
}
- ret = mtk_dai_etdm_mclk_configure(afe, dai->id);
- if (ret)
- return ret;
-
ret = mtk_dai_etdm_configure(afe, rate, channels, width, dai->id);
return ret;
}
-static int mtk_dai_hdmitx_dptx_prepare(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct mtk_dai_etdm_priv *etdm_data;
-
- if (!is_valid_etdm_dai(dai->id))
- return -EINVAL;
- etdm_data = afe_priv->dai_priv[dai->id];
-
- dev_dbg(afe->dev, "%s(), dai id %d, prepared %d\n", __func__, dai->id,
- etdm_data->is_prepared);
-
- if (etdm_data->is_prepared)
- return 0;
-
- etdm_data->is_prepared = true;
-
- /* enable dptx interface */
- if (dai->id == MT8188_AFE_IO_DPTX)
- regmap_set_bits(afe->regmap, AFE_DPTX_CON, AFE_DPTX_CON_ON);
-
- /* enable etdm_out3 */
- return mt8188_afe_enable_etdm(afe, dai->id);
-}
-
static int mtk_dai_hdmitx_dptx_set_sysclk(struct snd_soc_dai *dai,
int clk_id,
unsigned int freq,
@@ -2337,20 +2361,14 @@ static int mtk_dai_hdmitx_dptx_set_sysclk(struct snd_soc_dai *dai,
}
static const struct snd_soc_dai_ops mtk_dai_etdm_ops = {
- .startup = mtk_dai_etdm_startup,
- .shutdown = mtk_dai_etdm_shutdown,
.hw_params = mtk_dai_etdm_hw_params,
- .prepare = mtk_dai_etdm_prepare,
.set_sysclk = mtk_dai_etdm_set_sysclk,
.set_fmt = mtk_dai_etdm_set_fmt,
.set_tdm_slot = mtk_dai_etdm_set_tdm_slot,
};
static const struct snd_soc_dai_ops mtk_dai_hdmitx_dptx_ops = {
- .startup = mtk_dai_hdmitx_dptx_startup,
- .shutdown = mtk_dai_hdmitx_dptx_shutdown,
.hw_params = mtk_dai_hdmitx_dptx_hw_params,
- .prepare = mtk_dai_hdmitx_dptx_prepare,
.set_sysclk = mtk_dai_hdmitx_dptx_set_sysclk,
.set_fmt = mtk_dai_etdm_set_fmt,
};
diff --git a/sound/soc/mediatek/mt8188/mt8188-reg.h b/sound/soc/mediatek/mt8188/mt8188-reg.h
index 51cd1a83dd9d..bdd885419ff3 100644
--- a/sound/soc/mediatek/mt8188/mt8188-reg.h
+++ b/sound/soc/mediatek/mt8188/mt8188-reg.h
@@ -3007,6 +3007,7 @@
#define ETDM_CON0_SLAVE_MODE BIT(5)
#define ETDM_CON0_SYNC_MODE BIT(1)
#define ETDM_CON0_EN BIT(0)
+#define ETDM_CON0_EN_SHIFT 0
#define ETDM_OUT_CON0_RELATCH_DOMAIN_MASK GENMASK(29, 28)
@@ -3108,6 +3109,7 @@
#define AFE_DPTX_CON_CH_NUM_8CH (0x1 << 1)
#define AFE_DPTX_CON_CH_NUM_MASK BIT(1)
#define AFE_DPTX_CON_ON BIT(0)
+#define AFE_DPTX_CON_ON_SHIFT 0
/* AFE_ADDA_DL_SRC2_CON0 */
#define DL_2_INPUT_MODE_CTL_MASK GENMASK(31, 28)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/7] ASoC: mediatek: mt8188: revise AFE driver
From: Trevor Wu @ 2023-04-21 10:08 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
The series of patches consists of three major changes.
First, remove redundant supply for ADDA DAI dirver. Second, revise ETDM
control including APLL dynamic switch via DAPM, so APLL can be enabled
when it is really required. Finally, AFE probe function is updated. Bus
protection change was dropped at the previous patch because the dependent
change was not accepted.
Changes since v1:
- replace unnecessary dev_info with dev_dbg
- fix dt-binging ABI breaking behavior
Trevor Wu (7):
ASoC: mediatek: mt8188: remove supply AUDIO_HIRES
ASoC: mediatek: mt8188: complete set_tdm_slot function
ASoC: mediatek: mt8188: revise ETDM control flow
ASoC: mediatek: mt8188: refine APLL control
ASoC: mediatek: mt8188: combine afe component registration
ASoC: mediatek: mt8188: add bus protection
ASoC: dt-bindings: mediatek,mt8188-afe: add audio properties
.../bindings/sound/mediatek,mt8188-afe.yaml | 16 +-
sound/soc/mediatek/mt8188/mt8188-afe-clk.c | 138 ++-
sound/soc/mediatek/mt8188/mt8188-afe-clk.h | 11 +
sound/soc/mediatek/mt8188/mt8188-afe-pcm.c | 113 ++-
sound/soc/mediatek/mt8188/mt8188-dai-adda.c | 37 -
sound/soc/mediatek/mt8188/mt8188-dai-etdm.c | 922 ++++++++++--------
sound/soc/mediatek/mt8188/mt8188-reg.h | 2 +
7 files changed, 755 insertions(+), 484 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 7/7] ASoC: dt-bindings: mediatek,mt8188-afe: add audio properties
From: Trevor Wu @ 2023-04-21 10:09 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20230421100905.28045-1-trevor.wu@mediatek.com>
Assign top_a1sys_hp clock to 26M, and add apll1_d4 to clocks for switching
the parent of top_a1sys_hp dynamically
On the other hand, "mediatek,infracfg" is included for bus protection.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
---
.../bindings/sound/mediatek,mt8188-afe.yaml | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
index 82ccb32f08f2..812e0702ca36 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
@@ -29,6 +29,10 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek topckgen controller
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the mediatek infracfg controller
+
power-domains:
maxItems: 1
@@ -52,6 +56,7 @@ properties:
- description: mux for i2si1_mck
- description: mux for i2si2_mck
- description: audio 26m clock
+ - description: audio pll1 divide 4
clock-names:
items:
@@ -73,6 +78,7 @@ properties:
- const: i2si1_m_sel
- const: i2si2_m_sel
- const: adsp_audio_26m
+ - const: apll1_d4
mediatek,etdm-in1-cowork-source:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -147,6 +153,8 @@ required:
- power-domains
- clocks
- clock-names
+ - assigned-clocks
+ - assigned-clock-parents
additionalProperties: false
@@ -184,7 +192,8 @@ examples:
<&topckgen 78>, //CLK_TOP_I2SO2
<&topckgen 79>, //CLK_TOP_I2SI1
<&topckgen 80>, //CLK_TOP_I2SI2
- <&adsp_audio26m 0>; //CLK_AUDIODSP_AUDIO26M
+ <&adsp_audio26m 0>, //CLK_AUDIODSP_AUDIO26M
+ <&topckgen 136>; //CLK_TOP_APLL1_D4
clock-names = "clk26m",
"apll1",
"apll2",
@@ -202,7 +211,10 @@ examples:
"i2so2_m_sel",
"i2si1_m_sel",
"i2si2_m_sel",
- "adsp_audio_26m";
+ "adsp_audio_26m",
+ "apll1_d4";
+ assigned-clocks = <&topckgen 83>; //CLK_TOP_A1SYS_HP
+ assigned-clock-parents = <&clk26m>;
};
...
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/7] ASoC: mediatek: mt8188: combine afe component registration
From: Trevor Wu @ 2023-04-21 10:09 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20230421100905.28045-1-trevor.wu@mediatek.com>
There is no benefit to separate two components for AFE, so DAI driver
registration is moved to dev_snd_soc_register_component to merge these
two components.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
---
sound/soc/mediatek/mt8188/mt8188-afe-pcm.c | 37 ++--------------------
1 file changed, 2 insertions(+), 35 deletions(-)
diff --git a/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c b/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
index e5f9373bed56..fecc891f892d 100644
--- a/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
+++ b/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
@@ -1898,10 +1898,6 @@ static const struct snd_kcontrol_new mt8188_memif_controls[] = {
MT8188_AFE_MEMIF_UL10),
};
-static const struct snd_soc_component_driver mt8188_afe_pcm_dai_component = {
- .name = "mt8188-afe-pcm-dai",
-};
-
static const struct mtk_base_memif_data memif_data[MT8188_AFE_MEMIF_NUM] = {
[MT8188_AFE_MEMIF_DL2] = {
.name = "DL2",
@@ -3142,9 +3138,8 @@ static int mt8188_afe_pcm_dev_probe(struct platform_device *pdev)
struct mtk_base_afe *afe;
struct mt8188_afe_private *afe_priv;
struct device *dev;
- int i, irq_id, ret;
- struct snd_soc_component *component;
struct reset_control *rstc;
+ int i, irq_id, ret;
ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(33));
if (ret)
@@ -3280,34 +3275,12 @@ static int mt8188_afe_pcm_dev_probe(struct platform_device *pdev)
/* register component */
ret = devm_snd_soc_register_component(dev, &mt8188_afe_component,
- NULL, 0);
+ afe->dai_drivers, afe->num_dai_drivers);
if (ret) {
dev_warn(dev, "err_platform\n");
goto err_pm_put;
}
- component = devm_kzalloc(&pdev->dev, sizeof(*component), GFP_KERNEL);
- if (!component) {
- ret = -ENOMEM;
- goto err_pm_put;
- }
-
- ret = snd_soc_component_initialize(component,
- &mt8188_afe_pcm_dai_component,
- &pdev->dev);
- if (ret)
- goto err_pm_put;
-#ifdef CONFIG_DEBUG_FS
- component->debugfs_prefix = "pcm";
-#endif
- ret = snd_soc_add_component(component,
- afe->dai_drivers,
- afe->num_dai_drivers);
- if (ret) {
- dev_warn(dev, "err_add_component\n");
- goto err_pm_put;
- }
-
mt8188_afe_init_registers(afe);
pm_runtime_put_sync(&pdev->dev);
@@ -3323,11 +3296,6 @@ static int mt8188_afe_pcm_dev_probe(struct platform_device *pdev)
return ret;
}
-static void mt8188_afe_pcm_dev_remove(struct platform_device *pdev)
-{
- snd_soc_unregister_component(&pdev->dev);
-}
-
static const struct of_device_id mt8188_afe_pcm_dt_match[] = {
{ .compatible = "mediatek,mt8188-afe", },
{},
@@ -3346,7 +3314,6 @@ static struct platform_driver mt8188_afe_pcm_driver = {
.pm = &mt8188_afe_pm_ops,
},
.probe = mt8188_afe_pcm_dev_probe,
- .remove_new = mt8188_afe_pcm_dev_remove,
};
module_platform_driver(mt8188_afe_pcm_driver);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/7] ASoC: mediatek: mt8188: add bus protection
From: Trevor Wu @ 2023-04-21 10:09 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20230421100905.28045-1-trevor.wu@mediatek.com>
Add bus protection for reset controller.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
---
sound/soc/mediatek/mt8188/mt8188-afe-pcm.c | 76 ++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c b/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
index fecc891f892d..c3fd32764da0 100644
--- a/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
+++ b/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
@@ -17,6 +17,7 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/pm_runtime.h>
+#include <linux/soc/mediatek/infracfg.h>
#include <linux/reset.h>
#include <sound/pcm_params.h>
#include "mt8188-afe-common.h"
@@ -3133,12 +3134,68 @@ static int mt8188_afe_parse_of(struct mtk_base_afe *afe,
return 0;
}
+#define MT8188_DELAY_US 10
+#define MT8188_TIMEOUT_US USEC_PER_SEC
+
+static int bus_protect_enable(struct regmap *regmap)
+{
+ int ret;
+ u32 val;
+ u32 mask;
+
+ val = 0;
+ mask = MT8188_TOP_AXI_PROT_EN_2_AUDIO_STEP1;
+ regmap_write(regmap, MT8188_TOP_AXI_PROT_EN_2_SET, mask);
+
+ ret = regmap_read_poll_timeout(regmap, MT8188_TOP_AXI_PROT_EN_2_STA,
+ val, (val & mask) == mask,
+ MT8188_DELAY_US, MT8188_TIMEOUT_US);
+ if (ret)
+ return ret;
+
+ val = 0;
+ mask = MT8188_TOP_AXI_PROT_EN_2_AUDIO_STEP2;
+ regmap_write(regmap, MT8188_TOP_AXI_PROT_EN_2_SET, mask);
+
+ ret = regmap_read_poll_timeout(regmap, MT8188_TOP_AXI_PROT_EN_2_STA,
+ val, (val & mask) == mask,
+ MT8188_DELAY_US, MT8188_TIMEOUT_US);
+ return ret;
+}
+
+static int bus_protect_disable(struct regmap *regmap)
+{
+ int ret;
+ u32 val;
+ u32 mask;
+
+ val = 0;
+ mask = MT8188_TOP_AXI_PROT_EN_2_AUDIO_STEP2;
+ regmap_write(regmap, MT8188_TOP_AXI_PROT_EN_2_CLR, mask);
+
+ ret = regmap_read_poll_timeout(regmap, MT8188_TOP_AXI_PROT_EN_2_STA,
+ val, !(val & mask),
+ MT8188_DELAY_US, MT8188_TIMEOUT_US);
+ if (ret)
+ return ret;
+
+ val = 0;
+ mask = MT8188_TOP_AXI_PROT_EN_2_AUDIO_STEP1;
+ regmap_write(regmap, MT8188_TOP_AXI_PROT_EN_2_CLR, mask);
+
+ ret = regmap_read_poll_timeout(regmap, MT8188_TOP_AXI_PROT_EN_2_STA,
+ val, !(val & mask),
+ MT8188_DELAY_US, MT8188_TIMEOUT_US);
+ return ret;
+}
+
static int mt8188_afe_pcm_dev_probe(struct platform_device *pdev)
{
struct mtk_base_afe *afe;
struct mt8188_afe_private *afe_priv;
struct device *dev;
struct reset_control *rstc;
+ struct regmap *infra_ao;
int i, irq_id, ret;
ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(33));
@@ -3163,18 +3220,37 @@ static int mt8188_afe_pcm_dev_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(afe->base_addr),
"AFE base_addr not found\n");
+ infra_ao = syscon_regmap_lookup_by_phandle(dev->of_node,
+ "mediatek,infracfg");
+ if (IS_ERR(infra_ao))
+ return dev_err_probe(dev, PTR_ERR(infra_ao),
+ "%s() Cannot find infra_ao controller\n",
+ __func__);
+
/* reset controller to reset audio regs before regmap cache */
rstc = devm_reset_control_get_exclusive(dev, "audiosys");
if (IS_ERR(rstc))
return dev_err_probe(dev, PTR_ERR(rstc),
"could not get audiosys reset\n");
+ ret = bus_protect_enable(infra_ao);
+ if (ret) {
+ dev_err(dev, "bus_protect_enable failed\n");
+ return ret;
+ }
+
ret = reset_control_reset(rstc);
if (ret) {
dev_err(dev, "failed to trigger audio reset:%d\n", ret);
return ret;
}
+ ret = bus_protect_disable(infra_ao);
+ if (ret) {
+ dev_err(dev, "bus_protect_disable failed\n");
+ return ret;
+ }
+
/* initial audio related clock */
ret = mt8188_afe_init_clock(afe);
if (ret)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/7] ASoC: mediatek: mt8188: refine APLL control
From: Trevor Wu @ 2023-04-21 10:09 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20230421100905.28045-1-trevor.wu@mediatek.com>
Currently, APLL is only used in ETDM module, so APLL and APLL tuner
don't need to be enabled when AFE is used. Integrate APLL control into
ETDM DAPM routes, so that APLL can be enabled when it is really required.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
---
sound/soc/mediatek/mt8188/mt8188-afe-clk.c | 138 ++++++++++++++++----
sound/soc/mediatek/mt8188/mt8188-afe-clk.h | 11 ++
sound/soc/mediatek/mt8188/mt8188-dai-etdm.c | 115 ++++++++++++++++
3 files changed, 241 insertions(+), 23 deletions(-)
diff --git a/sound/soc/mediatek/mt8188/mt8188-afe-clk.c b/sound/soc/mediatek/mt8188/mt8188-afe-clk.c
index 743d6a162cb9..02411be93900 100644
--- a/sound/soc/mediatek/mt8188/mt8188-afe-clk.c
+++ b/sound/soc/mediatek/mt8188/mt8188-afe-clk.c
@@ -24,6 +24,7 @@ static const char *aud_clks[MT8188_CLK_NUM] = {
[MT8188_CLK_APMIXED_APLL2] = "apll2",
/* divider */
+ [MT8188_CLK_TOP_APLL1_D4] = "apll1_d4",
[MT8188_CLK_TOP_APLL12_DIV0] = "apll12_div0",
[MT8188_CLK_TOP_APLL12_DIV1] = "apll12_div1",
[MT8188_CLK_TOP_APLL12_DIV2] = "apll12_div2",
@@ -378,6 +379,19 @@ int mt8188_afe_get_default_mclk_source_by_rate(int rate)
MT8188_MCK_SEL_APLL1 : MT8188_MCK_SEL_APLL2;
}
+int mt8188_get_apll_by_rate(struct mtk_base_afe *afe, int rate)
+{
+ return ((rate % 8000) == 0) ? MT8188_AUD_PLL1 : MT8188_AUD_PLL2;
+}
+
+int mt8188_get_apll_by_name(struct mtk_base_afe *afe, const char *name)
+{
+ if (strcmp(name, APLL1_W_NAME) == 0)
+ return MT8188_AUD_PLL1;
+
+ return MT8188_AUD_PLL2;
+}
+
int mt8188_afe_init_clock(struct mtk_base_afe *afe)
{
struct mt8188_afe_private *afe_priv = afe->platform_priv;
@@ -477,8 +491,8 @@ int mt8188_afe_set_clk_parent(struct mtk_base_afe *afe, struct clk *clk,
if (clk && parent) {
ret = clk_set_parent(clk, parent);
if (ret) {
- dev_dbg(afe->dev, "%s(), failed to set clk parent\n",
- __func__);
+ dev_dbg(afe->dev, "%s(), failed to set clk parent %d\n",
+ __func__, ret);
return ret;
}
}
@@ -605,54 +619,132 @@ static int mt8188_afe_disable_afe_on(struct mtk_base_afe *afe)
return 0;
}
-static int mt8188_afe_enable_timing_sys(struct mtk_base_afe *afe)
+static int mt8188_afe_enable_a1sys(struct mtk_base_afe *afe)
{
struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ int ret;
- mt8188_afe_enable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A1SYS]);
- mt8188_afe_enable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A2SYS]);
+ ret = mt8188_afe_enable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A1SYS]);
+ if (ret)
+ return ret;
- mt8188_afe_enable_top_cg(afe, MT8188_TOP_CG_A1SYS_TIMING);
- mt8188_afe_enable_top_cg(afe, MT8188_TOP_CG_A2SYS_TIMING);
- mt8188_afe_enable_top_cg(afe, MT8188_TOP_CG_26M_TIMING);
+ return mt8188_afe_enable_top_cg(afe, MT8188_TOP_CG_A1SYS_TIMING);
+}
+
+static int mt8188_afe_disable_a1sys(struct mtk_base_afe *afe)
+{
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ mt8188_afe_disable_top_cg(afe, MT8188_TOP_CG_A1SYS_TIMING);
+ mt8188_afe_disable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A1SYS]);
return 0;
}
-static int mt8188_afe_disable_timing_sys(struct mtk_base_afe *afe)
+static int mt8188_afe_enable_a2sys(struct mtk_base_afe *afe)
{
struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ int ret;
- mt8188_afe_disable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A1SYS]);
- mt8188_afe_disable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A2SYS]);
+ ret = mt8188_afe_enable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A2SYS]);
+ if (ret)
+ return ret;
- mt8188_afe_disable_top_cg(afe, MT8188_TOP_CG_26M_TIMING);
- mt8188_afe_disable_top_cg(afe, MT8188_TOP_CG_A2SYS_TIMING);
- mt8188_afe_disable_top_cg(afe, MT8188_TOP_CG_A1SYS_TIMING);
+ return mt8188_afe_enable_top_cg(afe, MT8188_TOP_CG_A2SYS_TIMING);
+}
+
+static int mt8188_afe_disable_a2sys(struct mtk_base_afe *afe)
+{
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ mt8188_afe_disable_top_cg(afe, MT8188_TOP_CG_A2SYS_TIMING);
+ mt8188_afe_disable_clk(afe, afe_priv->clk[MT8188_CLK_AUD_A2SYS]);
return 0;
}
-int mt8188_afe_enable_main_clock(struct mtk_base_afe *afe)
+int mt8188_apll1_enable(struct mtk_base_afe *afe)
{
- mt8188_afe_enable_timing_sys(afe);
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+ int ret;
- mt8188_afe_enable_afe_on(afe);
+ ret = mt8188_afe_enable_clk(afe, afe_priv->clk[MT8188_CLK_TOP_APLL1_D4]);
+ if (ret)
+ return ret;
+
+ ret = mt8188_afe_set_clk_parent(afe, afe_priv->clk[MT8188_CLK_TOP_A1SYS_HP_SEL],
+ afe_priv->clk[MT8188_CLK_TOP_APLL1_D4]);
+ if (ret)
+ goto err_clk_parent;
- mt8188_afe_enable_apll_tuner(afe, MT8188_AUD_PLL1);
- mt8188_afe_enable_apll_tuner(afe, MT8188_AUD_PLL2);
+ ret = mt8188_afe_enable_apll_tuner(afe, MT8188_AUD_PLL1);
+ if (ret)
+ goto err_apll_tuner;
+
+ ret = mt8188_afe_enable_a1sys(afe);
+ if (ret)
+ goto err_a1sys;
return 0;
+
+err_a1sys:
+ mt8188_afe_disable_apll_tuner(afe, MT8188_AUD_PLL1);
+err_apll_tuner:
+ mt8188_afe_set_clk_parent(afe, afe_priv->clk[MT8188_CLK_TOP_A1SYS_HP_SEL],
+ afe_priv->clk[MT8188_CLK_XTAL_26M]);
+err_clk_parent:
+ mt8188_afe_disable_clk(afe, afe_priv->clk[MT8188_CLK_TOP_APLL1_D4]);
+
+ return ret;
}
-int mt8188_afe_disable_main_clock(struct mtk_base_afe *afe)
+int mt8188_apll1_disable(struct mtk_base_afe *afe)
{
- mt8188_afe_disable_apll_tuner(afe, MT8188_AUD_PLL2);
+ struct mt8188_afe_private *afe_priv = afe->platform_priv;
+
+ mt8188_afe_disable_a1sys(afe);
mt8188_afe_disable_apll_tuner(afe, MT8188_AUD_PLL1);
+ mt8188_afe_set_clk_parent(afe, afe_priv->clk[MT8188_CLK_TOP_A1SYS_HP_SEL],
+ afe_priv->clk[MT8188_CLK_XTAL_26M]);
+ mt8188_afe_disable_clk(afe, afe_priv->clk[MT8188_CLK_TOP_APLL1_D4]);
- mt8188_afe_disable_afe_on(afe);
+ return 0;
+}
+
+int mt8188_apll2_enable(struct mtk_base_afe *afe)
+{
+ int ret;
- mt8188_afe_disable_timing_sys(afe);
+ ret = mt8188_afe_enable_apll_tuner(afe, MT8188_AUD_PLL2);
+ if (ret)
+ return ret;
+ ret = mt8188_afe_enable_a2sys(afe);
+ if (ret)
+ goto err_a2sys;
+
+ return 0;
+err_a2sys:
+ mt8188_afe_disable_apll_tuner(afe, MT8188_AUD_PLL2);
+
+ return ret;
+}
+
+int mt8188_apll2_disable(struct mtk_base_afe *afe)
+{
+ mt8188_afe_disable_a2sys(afe);
+ mt8188_afe_disable_apll_tuner(afe, MT8188_AUD_PLL2);
+ return 0;
+}
+
+int mt8188_afe_enable_main_clock(struct mtk_base_afe *afe)
+{
+ mt8188_afe_enable_top_cg(afe, MT8188_TOP_CG_26M_TIMING);
+ mt8188_afe_enable_afe_on(afe);
+ return 0;
+}
+
+int mt8188_afe_disable_main_clock(struct mtk_base_afe *afe)
+{
+ mt8188_afe_disable_afe_on(afe);
+ mt8188_afe_disable_top_cg(afe, MT8188_TOP_CG_26M_TIMING);
return 0;
}
diff --git a/sound/soc/mediatek/mt8188/mt8188-afe-clk.h b/sound/soc/mediatek/mt8188/mt8188-afe-clk.h
index 084fdfb1d877..04cb476f0bcb 100644
--- a/sound/soc/mediatek/mt8188/mt8188-afe-clk.h
+++ b/sound/soc/mediatek/mt8188/mt8188-afe-clk.h
@@ -11,6 +11,10 @@
#ifndef _MT8188_AFE_CLK_H_
#define _MT8188_AFE_CLK_H_
+/* APLL */
+#define APLL1_W_NAME "APLL1"
+#define APLL2_W_NAME "APLL2"
+
enum {
/* xtal */
MT8188_CLK_XTAL_26M,
@@ -18,6 +22,7 @@ enum {
MT8188_CLK_APMIXED_APLL1,
MT8188_CLK_APMIXED_APLL2,
/* divider */
+ MT8188_CLK_TOP_APLL1_D4,
MT8188_CLK_TOP_APLL12_DIV0,
MT8188_CLK_TOP_APLL12_DIV1,
MT8188_CLK_TOP_APLL12_DIV2,
@@ -99,6 +104,8 @@ struct mtk_base_afe;
int mt8188_afe_get_mclk_source_clk_id(int sel);
int mt8188_afe_get_mclk_source_rate(struct mtk_base_afe *afe, int apll);
int mt8188_afe_get_default_mclk_source_by_rate(int rate);
+int mt8188_get_apll_by_rate(struct mtk_base_afe *afe, int rate);
+int mt8188_get_apll_by_name(struct mtk_base_afe *afe, const char *name);
int mt8188_afe_init_clock(struct mtk_base_afe *afe);
void mt8188_afe_deinit_clock(void *priv);
int mt8188_afe_enable_clk(struct mtk_base_afe *afe, struct clk *clk);
@@ -107,6 +114,10 @@ int mt8188_afe_set_clk_rate(struct mtk_base_afe *afe, struct clk *clk,
unsigned int rate);
int mt8188_afe_set_clk_parent(struct mtk_base_afe *afe, struct clk *clk,
struct clk *parent);
+int mt8188_apll1_enable(struct mtk_base_afe *afe);
+int mt8188_apll1_disable(struct mtk_base_afe *afe);
+int mt8188_apll2_enable(struct mtk_base_afe *afe);
+int mt8188_apll2_disable(struct mtk_base_afe *afe);
int mt8188_afe_enable_main_clock(struct mtk_base_afe *afe);
int mt8188_afe_disable_main_clock(struct mtk_base_afe *afe);
int mt8188_afe_enable_reg_rw_clk(struct mtk_base_afe *afe);
diff --git a/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c b/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
index fd6e39a1e4c1..16440dd0a89c 100644
--- a/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
+++ b/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
@@ -22,6 +22,7 @@
#define ENUM_TO_STR(x) #x
enum {
+ SUPPLY_SEQ_APLL,
SUPPLY_SEQ_ETDM_MCLK,
SUPPLY_SEQ_ETDM_CG,
SUPPLY_SEQ_DPTX_EN,
@@ -95,6 +96,7 @@ struct mtk_dai_etdm_priv {
bool slave_mode;
bool lrck_inv;
bool bck_inv;
+ unsigned int rate;
unsigned int format;
unsigned int slots;
unsigned int lrck_width;
@@ -360,6 +362,10 @@ static int get_etdm_id_by_name(struct mtk_base_afe *afe,
return MT8188_AFE_IO_ETDM1_OUT;
else if (!strncmp(name, "ETDM2_OUT", strlen("ETDM2_OUT")))
return MT8188_AFE_IO_ETDM2_OUT;
+ else if (!strncmp(name, "ETDM3_OUT", strlen("ETDM3_OUT")))
+ return MT8188_AFE_IO_ETDM3_OUT;
+ else if (!strncmp(name, "DPTX", strlen("DPTX")))
+ return MT8188_AFE_IO_ETDM3_OUT;
else
return -EINVAL;
}
@@ -445,6 +451,44 @@ static int mtk_dai_etdm_disable_mclk(struct mtk_base_afe *afe, int dai_id)
return 0;
}
+static int mtk_afe_etdm_apll_connect(struct snd_soc_dapm_widget *source,
+ struct snd_soc_dapm_widget *sink)
+{
+ struct snd_soc_dapm_widget *w = sink;
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+ struct mtk_dai_etdm_priv *etdm_priv;
+ int cur_apll;
+ int need_apll;
+
+ etdm_priv = get_etdm_priv_by_name(afe, w->name);
+ if (!etdm_priv) {
+ dev_dbg(afe->dev, "etdm_priv == NULL\n");
+ return 0;
+ }
+
+ cur_apll = mt8188_get_apll_by_name(afe, source->name);
+ need_apll = mt8188_get_apll_by_rate(afe, etdm_priv->rate);
+
+ return (need_apll == cur_apll) ? 1 : 0;
+}
+
+static int mtk_afe_mclk_apll_connect(struct snd_soc_dapm_widget *source,
+ struct snd_soc_dapm_widget *sink)
+{
+ struct snd_soc_dapm_widget *w = sink;
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+ struct mtk_dai_etdm_priv *etdm_priv;
+ int cur_apll;
+
+ etdm_priv = get_etdm_priv_by_name(afe, w->name);
+
+ cur_apll = mt8188_get_apll_by_name(afe, source->name);
+
+ return (etdm_priv->mclk_apll == cur_apll) ? 1 : 0;
+}
+
static int mtk_etdm_mclk_connect(struct snd_soc_dapm_widget *source,
struct snd_soc_dapm_widget *sink)
{
@@ -520,6 +564,36 @@ static int mtk_etdm_cowork_connect(struct snd_soc_dapm_widget *source,
return 0;
}
+static int mtk_apll_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
+ struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
+
+ dev_dbg(cmpnt->dev, "%s(), name %s, event 0x%x\n",
+ __func__, w->name, event);
+
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ if (strcmp(w->name, APLL1_W_NAME) == 0)
+ mt8188_apll1_enable(afe);
+ else
+ mt8188_apll2_enable(afe);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ if (strcmp(w->name, APLL1_W_NAME) == 0)
+ mt8188_apll1_disable(afe);
+ else
+ mt8188_apll2_disable(afe);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static int mtk_etdm_mclk_event(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol,
int event)
@@ -1231,6 +1305,16 @@ static const struct snd_soc_dapm_widget mtk_dai_etdm_widgets[] = {
SND_SOC_DAPM_SUPPLY_S("DPTX_EN", SUPPLY_SEQ_DPTX_EN,
AFE_DPTX_CON, AFE_DPTX_CON_ON_SHIFT, 0, NULL, 0),
+ /* apll */
+ SND_SOC_DAPM_SUPPLY_S(APLL1_W_NAME, SUPPLY_SEQ_APLL,
+ SND_SOC_NOPM, 0, 0,
+ mtk_apll_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SUPPLY_S(APLL2_W_NAME, SUPPLY_SEQ_APLL,
+ SND_SOC_NOPM, 0, 0,
+ mtk_apll_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
+
SND_SOC_DAPM_INPUT("ETDM_INPUT"),
SND_SOC_DAPM_OUTPUT("ETDM_OUTPUT"),
};
@@ -1259,6 +1343,21 @@ static const struct snd_soc_dapm_route mtk_dai_etdm_routes[] = {
{"DPTX", NULL, "DPTX_MCLK"},
+ {"ETDM1_IN_MCLK", NULL, APLL1_W_NAME, mtk_afe_mclk_apll_connect},
+ {"ETDM1_IN_MCLK", NULL, APLL2_W_NAME, mtk_afe_mclk_apll_connect},
+
+ {"ETDM2_IN_MCLK", NULL, APLL1_W_NAME, mtk_afe_mclk_apll_connect},
+ {"ETDM2_IN_MCLK", NULL, APLL2_W_NAME, mtk_afe_mclk_apll_connect},
+
+ {"ETDM1_OUT_MCLK", NULL, APLL1_W_NAME, mtk_afe_mclk_apll_connect},
+ {"ETDM1_OUT_MCLK", NULL, APLL2_W_NAME, mtk_afe_mclk_apll_connect},
+
+ {"ETDM2_OUT_MCLK", NULL, APLL1_W_NAME, mtk_afe_mclk_apll_connect},
+ {"ETDM2_OUT_MCLK", NULL, APLL2_W_NAME, mtk_afe_mclk_apll_connect},
+
+ {"DPTX_MCLK", NULL, APLL1_W_NAME, mtk_afe_mclk_apll_connect},
+ {"DPTX_MCLK", NULL, APLL2_W_NAME, mtk_afe_mclk_apll_connect},
+
/* cg */
{"ETDM1_IN", NULL, "ETDM1_IN_CG"},
{"ETDM1_IN", NULL, "ETDM2_IN_CG", mtk_etdm_cowork_connect},
@@ -1308,6 +1407,21 @@ static const struct snd_soc_dapm_route mtk_dai_etdm_routes[] = {
{"DPTX", NULL, "ETDM3_OUT_EN"},
{"DPTX", NULL, "DPTX_EN"},
+ {"ETDM1_IN_EN", NULL, APLL1_W_NAME, mtk_afe_etdm_apll_connect},
+ {"ETDM1_IN_EN", NULL, APLL2_W_NAME, mtk_afe_etdm_apll_connect},
+
+ {"ETDM2_IN_EN", NULL, APLL1_W_NAME, mtk_afe_etdm_apll_connect},
+ {"ETDM2_IN_EN", NULL, APLL2_W_NAME, mtk_afe_etdm_apll_connect},
+
+ {"ETDM1_OUT_EN", NULL, APLL1_W_NAME, mtk_afe_etdm_apll_connect},
+ {"ETDM1_OUT_EN", NULL, APLL2_W_NAME, mtk_afe_etdm_apll_connect},
+
+ {"ETDM2_OUT_EN", NULL, APLL1_W_NAME, mtk_afe_etdm_apll_connect},
+ {"ETDM2_OUT_EN", NULL, APLL2_W_NAME, mtk_afe_etdm_apll_connect},
+
+ {"ETDM3_OUT_EN", NULL, APLL1_W_NAME, mtk_afe_etdm_apll_connect},
+ {"ETDM3_OUT_EN", NULL, APLL2_W_NAME, mtk_afe_etdm_apll_connect},
+
{"I012", NULL, "ETDM2_IN"},
{"I013", NULL, "ETDM2_IN"},
{"I014", NULL, "ETDM2_IN"},
@@ -2004,6 +2118,7 @@ static int mtk_dai_etdm_configure(struct mtk_base_afe *afe,
return -EINVAL;
etdm_data = afe_priv->dai_priv[dai_id];
slave_mode = etdm_data->slave_mode;
+ etdm_data->rate = rate;
ret = get_etdm_reg(dai_id, &etdm_reg);
if (ret < 0)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/7] ASoC: mediatek: mt8188: remove supply AUDIO_HIRES
From: Trevor Wu @ 2023-04-21 10:08 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20230421100905.28045-1-trevor.wu@mediatek.com>
AUDIO_HIRES is not required in MT8188. Because top_audio_h is disabled
when hires clock is not used, set_parent is a redundant operation.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
sound/soc/mediatek/mt8188/mt8188-dai-adda.c | 37 ---------------------
1 file changed, 37 deletions(-)
diff --git a/sound/soc/mediatek/mt8188/mt8188-dai-adda.c b/sound/soc/mediatek/mt8188/mt8188-dai-adda.c
index d71696901553..fed9f927e623 100644
--- a/sound/soc/mediatek/mt8188/mt8188-dai-adda.c
+++ b/sound/soc/mediatek/mt8188/mt8188-dai-adda.c
@@ -18,7 +18,6 @@
#define ADDA_HIRES_THRES 48000
enum {
- SUPPLY_SEQ_CLOCK_SEL,
SUPPLY_SEQ_ADDA_DL_ON,
SUPPLY_SEQ_ADDA_MTKAIF_CFG,
SUPPLY_SEQ_ADDA_UL_ON,
@@ -242,34 +241,6 @@ static int mtk_adda_ul_event(struct snd_soc_dapm_widget *w,
return 0;
}
-static int mtk_audio_hires_event(struct snd_soc_dapm_widget *w,
- struct snd_kcontrol *kcontrol,
- int event)
-{
- struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm);
- struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt);
- struct mt8188_afe_private *afe_priv = afe->platform_priv;
- struct clk *clk = afe_priv->clk[MT8188_CLK_TOP_AUDIO_H_SEL];
- struct clk *clk_parent;
-
- dev_dbg(afe->dev, "%s(), name %s, event 0x%x\n",
- __func__, w->name, event);
-
- switch (event) {
- case SND_SOC_DAPM_PRE_PMU:
- clk_parent = afe_priv->clk[MT8188_CLK_APMIXED_APLL1];
- break;
- case SND_SOC_DAPM_POST_PMD:
- clk_parent = afe_priv->clk[MT8188_CLK_XTAL_26M];
- break;
- default:
- return 0;
- }
- mt8188_afe_set_clk_parent(afe, clk, clk_parent);
-
- return 0;
-}
-
static int mtk_afe_adc_hires_connect(struct snd_soc_dapm_widget *source,
struct snd_soc_dapm_widget *sink)
{
@@ -364,12 +335,6 @@ static const struct snd_soc_dapm_widget mtk_dai_adda_widgets[] = {
mtk_adda_ul_event,
SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
- SND_SOC_DAPM_SUPPLY_S("AUDIO_HIRES", SUPPLY_SEQ_CLOCK_SEL,
- SND_SOC_NOPM,
- 0, 0,
- mtk_audio_hires_event,
- SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
-
SND_SOC_DAPM_SUPPLY_S("ADDA_MTKAIF_CFG", SUPPLY_SEQ_ADDA_MTKAIF_CFG,
SND_SOC_NOPM,
0, 0,
@@ -397,7 +362,6 @@ static const struct snd_soc_dapm_route mtk_dai_adda_routes[] = {
{"ADDA Capture", NULL, "ADDA_MTKAIF_CFG"},
{"ADDA Capture", NULL, "aud_adc"},
{"ADDA Capture", NULL, "aud_adc_hires", mtk_afe_adc_hires_connect},
- {"aud_adc_hires", NULL, "AUDIO_HIRES"},
{"I168", NULL, "ADDA Capture"},
{"I169", NULL, "ADDA Capture"},
@@ -406,7 +370,6 @@ static const struct snd_soc_dapm_route mtk_dai_adda_routes[] = {
{"ADDA Playback", NULL, "ADDA Playback Enable"},
{"ADDA Playback", NULL, "aud_dac"},
{"ADDA Playback", NULL, "aud_dac_hires", mtk_afe_dac_hires_connect},
- {"aud_dac_hires", NULL, "AUDIO_HIRES"},
{"DL_GAIN", NULL, "O176"},
{"DL_GAIN", NULL, "O177"},
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V5 2/3] soc: qcom: boot_stat: Add Driver Support for Boot Stats
From: Bryan O'Donoghue @ 2023-04-21 10:02 UTC (permalink / raw)
To: Souradeep Chowdhury, Andy Gross, Konrad Dybcio,
Krzysztof Kozlowski, Bjorn Andersson, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, devicetree,
Sibi Sankar, Rajendra Nayak
In-Reply-To: <142bfd034c12c245cda9f1dee20a05188b63494d.1681799201.git.quic_schowdhu@quicinc.com>
On 18/04/2023 07:46, Souradeep Chowdhury wrote:
> All of Qualcomm's proprietary Android boot-loaders capture boot time
> stats, like the time when the bootloader started execution and at what
> point the bootloader handed over control to the kernel etc. in the IMEM
> region. This information is captured in a specific format by this driver
> by mapping a structure to the IMEM memory region and then accessing the
> members of the structure to show the information within debugfs file.
> This information is useful in verifying if the existing boot KPIs have
> regressed or not. The information is shown in milliseconds, a sample
> log from sm8450(waipio) device is as follows:-
>
> /sys/kernel/debug/146aa6b0.boot_stats # cat abl_time
> 17898 ms
> /sys/kernel/debug/146aa6b0.boot_stats # cat pre_abl_time
> 2879 ms
>
> The Module Power Manager(MPM) sleep counter starts ticking at the PBL
> stage and the timestamp generated by the sleep counter is logged by
> the Qualcomm proprietary bootloader(ABL) at two points-> First when it
> starts execution which is logged here as "pre_abl_time" and the second
> when it is about to load the kernel logged as "abl_time". Documentation
> details are also added in Documentation/ABI/testing/debugfs-driver-bootstat
>
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> ---
> Documentation/ABI/testing/debugfs-driver-bootstat | 17 ++++
> drivers/soc/qcom/Kconfig | 9 ++
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/boot_stats.c | 101 ++++++++++++++++++++++
> 4 files changed, 128 insertions(+)
> create mode 100644 Documentation/ABI/testing/debugfs-driver-bootstat
> create mode 100644 drivers/soc/qcom/boot_stats.c
>
> diff --git a/Documentation/ABI/testing/debugfs-driver-bootstat b/Documentation/ABI/testing/debugfs-driver-bootstat
> new file mode 100644
> index 0000000..2543029
> --- /dev/null
> +++ b/Documentation/ABI/testing/debugfs-driver-bootstat
> @@ -0,0 +1,17 @@
> +What: /sys/kernel/debug/...stats/pre_abl_time
> +Date: April 2023
> +Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> +Description:
> + This file is used to read the KPI value pre abl time.
> + It shows the time in milliseconds from the starting
> + point of PBL to the point when the control shifted
> + to ABL(Qualcomm proprietary bootloader).
> +
> +What: /sys/kernel/debug/...stats/abl_time
> +Date: April 2023
> +Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> +Description:
> + This file is used to read the KPI value abl time.
> + It show the duration in milliseconds from the
> + time control switched to ABL to the point when
> + the linux kernel started getting loaded.
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index a8f2830..0d2cbd3 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -16,6 +16,15 @@ config QCOM_AOSS_QMP
> subsystems as well as controlling the debug clocks exposed by the Always On
> Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
>
> +config QCOM_BOOTSTAT
> + tristate "Qualcomm Technologies, Boot Stat driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + help
> + This option enables driver support for boot stats. Boot stat driver logs
> + the kernel bootloader information by accessing the imem region. These
> + information are exposed in the form of debugfs files. This is used to
> + determine if there is any regression in boot timings.
> +
> config QCOM_COMMAND_DB
> tristate "Qualcomm Command DB"
> depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index 6e88da8..bdaa41a 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> CFLAGS_rpmh-rsc.o := -I$(src)
> obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
> +obj-$(CONFIG_QCOM_BOOTSTAT) += boot_stats.o
> obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
> obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
> obj-$(CONFIG_QCOM_CPR) += cpr.o
> diff --git a/drivers/soc/qcom/boot_stats.c b/drivers/soc/qcom/boot_stats.c
> new file mode 100644
> index 0000000..7ae002b
> --- /dev/null
> +++ b/drivers/soc/qcom/boot_stats.c
> @@ -0,0 +1,101 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2013-2019, 2021 The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/debugfs.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +#define TO_MS(timestamp) ((timestamp * 1000) / 32768)
Is this related to the sleep_clk, if not, what is the refrence clock ?
Is this value constant across different SoCs i.e. will this run and
produce meaningful results on an msm8916 ?
---
bod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] ARM: dts: s5pv210: add dummy 5V regulator for backlight on SMDKv210
From: Krzysztof Kozlowski @ 2023-04-21 9:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Alim Akhtar, devicetree,
linux-arm-kernel, linux-samsung-soc, linux-kernel
Cc: replicant, phone-devel, ~postmarketos/upstreaming,
Jonathan Bakker, Pawel Chmiel, Krzysztof Kozlowski
In-Reply-To: <20230421095721.31857-1-krzysztof.kozlowski@linaro.org>
Backlight is supplied by DC5V regulator. The DTS has no PMIC node, so
just add a regulator-fixed to solve it and fix dtbs_check warning:
s5pv210-smdkv210.dtb: backlight: 'power-supply' is a required property
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
arch/arm/boot/dts/s5pv210-smdkv210.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/s5pv210-smdkv210.dts b/arch/arm/boot/dts/s5pv210-smdkv210.dts
index fbae768d65e2..6e26c67e0a26 100644
--- a/arch/arm/boot/dts/s5pv210-smdkv210.dts
+++ b/arch/arm/boot/dts/s5pv210-smdkv210.dts
@@ -55,6 +55,14 @@ backlight {
default-brightness-level = <6>;
pinctrl-names = "default";
pinctrl-0 = <&pwm3_out>;
+ power-supply = <&dc5v_reg>;
+ };
+
+ dc5v_reg: regulator-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "DC5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
};
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: s5pv210: align USB node name with bindings
From: Krzysztof Kozlowski @ 2023-04-21 9:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Alim Akhtar, devicetree,
linux-arm-kernel, linux-samsung-soc, linux-kernel
Cc: replicant, phone-devel, ~postmarketos/upstreaming,
Jonathan Bakker, Pawel Chmiel, Krzysztof Kozlowski
In-Reply-To: <20230421095721.31857-1-krzysztof.kozlowski@linaro.org>
Bindings expect USB HSOTG controller node to be named "usb":
s5pv210-torbreck.dtb: hsotg@ec000000: $nodename:0: 'hsotg@ec000000' does not match '^usb(@.*)?'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
arch/arm/boot/dts/s5pv210.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index cbc108217483..fbe7f3d17f41 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -401,7 +401,7 @@ sdhci3: mmc@eb300000 {
status = "disabled";
};
- hsotg: hsotg@ec000000 {
+ hsotg: usb@ec000000 {
compatible = "samsung,s3c6400-hsotg";
reg = <0xec000000 0x20000>;
interrupt-parent = <&vic1>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: s5pv210: re-order MFC clock names to match Exynos and bindings
From: Krzysztof Kozlowski @ 2023-04-21 9:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Alim Akhtar, devicetree,
linux-arm-kernel, linux-samsung-soc, linux-kernel
Cc: replicant, phone-devel, ~postmarketos/upstreaming,
Jonathan Bakker, Pawel Chmiel, Krzysztof Kozlowski
In-Reply-To: <20230421095721.31857-1-krzysztof.kozlowski@linaro.org>
Align the order of two MFC clocks with Exynos4 DTS and MFC bindings
Link: https://lore.kernel.org/r/20230328114729.61436-1-aakarsh.jain@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
arch/arm/boot/dts/s5pv210.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index fbe7f3d17f41..d9436bbf77c8 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -452,8 +452,8 @@ mfc: codec@f1700000 {
reg = <0xf1700000 0x10000>;
interrupt-parent = <&vic2>;
interrupts = <14>;
- clocks = <&clocks DOUT_MFC>, <&clocks CLK_MFC>;
- clock-names = "sclk_mfc", "mfc";
+ clocks = <&clocks CLK_MFC>, <&clocks DOUT_MFC>;
+ clock-names = "mfc", "sclk_mfc";
};
vic0: interrupt-controller@f2000000 {
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: s5pv210: align pin configuration nodes with bindings
From: Krzysztof Kozlowski @ 2023-04-21 9:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Alim Akhtar, devicetree,
linux-arm-kernel, linux-samsung-soc, linux-kernel
Cc: replicant, phone-devel, ~postmarketos/upstreaming,
Jonathan Bakker, Pawel Chmiel, Krzysztof Kozlowski
Bindings expect that pins in initial and sleep states nodes end with
'-pin':
s5pv210-fascinate4g.dtb: pinctrl@e0200000: sleep-state: 'gpa0-0', ...
'mp07-7' do not match any of the regexes: '^(pin-[a-z0-9-]+|[a-z0-9-]+-pin)$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
arch/arm/boot/dts/s5pv210-pinctrl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s5pv210-pinctrl.dtsi b/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
index 6d6daef9fb7a..ae0b4a423746 100644
--- a/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
@@ -19,7 +19,7 @@
#include "s5pv210-pinctrl.h"
#define PIN_SLP(_pin, _mode, _pull) \
- _pin { \
+ pin- ## _pin { \
samsung,pins = #_pin; \
samsung,pin-con-pdn = <S5PV210_PIN_PDN_ ##_mode>; \
samsung,pin-pud-pdn = <S5PV210_PIN_PULL_ ##_pull>; \
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver
From: Cristian Marussi @ 2023-04-21 9:54 UTC (permalink / raw)
To: Oleksii Moisieiev
Cc: Peng Fan, sudeep.holla@arm.com, Linus Walleij,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
michal.simek@amd.com, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com
In-Reply-To: <3041c92c-385a-00cd-87cd-d8b906dcd84c@epam.com>
On Fri, Apr 21, 2023 at 09:48:33AM +0000, Oleksii Moisieiev wrote:
> Hi Cristian,
>
Hi,
> On 21.04.23 12:30, Cristian Marussi wrote:
> > On Fri, Apr 21, 2023 at 08:40:47AM +0000, Oleksii Moisieiev wrote:
> >> Hi Peng Fan,
> >>
> >> On 17.04.23 05:55, Peng Fan wrote:
> >>>
> >>> On 4/13/2023 6:04 AM, Cristian Marussi wrote:
> >>>> On Fri, Apr 07, 2023 at 10:18:27AM +0000, Oleksii Moisieiev wrote:
> >>>>> Implementation of the SCMI client driver, which implements
> >>>>> PINCTRL_PROTOCOL. This protocol has ID 19 and is described
> >>>>> in the latest DEN0056 document.
> >>>> Hi,
> >>>>
> >>>>> This protocol is part of the feature that was designed to
> >>>>> separate the pinctrl subsystem from the SCP firmware.
> >>>>> The idea is to separate communication of the pin control
> >>>>> subsystem with the hardware to SCP firmware
> >>>>> (or a similar system, such as ATF), which provides an interface
> >>>>> to give the OS ability to control the hardware through SCMI protocol.
> >>>>> This is a generic driver that implements SCMI protocol,
> >>>>> independent of the platform type.
> >>>>>
> >>>>> DEN0056 document:
> >>>>> https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!y2hR3PEGGxiPjVeXBcgGyV03DPDhzgUKR0uHvsTpiafKgBar8Egc6oOOs-IkFIquhSf-qBzltqEMyzRZHq8eC4g$
> >>>>> [developer[.]arm[.]com]
> >>>>>
> >>>> No need to specify all of this in the commit message, just a note that
> >>>> you are adding a new SCMIv3.2 Pincontrol protocol, highlighting anything
> >>>> that has been left out in this patch (if any) will be enough.
> >>> Is it possible to extend the spec to support multilple uint32_t for PIN
> >>> CONFIG SET?
> >>>
> >>> With only one uint32_t could not satisfy i.MX requirement.
> >>>
> >>> Thanks,
> >>> Peng.
> >>>
> >> IIUC you are expecting to have an ability to set some kind of array of
> >> uint32_t config values to some specific ConfigType?
> >>
> >> I'm not sure if it's supported by pintctrl subsystem right now. I was
> >> unable to find an example in the existing device-tree pinctrl bindings.
> >> This makes me think that this kind of binding is OEM specific.
> >>
> >> Maybe it can be implemented by adding new IDs to OEM specific range
> >> (192-255) which is reserved for OEM specific units (See Table 23 of
> >> DEN0056E).
> >>
> > If I understood correctly the aim of Peng multi-valued request, I think
> > that even if Linux does not support using this kind of multiple valued
> > requests (as of now), if it is useful or required by some of the possibly
> > supported hardware, it should be described and allowed by the specification
> > and supported by the core SCMI protocol support at least, while the pinctrl
> > SCMI driver can ignore this and keep using a one-sized array protocol_ops
> > call internally (since it cannot do any different anyway as of now)
> >
> > IOW I dont think we should model too strictly the SCMI spec against only
> > what the Linux pinctrl subsystem support today, since Linux it is just
> > really only one of the possible SCMI agents and Linux implementation itself
> > can possibly change: it is better to model the spec on the HW requirements
> > or the possible usage patterns across all the possibly participating agents.
> >
> > As an example, for similar reasons, when the SCMI Voltage protocol was added
> > to the spec, at the very last minute, a change was made to the spec to allow
> > for negative voltages, even though the Linux regulator subsystem was not
> > and still is not supporting at all negative voltages as of now; so basically
> > the SCMI voltage protocol API now exposes a per-domain flag (negative_volts_allowed),
> > that allows any kind of voltage domain to be enumerated and handled at the SCMI
> > spec and core layer but that also allows any SCMI driver user, like the SCMI
> > Regulator driver, to decide on his own if negative voltages domains can be
> > supported: indeed the scmi-regulator driver just skips the initialization of
> > any voltage domain that is found to be describing negative voltages.
> >
> > Here is a bit different, it is more of an optimization in the call path
> > than an HW difference, but I would follow the same approach: with the
> > SCMI spec and the core SCMI stack (the protocol) that supports a multi-uint32
> > call as a general case, if useful for some scenarios, and instead the SCMI
> > pinctrl driver that just ignores this possibility and keep using a single-value
> > array anyway....then, it will be up to the guys leveraging this multi-valued
> > call to come up with a way to use it on their systems, possibly maybe contributing
> > back to upstream any needed modification if general enough
> > (not sure about the details of how this multi-vals operation should be...we'll have
> > to discuss that about the spec all together I think.)
> >
> > In any case, I would definitely NOT relegate such possibility to vendor space,
> > since it is something generic and, especially being just (as it seems to me) an
> > optimization on the call path at the end, it will just lead to uneeded duplication
> > of functionalities in the vendor implementation of stuff that it is already
> > very slightly differently supported by the standard.
> >
> > ...just my opinion anyway, I'll happily let other guys in this thread discuss and
> > decide about this :P
> >
> > Thanks,
> > Cristian
>
> That sounds reasonable for me, although I can't imagine the use case of
> multi-valued config values (most likely this is the problem of my
> imagination). So I'd appreciate if Peng Fan could provide us with some
> examples.
>
> From my standpoint - ConfigTypes are meant to be simple value because
> they are mostly related to the electronic properties. But I agree that
> protocol should be platform-agnostic.
>
> It will be great if Peng Fan could provide some examples, so we can
> think about the best solution.
>
All of the above blabbing of mine (:P) is based on the assumption that
Peng wants just to simply fit multiple type/value pairs requests, possibly
about the same pin, at once in one SCMI command payload, not that he wants to
push a type/val1/val2/val3.. like command....but I maybe wrong and I agree that
more use-case examples from Peng could be useful.
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver
From: Oleksii Moisieiev @ 2023-04-21 9:53 UTC (permalink / raw)
To: Cristian Marussi, Linus Walleij
Cc: Peng Fan, sudeep.holla@arm.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
michal.simek@amd.com, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com
In-Reply-To: <ZEJbxTzv6tlBkExS@e120937-lin>
Hi Cristian,
On 21.04.23 12:47, Cristian Marussi wrote:
> On Fri, Apr 21, 2023 at 11:28:38AM +0200, Linus Walleij wrote:
>> On Fri, Apr 21, 2023 at 10:40 AM Oleksii Moisieiev
>> <Oleksii_Moisieiev@epam.com> wrote:
>>> On 17.04.23 05:55, Peng Fan wrote:
>>>> On 4/13/2023 6:04 AM, Cristian Marussi wrote:
>>>> Is it possible to extend the spec to support multilple uint32_t for PIN
>>>> CONFIG SET?
>>>>
>>>> With only one uint32_t could not satisfy i.MX requirement.
>>>>
>>>> Thanks,
>>>> Peng.
>>>>
>>> IIUC you are expecting to have an ability to set some kind of array of
>>> uint32_t config values to some specific ConfigType?
>>>
>>> I'm not sure if it's supported by pintctrl subsystem right now. I was
>>> unable to find an example in the existing device-tree pinctrl bindings.
>>> This makes me think that this kind of binding is OEM specific.
>>>
>>> Maybe it can be implemented by adding new IDs to OEM specific range
>>> (192-255) which is reserved for OEM specific units (See Table 23 of
>>> DEN0056E).
> Hi Linus,
>
>> From a pinctrl point of view I do not understand this requirement.
>>
>> The pinctrl subsystem in the Linux kernel certainly does not support
>> an array of u32 for the pin config, we only support passing a single
>> u32 value along with the enumerator (config type), or well it is
>> actually 24 bits in Linux, the uppermost 8 bits is for the config type:
>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/pinctrl/pinconf-generic.h__;!!GF_29dbcQIUBPA!0kv3XDV9f6l7rFEw9QFccCFZcl8t0vXfh_76DD80uq_dI_znPtdt4CVU6mLCZA5bHpliIRnzkIady9IAUEeIP7AB7fwWXg$ [git[.]kernel[.]org]
>>
>> /*
>> * Helpful configuration macro to be used in tables etc.
>> */
>> #define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
>>
>> p = parameter (PIN_CONFIG_DRIVE_STRENGTH etc)
>> a = argument (value such as in mA)
>>
> My (possibly wrong) reasoning on the other reply, is based on the
> (possibly equally wrong :D) understanding that what Peng wants is just
> the possibility at the spec and the SCMI protocol layer (exposed in
> protocol operations) to issue PINCTRL_SET requests containing optionally
> an array of multiple ConfigType/Value pairs (which is anyway not supported
> by PinCtrl as I understand) instead of a single pair.
>
> ... but I can divine (:D)....that soon a new SCMI spec review/comment/amend
> cycle will be coming for people reading this...
>
> Thanks,
> Cristian
Pinctrl subsystem does support pinctrl_set call with an array of
ConfigType/Value pairs. I'm sending those comfigs one-by-one from
pinctrl_scmi_pinconf_set function. I think that can be added to the
protocol to avoid extra scmi calls.
My understanding on Peng Fan words was that he want's to have multiple
values for one ConfigType.
Let's wait for more information from Peng Fang.
Oleksii
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver
From: Oleksii Moisieiev @ 2023-04-21 9:48 UTC (permalink / raw)
To: Cristian Marussi
Cc: Peng Fan, sudeep.holla@arm.com, Linus Walleij,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
michal.simek@amd.com, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com
In-Reply-To: <ZEJXpCdf9pWgoXL6@e120937-lin>
Hi Cristian,
On 21.04.23 12:30, Cristian Marussi wrote:
> On Fri, Apr 21, 2023 at 08:40:47AM +0000, Oleksii Moisieiev wrote:
>> Hi Peng Fan,
>>
>> On 17.04.23 05:55, Peng Fan wrote:
>>>
>>> On 4/13/2023 6:04 AM, Cristian Marussi wrote:
>>>> On Fri, Apr 07, 2023 at 10:18:27AM +0000, Oleksii Moisieiev wrote:
>>>>> Implementation of the SCMI client driver, which implements
>>>>> PINCTRL_PROTOCOL. This protocol has ID 19 and is described
>>>>> in the latest DEN0056 document.
>>>> Hi,
>>>>
>>>>> This protocol is part of the feature that was designed to
>>>>> separate the pinctrl subsystem from the SCP firmware.
>>>>> The idea is to separate communication of the pin control
>>>>> subsystem with the hardware to SCP firmware
>>>>> (or a similar system, such as ATF), which provides an interface
>>>>> to give the OS ability to control the hardware through SCMI protocol.
>>>>> This is a generic driver that implements SCMI protocol,
>>>>> independent of the platform type.
>>>>>
>>>>> DEN0056 document:
>>>>> https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!y2hR3PEGGxiPjVeXBcgGyV03DPDhzgUKR0uHvsTpiafKgBar8Egc6oOOs-IkFIquhSf-qBzltqEMyzRZHq8eC4g$
>>>>> [developer[.]arm[.]com]
>>>>>
>>>> No need to specify all of this in the commit message, just a note that
>>>> you are adding a new SCMIv3.2 Pincontrol protocol, highlighting anything
>>>> that has been left out in this patch (if any) will be enough.
>>> Is it possible to extend the spec to support multilple uint32_t for PIN
>>> CONFIG SET?
>>>
>>> With only one uint32_t could not satisfy i.MX requirement.
>>>
>>> Thanks,
>>> Peng.
>>>
>> IIUC you are expecting to have an ability to set some kind of array of
>> uint32_t config values to some specific ConfigType?
>>
>> I'm not sure if it's supported by pintctrl subsystem right now. I was
>> unable to find an example in the existing device-tree pinctrl bindings.
>> This makes me think that this kind of binding is OEM specific.
>>
>> Maybe it can be implemented by adding new IDs to OEM specific range
>> (192-255) which is reserved for OEM specific units (See Table 23 of
>> DEN0056E).
>>
> If I understood correctly the aim of Peng multi-valued request, I think
> that even if Linux does not support using this kind of multiple valued
> requests (as of now), if it is useful or required by some of the possibly
> supported hardware, it should be described and allowed by the specification
> and supported by the core SCMI protocol support at least, while the pinctrl
> SCMI driver can ignore this and keep using a one-sized array protocol_ops
> call internally (since it cannot do any different anyway as of now)
>
> IOW I dont think we should model too strictly the SCMI spec against only
> what the Linux pinctrl subsystem support today, since Linux it is just
> really only one of the possible SCMI agents and Linux implementation itself
> can possibly change: it is better to model the spec on the HW requirements
> or the possible usage patterns across all the possibly participating agents.
>
> As an example, for similar reasons, when the SCMI Voltage protocol was added
> to the spec, at the very last minute, a change was made to the spec to allow
> for negative voltages, even though the Linux regulator subsystem was not
> and still is not supporting at all negative voltages as of now; so basically
> the SCMI voltage protocol API now exposes a per-domain flag (negative_volts_allowed),
> that allows any kind of voltage domain to be enumerated and handled at the SCMI
> spec and core layer but that also allows any SCMI driver user, like the SCMI
> Regulator driver, to decide on his own if negative voltages domains can be
> supported: indeed the scmi-regulator driver just skips the initialization of
> any voltage domain that is found to be describing negative voltages.
>
> Here is a bit different, it is more of an optimization in the call path
> than an HW difference, but I would follow the same approach: with the
> SCMI spec and the core SCMI stack (the protocol) that supports a multi-uint32
> call as a general case, if useful for some scenarios, and instead the SCMI
> pinctrl driver that just ignores this possibility and keep using a single-value
> array anyway....then, it will be up to the guys leveraging this multi-valued
> call to come up with a way to use it on their systems, possibly maybe contributing
> back to upstream any needed modification if general enough
> (not sure about the details of how this multi-vals operation should be...we'll have
> to discuss that about the spec all together I think.)
>
> In any case, I would definitely NOT relegate such possibility to vendor space,
> since it is something generic and, especially being just (as it seems to me) an
> optimization on the call path at the end, it will just lead to uneeded duplication
> of functionalities in the vendor implementation of stuff that it is already
> very slightly differently supported by the standard.
>
> ...just my opinion anyway, I'll happily let other guys in this thread discuss and
> decide about this :P
>
> Thanks,
> Cristian
That sounds reasonable for me, although I can't imagine the use case of
multi-valued config values (most likely this is the problem of my
imagination). So I'd appreciate if Peng Fan could provide us with some
examples.
From my standpoint - ConfigTypes are meant to be simple value because
they are mostly related to the electronic properties. But I agree that
protocol should be platform-agnostic.
It will be great if Peng Fan could provide some examples, so we can
think about the best solution.
Best regards,
Oleksii
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Fix incorrect alloc_workqueue() invocation
From: Sudeep Holla @ 2023-04-21 9:48 UTC (permalink / raw)
To: Cristian Marussi; +Cc: Tejun Heo, linux-arm-kernel, linux-kernel, kernel-team
In-Reply-To: <ZEJZqYfNbyrFkqWY@e120937-lin>
On Fri, Apr 21, 2023 at 10:38:49AM +0100, Cristian Marussi wrote:
> I though so, but as usual I am not sure what to do when we are fixing something
> in the middle of a cycle... Raw support went in v6.3-rc1 and we are now in
> v6.3-rc7, so if you want to pick this up now (as it seems the case) it will fix
> the above yes, but it is anyway still on an unreleased kernel...so nothing really
> to have to apply on any early stable kernels...buh..I dont know what is the rule,
> but the Fix tag seems harmless ... so why not :D
>
Not that complicated TBH. If you know this fixes a particular commit in the
tree, just add Fixes tag. The stable maintainers have made it easier in
general by relying on the fixes tag and not needing explicit stable tag in
most of the cases. I will add it.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver
From: Cristian Marussi @ 2023-04-21 9:47 UTC (permalink / raw)
To: Linus Walleij
Cc: Oleksii Moisieiev, Peng Fan, sudeep.holla@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
michal.simek@amd.com, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com
In-Reply-To: <CACRpkdY1eSdWX6+azn43MO77urVf_t25wgZtuyTwKHw4v+QYNg@mail.gmail.com>
On Fri, Apr 21, 2023 at 11:28:38AM +0200, Linus Walleij wrote:
> On Fri, Apr 21, 2023 at 10:40 AM Oleksii Moisieiev
> <Oleksii_Moisieiev@epam.com> wrote:
> > On 17.04.23 05:55, Peng Fan wrote:
> > > On 4/13/2023 6:04 AM, Cristian Marussi wrote:
>
> > > Is it possible to extend the spec to support multilple uint32_t for PIN
> > > CONFIG SET?
> > >
> > > With only one uint32_t could not satisfy i.MX requirement.
> > >
> > > Thanks,
> > > Peng.
> > >
> > IIUC you are expecting to have an ability to set some kind of array of
> > uint32_t config values to some specific ConfigType?
> >
> > I'm not sure if it's supported by pintctrl subsystem right now. I was
> > unable to find an example in the existing device-tree pinctrl bindings.
> > This makes me think that this kind of binding is OEM specific.
> >
> > Maybe it can be implemented by adding new IDs to OEM specific range
> > (192-255) which is reserved for OEM specific units (See Table 23 of
> > DEN0056E).
>
Hi Linus,
> From a pinctrl point of view I do not understand this requirement.
>
> The pinctrl subsystem in the Linux kernel certainly does not support
> an array of u32 for the pin config, we only support passing a single
> u32 value along with the enumerator (config type), or well it is
> actually 24 bits in Linux, the uppermost 8 bits is for the config type:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/pinctrl/pinconf-generic.h
>
> /*
> * Helpful configuration macro to be used in tables etc.
> */
> #define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
>
> p = parameter (PIN_CONFIG_DRIVE_STRENGTH etc)
> a = argument (value such as in mA)
>
My (possibly wrong) reasoning on the other reply, is based on the
(possibly equally wrong :D) understanding that what Peng wants is just
the possibility at the spec and the SCMI protocol layer (exposed in
protocol operations) to issue PINCTRL_SET requests containing optionally
an array of multiple ConfigType/Value pairs (which is anyway not supported
by PinCtrl as I understand) instead of a single pair.
... but I can divine (:D)....that soon a new SCMI spec review/comment/amend
cycle will be coming for people reading this...
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] Revert "arm64: dts: mediatek: mt8173-elm: Move display to ps8640 auxiliary bus"
From: Pin-yen Lin @ 2023-04-21 9:44 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Rob Herring, Krzysztof Kozlowski, Matthias Brugger, devicetree,
linux-kernel, linux-mediatek, linux-arm-kernel
In-Reply-To: <e15eac65-94d4-6a70-cab1-4fdb550116f7@collabora.com>
Hi all,
I would like to drop this patch because 102e80d1fa2c ("drm/bridge:
ps8640: Use atomic variants of drm_bridge_funcs") breaks the
ps8640_bridge_get_edid function. The atomic helper requires an atomic
state to do the chain enablement, but we don't have that in the
.get_edid callback.
The latest ChromeOS tree uses the "aux-bus" with "edp-panel"
compatible string, and it seems to be working well. I'll upload
another patch to update this.
Best regards,
Pin-yen
On Wed, Mar 15, 2023 at 6:34 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 15/03/23 05:11, Pin-yen Lin ha scritto:
> > This reverts commit c2d94f72140a28d0f516b7c5e8274a9c185a04ff.
> >
> > The `lg_lp120up1_mode` defined in panel-edp.c is not working for some
> > panels used on elm/hana devices. Move the panel node out of the aux-bus
> > subnode so the driver only uses the modes retrieved from the EDID.
> >
> > Signed-off-by: Pin-yen Lin <treapking@chromium.org>
> >
>
> This commit was sent to fix display functionality on MT8173-Elm (Acer Chromebook
> R13).... apparently this should get fixed with [1].
>
> Investigating if this is the case.
>
> Regards,
> Angelo
>
> [1]:
> https://patchwork.kernel.org/project/dri-devel/patch/20230315035508.2874915-1-treapking@chromium.org/
>
> > ---
> >
> > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 26 +++++++++-----------
> > 1 file changed, 12 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> > index d452cab28c67..d45a2aeb0eb1 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> > @@ -90,6 +90,18 @@ switch-volume-up {
> > };
> > };
> >
> > + panel: panel {
> > + compatible = "lg,lp120up1";
> > + power-supply = <&panel_fixed_3v3>;
> > + backlight = <&backlight>;
> > +
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&ps8640_out>;
> > + };
> > + };
> > + };
> > +
> > panel_fixed_3v3: regulator1 {
> > compatible = "regulator-fixed";
> > regulator-name = "PANEL_3V3";
> > @@ -282,20 +294,6 @@ ps8640_out: endpoint {
> > };
> > };
> > };
> > -
> > - aux-bus {
> > - panel: panel {
> > - compatible = "lg,lp120up1";
> > - power-supply = <&panel_fixed_3v3>;
> > - backlight = <&backlight>;
> > -
> > - port {
> > - panel_in: endpoint {
> > - remote-endpoint = <&ps8640_out>;
> > - };
> > - };
> > - };
> > - };
> > };
> > };
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/7] ARM: dts: s5pv210: Adjust I2S entries to match spec
From: Krzysztof Kozlowski @ 2023-04-21 9:44 UTC (permalink / raw)
To: Jonathan Bakker, alim.akhtar
Cc: robh+dt, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <414f1ad8-8ee1-9913-c0e8-b4f66f3e7180@kernel.org>
On 24/03/2022 12:49, Krzysztof Kozlowski wrote:
> On 23/03/2022 18:24, Jonathan Bakker wrote:
>> Hi Krzysztof,
>>
>> On 2022-03-23 8:15 a.m., Krzysztof Kozlowski wrote:
>>> On 23/03/2022 16:14, Krzysztof Kozlowski wrote:
>>>> On 23/03/2022 16:03, Jonathan Bakker wrote:
>>>>> Based on the device tree spec, clocks should be ordered tx/rx.
>>>>> Re-order from rx/tx to avoid warnings when running make dtbs_check
>>>>>
>>>>> Additionally, the number of #sound-dai-cells should be 1, not 0
>>>>>
>>>>> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
>>>>> ---
>>>>> arch/arm/boot/dts/s5pv210-aries.dtsi | 2 +-
>>>>> arch/arm/boot/dts/s5pv210.dtsi | 18 +++++++++---------
>>>>> 2 files changed, 10 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/s5pv210-aries.dtsi b/arch/arm/boot/dts/s5pv210-aries.dtsi
>>>>> index 70ff56daf4cb..503b5a50ef1a 100644
>>>>> --- a/arch/arm/boot/dts/s5pv210-aries.dtsi
>>>>> +++ b/arch/arm/boot/dts/s5pv210-aries.dtsi
>>>>> @@ -644,7 +644,7 @@
>>>>> };
>>>>>
>>>>> &i2s0 {
>>>>> - dmas = <&pdma0 9>, <&pdma0 10>, <&pdma0 11>;
>>>>> + dmas = <&pdma0 10>, <&pdma0 9>, <&pdma0 11>;
>>>>> status = "okay";
>>>>
>>>> Except that fix that's the same commit as here:
>>>> https://lore.kernel.org/all/20200907161141.31034-26-krzk@kernel.org/
>>>> so just extend it.
>>>>
>>>> sound-dai-cells should go to a separate commit. But are you sure they
>>>> are correct? The Fascinate 4G seems to be using them as cells=0.
>>>
>>> See my previous patch and discussion:
>>> https://lore.kernel.org/all/20200907161141.31034-10-krzk@kernel.org/
>>>
>>
>> Thanks, I'd totally forgotten about this series from the past. I'll re-test
>> those commits and submit your copies of them in v2 if that's OK with you and
>> that they're confirmed functional?
>
> My dma fixes change lacked this aries fix. The sound-dai-cells needed
> more rethinking.
>
Hi Jonathan,
Any plans for checking/fixing/testing and resending the sound-dai-cells
fixes?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver
From: Linus Walleij @ 2023-04-21 9:28 UTC (permalink / raw)
To: Oleksii Moisieiev
Cc: Peng Fan, Cristian Marussi, sudeep.holla@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
michal.simek@amd.com, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com
In-Reply-To: <f73f39e2-81dd-4204-a3be-c5e7f5e54c1b@epam.com>
On Fri, Apr 21, 2023 at 10:40 AM Oleksii Moisieiev
<Oleksii_Moisieiev@epam.com> wrote:
> On 17.04.23 05:55, Peng Fan wrote:
> > On 4/13/2023 6:04 AM, Cristian Marussi wrote:
> > Is it possible to extend the spec to support multilple uint32_t for PIN
> > CONFIG SET?
> >
> > With only one uint32_t could not satisfy i.MX requirement.
> >
> > Thanks,
> > Peng.
> >
> IIUC you are expecting to have an ability to set some kind of array of
> uint32_t config values to some specific ConfigType?
>
> I'm not sure if it's supported by pintctrl subsystem right now. I was
> unable to find an example in the existing device-tree pinctrl bindings.
> This makes me think that this kind of binding is OEM specific.
>
> Maybe it can be implemented by adding new IDs to OEM specific range
> (192-255) which is reserved for OEM specific units (See Table 23 of
> DEN0056E).
From a pinctrl point of view I do not understand this requirement.
The pinctrl subsystem in the Linux kernel certainly does not support
an array of u32 for the pin config, we only support passing a single
u32 value along with the enumerator (config type), or well it is
actually 24 bits in Linux, the uppermost 8 bits is for the config type:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/pinctrl/pinconf-generic.h
/*
* Helpful configuration macro to be used in tables etc.
*/
#define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
p = parameter (PIN_CONFIG_DRIVE_STRENGTH etc)
a = argument (value such as in mA)
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Fix incorrect alloc_workqueue() invocation
From: Sudeep Holla @ 2023-04-21 9:27 UTC (permalink / raw)
To: Cristian Marussi
Cc: Tejun Heo, linux-arm-kernel, Sudeep Holla, linux-kernel,
kernel-team
In-Reply-To: <ZEJNU1om5IhQHB2J@e120937-lin>
On Fri, Apr 21, 2023 at 09:46:11AM +0100, Cristian Marussi wrote:
> On Thu, Apr 20, 2023 at 09:33:49AM -1000, Tejun Heo wrote:
> > scmi_xfer_raw_worker_init() is specifying a flag, WQ_SYSFS, as @max_active.
> > Fix it by or'ing WQ_SYSFS into @flags so that it actually enables sysfs
> > interface and using 0 for @max_active for the default setting.
> >
Thanks, good catch, very hard to notice.
>
> Hi Tejun,
>
> my bad I messed up the params in the call.
>
Hi Cristian,
I think it deserves the fixes tag, right ?
Fixes: 3c3d818a9317 ("firmware: arm_scmi: Add core raw transmission support")
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox