* Re: [PATCH 1/3] dt-bindings: power: qcom,rpmpd: Add Hawi RPMh power domain
From: Krzysztof Kozlowski @ 2026-04-02 8:35 UTC (permalink / raw)
To: Fenglin Wu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio, Subbaraman Narayanamurthy,
linux-arm-msm, devicetree, linux-kernel, linux-pm, kernel
In-Reply-To: <20260401-haw-rpmhpd-v1-1-c830c79ed8f9@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 02:15:29AM -0700, Fenglin Wu wrote:
> Document the RPMh power domain for Hawi SoC.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Missing new power domains, no?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spmi: glymur-spmi-pmic-arb: Add compatible for Hawi
From: Krzysztof Kozlowski @ 2026-04-02 8:37 UTC (permalink / raw)
To: Fenglin Wu
Cc: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Subbaraman Narayanamurthy, David Collins,
linux-arm-msm, linux-kernel, devicetree, kernel
In-Reply-To: <20260401-hawi-spmi-v1-1-c40963041078@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 02:41:23AM -0700, Fenglin Wu wrote:
> Add a string for hawi-spmi-pmic-arb which is a compat of
There is no such term as being a compat of something/someone.
> glymur-spmi-pmic-arb.
SPMI PMIC Arbiter in Glymur?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spmi: glymur-spmi-pmic-arb: Add compatible for Hawi
From: Krzysztof Kozlowski @ 2026-04-02 8:37 UTC (permalink / raw)
To: Fenglin Wu
Cc: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Subbaraman Narayanamurthy, David Collins,
linux-arm-msm, linux-kernel, devicetree, kernel
In-Reply-To: <20260401-hawi-spmi-v1-1-c40963041078@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 02:41:23AM -0700, Fenglin Wu wrote:
> Add a string for hawi-spmi-pmic-arb which is a compat of
> glymur-spmi-pmic-arb.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
Another patch without any qcom reference.
I already complained yesterday internally, but I did not Cc you.
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: watchdog: qcom-wdt: Document Hawi watchdog compatible
From: Krzysztof Kozlowski @ 2026-04-02 8:39 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rajendra Nayak, linux-arm-msm, linux-watchdog,
devicetree, linux-kernel
In-Reply-To: <20260401124442.591803-1-mukesh.ojha@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:14:42PM +0530, Mukesh Ojha wrote:
> Add devicetree binding for watchdog present on Qualcomm Hawi SoC.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: qcom,gpi: Document GPI DMA engine for Hawi SoC
From: Krzysztof Kozlowski @ 2026-04-02 8:40 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, linux-arm-msm, dmaengine, devicetree, linux-kernel,
Xueyao An, Konrad Dybcio
In-Reply-To: <20260401124028.589931-1-mukesh.ojha@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:10:28PM +0530, Mukesh Ojha wrote:
> From: Xueyao An <xueyao.an@oss.qualcomm.com>
>
> The Hawi GPI DMA engine follows the same programming model and
> register interface as previous generation of Qualcomm SoCs like
> kaanapali, glymur, and is fully compatible with earlier GPI DMA
> implementations.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] staging: iio: adis16203: align MODULE_LICENSE with SPDX identifier
From: Andy Shevchenko @ 2026-04-02 8:41 UTC (permalink / raw)
To: Sheng Kun Chang
Cc: jic23, lars, Michael.Hennerich, dlechner, nuno.sa, andy, gregkh,
robh, krzk+dt, conor+dt, linux-iio, linux-staging, devicetree,
linux-kernel
In-Reply-To: <20260401162458.88110-3-nothingchang@mirrorstack.ai>
On Wed, Apr 01, 2026 at 04:24:56PM +0000, Sheng Kun Chang wrote:
> The SPDX license identifier is GPL-2.0+ (GPL v2 or later) but
> MODULE_LICENSE was set to "GPL v2" which indicates GPL v2 only.
> Change to "GPL" which means GPL v2 or later, matching the SPDX
> header.
This description has nothing to do with the macro parameter. GPL is new,
GPL v2 is just legacy alias.
Also I think this is unneeded churn. If we want to unify this, needs to
be done for all drivers in IIO.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Tudor Ambarus @ 2026-04-02 8:42 UTC (permalink / raw)
To: Alexey Klimov, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Sam Protsenko, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-2-ca5ffdff99d4@linaro.org>
Hi, Alexey,
On 4/2/26 5:20 AM, Alexey Klimov wrote:
> Exynos850-based platforms support ACPM and has similar workflow
> of communicating with ACPM via mailbox, however mailbox controller
> registers are located at different offsets and writes/reads could be
> different. To distinguish between such different behaviours,
> the registers offsets for Exynos850 and the platform-specific data
> structs are introduced and configuration is described in such structs
> for gs101 and exynos850 based SoCs. Probe routine now selects the
> corresponding platform-specific data via device_get_match_data().
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> drivers/mailbox/exynos-mailbox.c | 67 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mailbox/exynos-mailbox.c b/drivers/mailbox/exynos-mailbox.c
> index d2355b128ba4..f9c59c07558a 100644
> --- a/drivers/mailbox/exynos-mailbox.c
> +++ b/drivers/mailbox/exynos-mailbox.c
> @@ -31,14 +31,61 @@
>
> #define EXYNOS_MBOX_CHAN_COUNT HWEIGHT32(EXYNOS_MBOX_INTGR1_MASK)
>
> +#define EXYNOS850_MBOX_MCUCTRL 0x0 /* Mailbox Control Register */
> +#define EXYNOS850_MBOX_INTGR0 0x8 /* Interrupt Generation Register 0 */
> +#define EXYNOS850_MBOX_INTCR0 0x0C /* Interrupt Clear Register 0 */
> +#define EXYNOS850_MBOX_INTMR0 0x10 /* Interrupt Mask Register 0 */
> +#define EXYNOS850_MBOX_INTSR0 0x14 /* Interrupt Status Register 0 */
> +#define EXYNOS850_MBOX_INTMSR0 0x18 /* Interrupt Mask Status Register 0 */
> +#define EXYNOS850_MBOX_INTGR1 0x1C /* Interrupt Generation Register 1 */
> +#define EXYNOS850_MBOX_INTMR1 0x24 /* Interrupt Mask Register 1 */
> +#define EXYNOS850_MBOX_INTSR1 0x28 /* Interrupt Status Register 1 */
> +#define EXYNOS850_MBOX_INTMSR1 0x2C /* Interrupt Mask Status Register 1 */
> +#define EXYNOS850_MBOX_VERSION 0x70
Please consider defining just the registers that are used, to not
pollute the driver. You may drop the unused gs101 definitions too.
> +
> +#define EXYNOS850_MBOX_INTMR1_MASK GENMASK(15, 0)
> +
> +/**
> + * struct exynos_mbox_driver_data - platform-specific mailbox configuration.
> + * @irq_doorbell_offset: offset to the IRQ generation register, doorbell
> + * to APM co-processor.
> + * @irq_doorbell_shift: shift to apply to the value written to IRQ
> + * generation register.
> + * @irq_mask_offset: offset to the IRQ mask register.
> + * @irq_mask_value: value to right to the mask register to mask out
> + * all interrupts.
> + */
> +struct exynos_mbox_driver_data {
> + u16 irq_doorbell_offset;
> + u16 irq_doorbell_shift;
> + u16 irq_mask_offset;
> + u16 irq_mask_value;
> +};
> +
> /**
> * struct exynos_mbox - driver's private data.
> * @regs: mailbox registers base address.
> * @mbox: pointer to the mailbox controller.
> + * @data: pointer to driver platform-specific data.
> */
> struct exynos_mbox {
> void __iomem *regs;
> struct mbox_controller *mbox;
> + const struct exynos_mbox_driver_data *data;
> +};
> +
> +static const struct exynos_mbox_driver_data exynos850_mbox_data = {
> + .irq_doorbell_offset = EXYNOS850_MBOX_INTGR0,
> + .irq_doorbell_shift = 16,
> + .irq_mask_offset = EXYNOS850_MBOX_INTMR1,
> + .irq_mask_value = EXYNOS850_MBOX_INTMR1_MASK,
> +};
> +
> +static const struct exynos_mbox_driver_data exynos_gs101_mbox_data = {
> + .irq_doorbell_offset = EXYNOS_MBOX_INTGR1,
> + .irq_doorbell_shift = 0,
> + .irq_mask_offset = EXYNOS_MBOX_INTMR0,
> + .irq_mask_value = EXYNOS_MBOX_INTMR0_MASK,
> };
I find it strange that the SoCs use different registers. Are you sure you're
using the right direction? i.e. ring the doorbell to APM and not to AP?
>
> static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
> @@ -57,7 +104,8 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
> return -EINVAL;
> }
>
> - writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
> + writel(BIT(msg->chan_id) << exynos_mbox->data->irq_doorbell_shift,
> + exynos_mbox->regs + exynos_mbox->data->irq_doorbell_offset);
Use FIELD_PREP from <linux/bitfield.h> please. You will use a mask instead of
a shift.
I would rename irq_doorbell_offset to intgr. It aligns with the register name
from the datasheet. You won't need to prepend _offset to the name, we already
see it's an offset when doing the writel().
>
> return 0;
> }
> @@ -87,13 +135,21 @@ static struct mbox_chan *exynos_mbox_of_xlate(struct mbox_controller *mbox,
> }
>
> static const struct of_device_id exynos_mbox_match[] = {
> - { .compatible = "google,gs101-mbox" },
> + {
> + .compatible = "google,gs101-mbox",
> + .data = &exynos_gs101_mbox_data
> + },
> + {
> + .compatible = "samsung,exynos850-mbox",
> + .data = &exynos850_mbox_data
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, exynos_mbox_match);
>
> static int exynos_mbox_probe(struct platform_device *pdev)
> {
> + const struct exynos_mbox_driver_data *data;
> struct device *dev = &pdev->dev;
> struct exynos_mbox *exynos_mbox;
> struct mbox_controller *mbox;
> @@ -122,6 +178,11 @@ static int exynos_mbox_probe(struct platform_device *pdev)
> return dev_err_probe(dev, PTR_ERR(pclk),
> "Failed to enable clock.\n");
>
> + data = device_get_match_data(&pdev->dev);
> + if (!data)
> + return -ENODEV;
> +
> + exynos_mbox->data = data;
> mbox->num_chans = EXYNOS_MBOX_CHAN_COUNT;
> mbox->chans = chans;
> mbox->dev = dev;
> @@ -133,7 +194,7 @@ static int exynos_mbox_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, exynos_mbox);
>
> /* Mask out all interrupts. We support just polling channels for now. */
> - writel(EXYNOS_MBOX_INTMR0_MASK, exynos_mbox->regs + EXYNOS_MBOX_INTMR0);
> + writel(data->irq_mask_value, exynos_mbox->regs + data->irq_mask_offset);
>
and here I would s/irq_mask_value/intmr_mask and irq_mask_offset/intmr.
Cheers,
ta
> return devm_mbox_controller_register(dev, mbox);
> }
>
^ permalink raw reply
* Re: [PATCH 0/3] Move adis16203 inclinometer driver out of staging
From: Andy Shevchenko @ 2026-04-02 8:43 UTC (permalink / raw)
To: Sheng Kun Chang
Cc: jic23, lars, Michael.Hennerich, dlechner, nuno.sa, andy, gregkh,
robh, krzk+dt, conor+dt, linux-iio, linux-staging, devicetree,
linux-kernel
In-Reply-To: <20260401162458.88110-1-nothingchang@mirrorstack.ai>
On Wed, Apr 01, 2026 at 04:24:54PM +0000, Sheng Kun Chang wrote:
> This series moves the ADIS16203 Programmable 360 Degrees Inclinometer
> driver out of staging and into drivers/iio/accel/.
>
> The driver already uses standard IIO channel interfaces and devm
> managed APIs. The only missing piece was devicetree binding
> documentation, which is added in patch 1.
>
> Patch 1: Add devicetree binding documentation
> Patch 2: Fix MODULE_LICENSE to match SPDX identifier
> Patch 3: Move the driver from staging to drivers/iio/accel/
Please, add also MAINTAINERS record.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] riscv: dts: sophgo: Add dma-coherent to SG2042 PCIe controllers
From: Chen Wang @ 2026-04-02 8:43 UTC (permalink / raw)
To: Han Gao, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Inochi Amaoto, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Zixian Zeng
Cc: linux-pci, devicetree, sophgo, linux-kernel, linux-riscv, Han Gao,
stable
In-Reply-To: <20260331171248.973014-3-gaohan@iscas.ac.cn>
On 4/1/2026 1:12 AM, Han Gao wrote:
> SG2042's PCIe root complexes are cache-coherent with the CPU. Mark all
> four PCIe controller nodes (pcie_rc0 through pcie_rc3) as dma-coherent
> so the kernel uses coherent DMA mappings instead of non-coherent bounce
> buffering.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> ---
> arch/riscv/boot/dts/sophgo/sg2042.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/sophgo/sg2042.dtsi b/arch/riscv/boot/dts/sophgo/sg2042.dtsi
> index 9fddf3f0b3b9..3af770549742 100644
> --- a/arch/riscv/boot/dts/sophgo/sg2042.dtsi
> +++ b/arch/riscv/boot/dts/sophgo/sg2042.dtsi
> @@ -417,6 +417,7 @@ pcie_rc0: pcie@7060000000 {
> vendor-id = <0x1f1c>;
> device-id = <0x2042>;
> cdns,no-bar-match-nbits = <48>;
> + dma-coherent;
> msi-parent = <&msi>;
> status = "disabled";
> };
> @@ -439,6 +440,7 @@ pcie_rc1: pcie@7060800000 {
> vendor-id = <0x1f1c>;
> device-id = <0x2042>;
> cdns,no-bar-match-nbits = <48>;
> + dma-coherent;
> msi-parent = <&msi>;
> status = "disabled";
> };
> @@ -461,6 +463,7 @@ pcie_rc2: pcie@7062000000 {
> vendor-id = <0x1f1c>;
> device-id = <0x2042>;
> cdns,no-bar-match-nbits = <48>;
> + dma-coherent;
> msi-parent = <&msi>;
> status = "disabled";
> };
> @@ -483,6 +486,7 @@ pcie_rc3: pcie@7062800000 {
> vendor-id = <0x1f1c>;
> device-id = <0x2042>;
> cdns,no-bar-match-nbits = <48>;
> + dma-coherent;
> msi-parent = <&msi>;
> status = "disabled";
> };
For binding changes, LGTM. But I have a question regarding this change
in dtsi.
From your patch description, I understand that enabling the
`dma-coherent` attribute requires upgrading the firmware `fip.bin`. If a
user only updates the kernel (which is relatively easy) but forgets or
doesn't know how to upgrade the firmware, enabling `coherent` might
cause the kernel to skip all explicit cache maintenance operations.
Could this pose a subtle risk?
Wouldn't it be safer to leave the upstream unchanged in dtsi and allow
users to add the `dma-coherent` attribute themselves after they upgrade
the firmware?
I would greatly appreciate your guidance.
Thanks,
Chen
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: iio: accel: add binding for adi,adis16203
From: Krzysztof Kozlowski @ 2026-04-02 8:45 UTC (permalink / raw)
To: Sheng Kun Chang
Cc: jic23, lars, Michael.Hennerich, dlechner, nuno.sa, andy, gregkh,
robh, krzk+dt, conor+dt, linux-iio, linux-staging, devicetree,
linux-kernel
In-Reply-To: <20260401162458.88110-2-nothingchang@mirrorstack.ai>
On Wed, Apr 01, 2026 at 04:24:55PM +0000, Sheng Kun Chang wrote:
> Add devicetree binding documentation for the Analog Devices
> ADIS16203 Programmable 360 Degrees Inclinometer, in preparation
> for moving the driver out of staging.
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Sheng Kun Chang <nothingchang@mirrorstack.ai>
> ---
> .../bindings/iio/accel/adi,adis16203.yaml | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/adi,adis16203.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16203.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16203.yaml
> new file mode 100644
> index 000000000..6c5e2833c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16203.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/accel/adi,adis16203.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ADIS16203 Programmable 360 Degrees Inclinometer
> +
> +maintainers:
> + - Jonathan Cameron <jic23@kernel.org>
> +
> +description: |
> + Programmable 360 degrees inclinometer with SPI interface.
> + https://www.analog.com/en/products/adis16203.html
> +
> +properties:
> + compatible:
> + const: adi,adis16203
So everything looks exactly the same as adi,adis16201. Put it there. You
probably copied it already, because you made exactly same
issues/mistakes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/3] Exynos850 APM-to-AP mailbox support
From: Tudor Ambarus @ 2026-04-02 8:45 UTC (permalink / raw)
To: Alexey Klimov, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Sam Protsenko, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-0-ca5ffdff99d4@linaro.org>
Hi!
On 4/2/26 5:20 AM, Alexey Klimov wrote:
> This patch series introduces support for the APM-to-AP mailbox on the
If AP initiates the communication and APM responds, shouldn't this be called
AP-to-APM mailbox?
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: mailbox: google,gs101-mbox: Add samsung,exynos850-mbox
From: Tudor Ambarus @ 2026-04-02 8:46 UTC (permalink / raw)
To: Alexey Klimov, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Sam Protsenko, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-1-ca5ffdff99d4@linaro.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support
From: Krzysztof Kozlowski @ 2026-04-02 8:47 UTC (permalink / raw)
To: Suneel Garapati
Cc: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260401213831.187569-2-suneelg@nvidia.com>
On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
> reg:
> maxItems: 1
> @@ -112,6 +114,7 @@ allOf:
> contains:
> enum:
> - nvidia,tegra234-gte-aon
> + - nvidia,tegra264-gte-aon
And why exactly the slices are variable here? Explain that in commit
msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: timestamp: Add Tegra264 support
From: Krzysztof Kozlowski @ 2026-04-02 8:47 UTC (permalink / raw)
To: Suneel Garapati
Cc: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260402-neat-amiable-puma-d747ea@quoll>
On 02/04/2026 10:47, Krzysztof Kozlowski wrote:
> On Wed, Apr 01, 2026 at 09:38:29PM +0000, Suneel Garapati wrote:
>> reg:
>> maxItems: 1
>> @@ -112,6 +114,7 @@ allOf:
>> contains:
>> enum:
>> - nvidia,tegra234-gte-aon
>> + - nvidia,tegra264-gte-aon
>
> And why exactly the slices are variable here? Explain that in commit
> msg.
s/Explain/Shortly describe/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Tudor Ambarus @ 2026-04-02 8:48 UTC (permalink / raw)
To: Alexey Klimov, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Sam Protsenko, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-3-ca5ffdff99d4@linaro.org>
On 4/2/26 5:20 AM, Alexey Klimov wrote:
> Add mailbox node that describes AP-to-APM mailbox, that can be
okay so here it's AP-to-APM mailbox.
> used for communicating with APM co-processor on Exynos850 SoCs.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> index cb55015c8dce..fcb665ccc7ae 100644
> --- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> @@ -298,6 +298,15 @@ cmu_apm: clock-controller@11800000 {
> clock-names = "oscclk", "dout_clkcmu_apm_bus";
> };
>
> + ap2apm_mailbox: mailbox@11900000 {
> + compatible = "samsung,exynos850-mbox";
> + reg = <0x11900000 0x1000>;
> + clocks = <&cmu_apm CLK_GOUT_MAILBOX_APM_AP_PCLK>;
> + clock-names = "pclk";
> + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> + #mbox-cells = <0>;
> + };
> +
lgtm:
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> cmu_cmgp: clock-controller@11c00000 {
> compatible = "samsung,exynos850-cmu-cmgp";
> reg = <0x11c00000 0x8000>;
>
^ permalink raw reply
* Re: [PATCH v4 1/4] arm64: dts: qcom: sdm845-xiaomi-beryllium: Introduce framebuffer
From: Konrad Dybcio @ 2026-04-02 8:50 UTC (permalink / raw)
To: david, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sam Day, Dzmitry Sankouski,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel, Petr Hodina
In-Reply-To: <20260402-beryllium-fb-v4-1-46170004da28@ixit.cz>
On 4/2/26 12:39 AM, David Heidelberg via B4 Relay wrote:
> From: Petr Hodina <petr.hodina@protonmail.com>
>
> Add framebuffer for early console and u-boot support.
>
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: Konrad Dybcio @ 2026-04-02 8:53 UTC (permalink / raw)
To: guptarud, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-expressatt_fuel_guage-v3-1-9674cfc0b5a2@gmail.com>
On 4/1/26 10:32 PM, Rudraksha Gupta via B4 Relay wrote:
> From: Rudraksha Gupta <guptarud@gmail.com>
>
> Reorganize the DTS file for consistency with other msm8960 board files.
>
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM: dts: qcom: msm8960: Flatten I2C pinctrl state subnodes
From: Konrad Dybcio @ 2026-04-02 8:53 UTC (permalink / raw)
To: guptarud, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-expressatt_fuel_guage-v3-2-9674cfc0b5a2@gmail.com>
On 4/1/26 10:32 PM, Rudraksha Gupta via B4 Relay wrote:
> From: Rudraksha Gupta <guptarud@gmail.com>
>
> Remove unnecessary inner i2c*-pins {} wrapper nodes from the I2C
> pinctrl state definitions. Properties are moved directly under the
> -state {} node, consistent with modern DT style.
>
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Fix ICE reg size
From: Konrad Dybcio @ 2026-04-02 8:54 UTC (permalink / raw)
To: Kuldeep Singh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Luca Weiss, Eric Biggers
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260402-ice_dt_reg_fix-v1-1-74e4c2129238@oss.qualcomm.com>
On 4/1/26 8:35 PM, Kuldeep Singh wrote:
> The ICE register region on Kodiak is currently defined as 0x8000 bytes.
> According to the hardware specification, the correct register size is
> 0x18000.
>
> Update the ICE node reg property to match the hardware.
>
> Fixes: dfd5ee7b34bb ("arm64: dts: qcom: sc7280: Add inline crypto engine")
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sm8450: Fix ICE reg size
From: Konrad Dybcio @ 2026-04-02 8:57 UTC (permalink / raw)
To: Kuldeep Singh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Luca Weiss, Eric Biggers
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260402-ice_dt_reg_fix-v1-2-74e4c2129238@oss.qualcomm.com>
On 4/1/26 8:35 PM, Kuldeep Singh wrote:
> The ICE register region size was originally described incorrectly when
> the ICE hardware was first introduced. The same value was later carried
> over unchanged when the ICE node was split out from the UFS node into
> its own DT entry.
>
> Correct the register size to match the hardware specification.
>
> Fixes: 276ee34a40c1 ("arm64: dts: qcom: sm8450: add Inline Crypto Engine registers and clock")
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 05/10] drm/bridge: dw-hdmi: document the output_port field
From: Damon Ding @ 2026-04-02 9:05 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Liu Ying, Rob Herring,
Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Christopher Obbard,
Daniel Scally, Emanuele Ghidoli, Fabio Estevam, Francesco Dolcini,
Frieder Schrempf, Gilles Talis, Goran Rađenović,
Heiko Schocher, Josua Mayer, Kieran Bingham, Marco Felsch,
Martyn Welch, Oleksij Rempel, Peng Fan, Richard Hu, Shengjiu Wang,
Stefan Eichenberger, Vitor Soares
In-Reply-To: <DHII3VS5NVEC.179WKXX8C8SOO@bootlin.com>
Hi Luca,
On 4/2/2026 3:46 PM, Luca Ceresoli wrote:
> Hello Damon,
>
> On Tue Mar 31, 2026 at 9:21 AM CEST, Damon Ding wrote:
>> On 3/31/2026 3:25 AM, Luca Ceresoli wrote:
>>> The meaning of this flag may not be obvious at first sight.
>>>
>>> Reviewed-by: Liu Ying <victor.liu@nxp.com>
>>> Tested-by: Martyn Welch <martyn.welch@collabora.com>
>>> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
>>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> Thanks for looking at this series!
>
>>> @@ -126,6 +126,12 @@ struct dw_hdmi_phy_ops {
>>> struct dw_hdmi_plat_data {
>>> struct regmap *regm;
>>>
>>> + /*
>>> + * The HDMI output port number must be 1 if the port is described
>>> + * in the device tree. 0 if the device tree does not describe the
>>> + * next component (legacy mode, i.e. without
>>> + * DRM_BRIDGE_ATTACH_NO_CONNECTOR flag when attaching bridge).
>>> + */
>>> unsigned int output_port;
>>>
>>> unsigned long input_bus_encoding;
>>>
>>
>> Tested-by: Damon Ding <damon.ding@rock-chips.com> (on rk3399)
>
> Uhm, I'm not sure what can be tested in a patch only adding a comment. Did
> you mean 'Reviewed-by' maybe?
>
> Also, I _think_ the best syntax for a comment would be using a '#', not
> parentheses, so that would be
>
> | Tested-by: Damon Ding <damon.ding@rock-chips.com> # on rk3399
>
> This is the recommended syntax for the 'Cc: stable' lines [0], at
> least. Additionally b4 keeps comments with the '#' as those in [1], while
> is discards the ones in parentheses.
>
> [0] https://docs.kernel.org/process/stable-kernel-rules.html
> [1] https://lore.kernel.org/all/2948177.mvXUDI8C0e@steina-w/
>
Indeed, '#' is much better.
I think we still need to further discuss the various cases around
DRM_BRIDGE_ATTACH_NO_CONNECTOR in [PATCH v2 06/10].
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v6 2/3] arm64: dts: qcom: kodiak: enable the inline crypto engine for SDHC
From: Kuldeep Singh @ 2026-04-02 9:06 UTC (permalink / raw)
To: Neeraj Soni, ulf.hansson, robh, krzk+dt, conor+dt, andersson,
konradybcio
Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <20260310113557.348502-3-neeraj.soni@oss.qualcomm.com>
On 3/10/2026 5:05 PM, Neeraj Soni wrote:
> Add an ICE node to kodiak SoC description and enable it by adding a
> phandle to the SDHC node.
>
> Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index c2ccbb67f800..de01a6669522 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -1045,6 +1045,8 @@ sdhc_1: mmc@7c4000 {
> qcom,dll-config = <0x0007642c>;
> qcom,ddr-config = <0x80040868>;
>
> + qcom,ice = <&sdhc_ice>;
> +
> mmc-ddr-1_8v;
> mmc-hs200-1_8v;
> mmc-hs400-1_8v;
> @@ -1071,6 +1073,13 @@ opp-384000000 {
> };
> };
>
> + sdhc_ice: crypto@7c8000 {
> + compatible = "qcom,sc7280-inline-crypto-engine",
> + "qcom,inline-crypto-engine";
> + reg = <0x0 0x007c8000 0x0 0x18000>;
> + clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
> + };
> +
Just thinking out loud, as ufs/emmc ice using same compatible and later
need to add some specific handling due to erratum etc, how to
distinguish two in driver then?
Can add an extra compatible layering to distinguish like
qcom,sc7280-ufs-inline-crypto-engine, qcom,sc7280-ice-inline-crypto-engine?
Otherwise,
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
--
Regards
Kuldeep
^ permalink raw reply
* [PATCH v2 00/24] ASoC: rsnd: Add audio support for the Renesas RZ/G3E SoC
From: John Madieu @ 2026-04-02 9:04 UTC (permalink / raw)
To: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Conor Dooley, Frank Li,
Liam Girdwood, Magnus Damm, Thomas Gleixner, Jaroslav Kysela,
Takashi Iwai, Philipp Zabel, Claudiu Beznea, Biju Das,
Fabrizio Castro, Lad Prabhakar, John Madieu, linux-renesas-soc,
linux-clk, devicetree, linux-kernel, dmaengine, linux-sound,
John Madieu
This series adds audio support for the Renesas RZ/G3E SoC and enables
it on the SMARC EVK board with the Dialog DA7212 codec.
The RZ/G3E audio subsystem is based on R-Car Sound IP but has several
differences requiring dedicated handling:
- SSI operates exclusively in BUSIF mode (no PIO)
- 2 BUSIF channels per SSI instead of 4/8 on R-Car
- Different register offsets for SCU, ADG, SSIU, and SSI
- Per-SSI ADG and SSIF supply clocks
- DMA ACK signal routing through ICU
This series includes:
- Clock driver support for audio clocks and resets
- DT bindings update for DMA ACK signal field
- IRQ chip extension for DMA ACK signal routing
- RZ-DMAC driver updates for ACK signal support
- R-Car Sound driver updates for RZ/G3E support
- System suspend/resume support
- Device tree nodes for RZ/G3E SMARC EVK
Note: patch 04/22 depends on [1]. As this patch will propably be routed
through the DMA tree independently, the rest of the series can be reviewed
and the remaining patches applied without this dependency being resolved
first.
Audio configuration on SMARC EVK:
- Codec: Dialog DA7212 on I2C1
- Playback: SSI3 -> SRC1 -> DVC1
- Capture: SSI4 -> SRC0 -> DVC0
- MCLK: 12.288MHz from Versa3 clock generator
- Format: I2S, RZ/G3E Sound as clock master
- SSI4 shares clock pins with SSI3 (shared-pin)
Tested on RZ/G3E SMARC EVK with:
- Playback to headphone output
- Capture from line-in (AUX) input and/or Mic
- Full duplex operation
- System suspend/resume
Merge strategy:
- Patch 01-02/24: Clock tree
- Patch 03-04/24: both in DMA tree, as there is hard inter-dependency between
these patches
- Patch 05-18/24: ASoC tree
- Patch 19-24/24: SoC dts tree
[1] https://lore.kernel.org/all/20260320112838.2200198-1-claudiu.beznea.uj@bp.renesas.com/
Changes:
v2:
- Fix Rob's comment on maxItems not needed with items lists.
- Drop DMA ACK second cell from DT specifier
- Derive ACK signal number in-driver from MID/RID using arithmetic formulas
per ICU Table 4.6-28 (3 linear peripheral groups)
- Split of rsnd.yaml into common and R-Car-specific schemas
- Introduce RZ/G3E sound binding as a standalone schema
- Addressed Kuninori'comments, details are in individual patches
John Madieu (24):
dt-bindings: clock: renesas: Add audio clock inputs for RZ/V2H family
clk: renesas: r9a09g047: Add audio clock and reset support
irqchip/renesas-rzv2h: Add DMA ACK signal routing support
dma: sh: rz-dmac: Add DMA ACK signal routing support
ASoC: dt-bindings: renesas,rsnd: Split into generic and SoC-specific
parts
ASoC: dt-bindings: Add RZ/G3E (R9A09G047) sound binding
ASoC: rsnd: Add reset controller support to rsnd_mod
ASoC: rsnd: Add RZ/G3E SoC probing and register map
ASoC: rsnd: Add audmacpp clock and reset support for RZ/G3E
ASoC: rsnd: Add RZ/G3E DMA address calculation support
ASoC: rsnd: ssui: Add RZ/G3E SSIU BUSIF support
ASoC: rsnd: Add SSI reset support for RZ/G3E platforms
ASoC: rsnd: Add ADG reset support for RZ/G3E
ASoC: rsnd: adg: Add per-SSI ADG and SSIF supply clock management
ASoC: rsnd: src: Add SRC reset and clock support for RZ/G3E
ASoC: rsnd: Add rsnd_adg_mod_get() for PM support
ASoC: rsnd: Export rsnd_ssiu_mod_get() for PM support
ASoC: rsnd: Add system suspend/resume support
arm64: dts: renesas: rzv2h: Add audio clock inputs
arm64: dts: renesas: r9a09g047: Add R-Car Sound support
arm64: dts: renesas: rzg3e-smarc-som: Add Versa3 clock generator
arm64: dts: renesas: rzg3e-smarc-som: Add I2C1 support
arm64: dts: renesas: rzg3e-smarc-som: add audio pinmux definitions
arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec
support
.../bindings/clock/renesas,rzv2h-cpg.yaml | 8 +
.../sound/renesas,r9a09g047-sound.yaml | 371 ++++++++++++
.../bindings/sound/renesas,rsnd-common.yaml | 196 +++++++
.../bindings/sound/renesas,rsnd.yaml | 319 +++--------
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 529 +++++++++++++++++-
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 114 ++++
arch/arm64/boot/dts/renesas/r9a09g056.dtsi | 27 +-
arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 27 +-
.../boot/dts/renesas/rzg3e-smarc-som.dtsi | 44 ++
drivers/clk/renesas/r9a09g047-cpg.c | 129 ++++-
drivers/dma/sh/rz-dmac.c | 72 +++
drivers/irqchip/irq-renesas-rzv2h.c | 40 ++
include/linux/irqchip/irq-renesas-rzv2h.h | 5 +
sound/soc/renesas/rcar/adg.c | 133 ++++-
sound/soc/renesas/rcar/cmd.c | 2 +-
sound/soc/renesas/rcar/core.c | 60 +-
sound/soc/renesas/rcar/ctu.c | 22 +-
sound/soc/renesas/rcar/dma.c | 167 +++++-
sound/soc/renesas/rcar/dvc.c | 22 +-
sound/soc/renesas/rcar/gen.c | 180 ++++++
sound/soc/renesas/rcar/mix.c | 22 +-
sound/soc/renesas/rcar/rsnd.h | 53 +-
sound/soc/renesas/rcar/src.c | 71 ++-
sound/soc/renesas/rcar/ssi.c | 51 +-
sound/soc/renesas/rcar/ssiu.c | 69 ++-
25 files changed, 2427 insertions(+), 306 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
create mode 100644 Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
--
2.25.1
^ permalink raw reply
* [PATCH v2 01/24] dt-bindings: clock: renesas: Add audio clock inputs for RZ/V2H family
From: John Madieu @ 2026-04-02 9:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Conor Dooley, Frank Li,
Liam Girdwood, Magnus Damm, Thomas Gleixner, Jaroslav Kysela,
Takashi Iwai, Philipp Zabel, Claudiu Beznea, Biju Das,
Fabrizio Castro, Lad Prabhakar, John Madieu, linux-renesas-soc,
linux-clk, devicetree, linux-kernel, dmaengine, linux-sound,
John Madieu
In-Reply-To: <20260402090524.9137-1-john.madieu.xa@bp.renesas.com>
RZ/V2H, RZ/V2N, and RZ/G3E support external audio clock inputs
(AUDIO_CLKA, AUDIO_CLKB, AUDIO_CLKC) that can be used by the Audio Clock
Generator (ADG) to derive internal audio clocks. These clocks are optional
and their frequencies are set by the board.
Update the bindings to allow these optional clocks for all RZ/V2H family
SoCs.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v2: Remove maxItems as it not needed with items lists.
.../devicetree/bindings/clock/renesas,rzv2h-cpg.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml
index f261445bf341..d9cf62f5224e 100644
--- a/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml
@@ -26,16 +26,24 @@ properties:
maxItems: 1
clocks:
+ minItems: 3
items:
- description: AUDIO_EXTAL clock input
- description: RTXIN clock input
- description: QEXTAL clock input
+ - description: AUDIO_CLKA clock input
+ - description: AUDIO_CLKB clock input
+ - description: AUDIO_CLKC clock input
clock-names:
+ minItems: 3
items:
- const: audio_extal
- const: rtxin
- const: qextal
+ - const: audio_clka
+ - const: audio_clkb
+ - const: audio_clkc
'#clock-cells':
description: |
--
2.25.1
^ permalink raw reply related
* [PATCH v2 02/24] clk: renesas: r9a09g047: Add audio clock and reset support
From: John Madieu @ 2026-04-02 9:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Rob Herring, Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Conor Dooley, Frank Li,
Liam Girdwood, Magnus Damm, Thomas Gleixner, Jaroslav Kysela,
Takashi Iwai, Philipp Zabel, Claudiu Beznea, Biju Das,
Fabrizio Castro, Lad Prabhakar, John Madieu, linux-renesas-soc,
linux-clk, devicetree, linux-kernel, dmaengine, linux-sound,
John Madieu
In-Reply-To: <20260402090524.9137-1-john.madieu.xa@bp.renesas.com>
Add clock and reset entries for audio-related modules on the RZ/G3E SoC.
Target modules are:
- SSIU (Serial Sound Interface Unit) with SSI ch0-ch9
- SCU (Sampling Rate Converter Unit) with SRC ch0-ch9, DVC ch0-ch1,
CTU/MIX ch0-ch1
- ADMAC (Audio DMA Controller)
- ADG (Audio Clock Generator) with divider input clocks and audio
master clock outputs
While at it, reorder plldty_div16 to group it with other plldty fixed
dividers.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v2: No changes
drivers/clk/renesas/r9a09g047-cpg.c | 129 +++++++++++++++++++++++++++-
1 file changed, 128 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r9a09g047-cpg.c b/drivers/clk/renesas/r9a09g047-cpg.c
index e59ac4a05a7f..2d7e58f155f6 100644
--- a/drivers/clk/renesas/r9a09g047-cpg.c
+++ b/drivers/clk/renesas/r9a09g047-cpg.c
@@ -22,6 +22,9 @@ enum clk_ids {
CLK_AUDIO_EXTAL,
CLK_RTXIN,
CLK_QEXTAL,
+ CLK_AUDIO_CLKA,
+ CLK_AUDIO_CLKB,
+ CLK_AUDIO_CLKC,
/* PLL Clocks */
CLK_PLLCM33,
@@ -34,6 +37,8 @@ enum clk_ids {
/* Internal Core Clocks */
CLK_PLLCM33_DIV3,
CLK_PLLCM33_DIV4,
+ CLK_PLLCM33_DIV4_DDIV2,
+ CLK_PLLCM33_DIV4_DDIV2_DIV2,
CLK_PLLCM33_DIV5,
CLK_PLLCM33_DIV16,
CLK_PLLCM33_GEAR,
@@ -41,15 +46,19 @@ enum clk_ids {
CLK_SMUX2_XSPI_CLK1,
CLK_PLLCM33_XSPI,
CLK_PLLCLN_DIV2,
+ CLK_PLLCLN_DIV4,
CLK_PLLCLN_DIV8,
CLK_PLLCLN_DIV16,
CLK_PLLCLN_DIV20,
+ CLK_PLLCLN_DIV32,
CLK_PLLCLN_DIV64,
CLK_PLLCLN_DIV256,
CLK_PLLCLN_DIV1024,
CLK_PLLDTY_ACPU,
CLK_PLLDTY_ACPU_DIV2,
CLK_PLLDTY_ACPU_DIV4,
+ CLK_PLLDTY_DIV2,
+ CLK_PLLDTY_DIV4,
CLK_PLLDTY_DIV8,
CLK_PLLDTY_RCPU,
CLK_PLLDTY_RCPU_DIV4,
@@ -64,6 +73,7 @@ enum clk_ids {
CLK_PLLDTY_DIV16,
CLK_PLLVDO_CRU0,
CLK_PLLVDO_GPU,
+ CLK_CDIV5_MAINOSC,
/* Module Clocks */
MOD_CLK_BASE,
@@ -120,6 +130,9 @@ static const struct cpg_core_clk r9a09g047_core_clks[] __initconst = {
DEF_INPUT("audio_extal", CLK_AUDIO_EXTAL),
DEF_INPUT("rtxin", CLK_RTXIN),
DEF_INPUT("qextal", CLK_QEXTAL),
+ DEF_INPUT("audio_clka", CLK_AUDIO_CLKA),
+ DEF_INPUT("audio_clkb", CLK_AUDIO_CLKB),
+ DEF_INPUT("audio_clkc", CLK_AUDIO_CLKC),
/* PLL Clocks */
DEF_FIXED(".pllcm33", CLK_PLLCM33, CLK_QEXTAL, 200, 3),
@@ -135,6 +148,11 @@ static const struct cpg_core_clk r9a09g047_core_clks[] __initconst = {
DEF_FIXED(".pllcm33_div5", CLK_PLLCM33_DIV5, CLK_PLLCM33, 1, 5),
DEF_FIXED(".pllcm33_div16", CLK_PLLCM33_DIV16, CLK_PLLCM33, 1, 16),
+ DEF_DDIV(".pllcm33_div4_ddiv2", CLK_PLLCM33_DIV4_DDIV2, CLK_PLLCM33_DIV4,
+ CDDIV0_DIVCTL1, dtable_2_64),
+ DEF_FIXED(".pllcm33_div4_ddiv2_div2", CLK_PLLCM33_DIV4_DDIV2_DIV2,
+ CLK_PLLCM33_DIV4_DDIV2, 1, 2),
+
DEF_DDIV(".pllcm33_gear", CLK_PLLCM33_GEAR, CLK_PLLCM33_DIV4, CDDIV0_DIVCTL1, dtable_2_64),
DEF_SMUX(".smux2_xspi_clk0", CLK_SMUX2_XSPI_CLK0, SSEL1_SELCTL2, smux2_xspi_clk0),
@@ -142,9 +160,11 @@ static const struct cpg_core_clk r9a09g047_core_clks[] __initconst = {
DEF_CSDIV(".pllcm33_xspi", CLK_PLLCM33_XSPI, CLK_SMUX2_XSPI_CLK1, CSDIV0_DIVCTL3,
dtable_2_16),
DEF_FIXED(".pllcln_div2", CLK_PLLCLN_DIV2, CLK_PLLCLN, 1, 2),
+ DEF_FIXED(".pllcln_div4", CLK_PLLCLN_DIV4, CLK_PLLCLN, 1, 4),
DEF_FIXED(".pllcln_div8", CLK_PLLCLN_DIV8, CLK_PLLCLN, 1, 8),
DEF_FIXED(".pllcln_div16", CLK_PLLCLN_DIV16, CLK_PLLCLN, 1, 16),
DEF_FIXED(".pllcln_div20", CLK_PLLCLN_DIV20, CLK_PLLCLN, 1, 20),
+ DEF_FIXED(".pllcln_div32", CLK_PLLCLN_DIV32, CLK_PLLCLN, 1, 32),
DEF_FIXED(".pllcln_div64", CLK_PLLCLN_DIV64, CLK_PLLCLN, 1, 64),
DEF_FIXED(".pllcln_div256", CLK_PLLCLN_DIV256, CLK_PLLCLN, 1, 256),
DEF_FIXED(".pllcln_div1024", CLK_PLLCLN_DIV1024, CLK_PLLCLN, 1, 1024),
@@ -152,7 +172,10 @@ static const struct cpg_core_clk r9a09g047_core_clks[] __initconst = {
DEF_DDIV(".plldty_acpu", CLK_PLLDTY_ACPU, CLK_PLLDTY, CDDIV0_DIVCTL2, dtable_2_64),
DEF_FIXED(".plldty_acpu_div2", CLK_PLLDTY_ACPU_DIV2, CLK_PLLDTY_ACPU, 1, 2),
DEF_FIXED(".plldty_acpu_div4", CLK_PLLDTY_ACPU_DIV4, CLK_PLLDTY_ACPU, 1, 4),
+ DEF_FIXED(".plldty_div2", CLK_PLLDTY_DIV2, CLK_PLLDTY, 1, 2),
+ DEF_FIXED(".plldty_div4", CLK_PLLDTY_DIV4, CLK_PLLDTY, 1, 4),
DEF_FIXED(".plldty_div8", CLK_PLLDTY_DIV8, CLK_PLLDTY, 1, 8),
+ DEF_FIXED(".plldty_div16", CLK_PLLDTY_DIV16, CLK_PLLDTY, 1, 16),
DEF_FIXED(".plleth_250_fix", CLK_PLLETH_DIV_250_FIX, CLK_PLLETH, 1, 4),
DEF_FIXED(".plleth_125_fix", CLK_PLLETH_DIV_125_FIX, CLK_PLLETH_DIV_250_FIX, 1, 2),
@@ -164,9 +187,9 @@ static const struct cpg_core_clk r9a09g047_core_clks[] __initconst = {
DEF_SMUX(".smux2_gbe0_rxclk", CLK_SMUX2_GBE0_RXCLK, SSEL0_SELCTL3, smux2_gbe0_rxclk),
DEF_SMUX(".smux2_gbe1_txclk", CLK_SMUX2_GBE1_TXCLK, SSEL1_SELCTL0, smux2_gbe1_txclk),
DEF_SMUX(".smux2_gbe1_rxclk", CLK_SMUX2_GBE1_RXCLK, SSEL1_SELCTL1, smux2_gbe1_rxclk),
- DEF_FIXED(".plldty_div16", CLK_PLLDTY_DIV16, CLK_PLLDTY, 1, 16),
DEF_DDIV(".plldty_rcpu", CLK_PLLDTY_RCPU, CLK_PLLDTY, CDDIV3_DIVCTL2, dtable_2_64),
DEF_FIXED(".plldty_rcpu_div4", CLK_PLLDTY_RCPU_DIV4, CLK_PLLDTY_RCPU, 1, 4),
+ DEF_FIXED(".cdiv5_mainosc", CLK_CDIV5_MAINOSC, CLK_QEXTAL, 1, 5),
DEF_DDIV(".pllvdo_cru0", CLK_PLLVDO_CRU0, CLK_PLLVDO, CDDIV3_DIVCTL3, dtable_2_4),
DEF_DDIV(".pllvdo_gpu", CLK_PLLVDO_GPU, CLK_PLLVDO, CDDIV3_DIVCTL1, dtable_2_64),
@@ -460,6 +483,96 @@ static const struct rzv2h_mod_clk r9a09g047_mod_clks[] __initconst = {
BUS_MSTOP(3, BIT(4))),
DEF_MOD("tsu_1_pclk", CLK_QEXTAL, 16, 10, 8, 10,
BUS_MSTOP(2, BIT(15))),
+ DEF_MOD("ssif_clk", CLK_PLLCLN_DIV8, 15, 5, 7, 21,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("scu_clk", CLK_PLLCLN_DIV8, 15, 6, 7, 22,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("scu_clkx2", CLK_PLLCLN_DIV4, 15, 7, 7, 23,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("admac_clk", CLK_PLLCLN_DIV8, 15, 8, 7, 24,
+ BUS_MSTOP(2, BIT(5))),
+ DEF_MOD("adg_clks1", CLK_PLLCLN_DIV8, 15, 9, 7, 25,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_clk_200m", CLK_PLLCLN_DIV8, 15, 10, 7, 26,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_audio_clka", CLK_AUDIO_CLKA, 15, 11, 7, 27,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_audio_clkb", CLK_AUDIO_CLKB, 15, 12, 7, 28,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_audio_clkc", CLK_AUDIO_CLKC, 15, 13, 7, 29,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi0_clk", CLK_PLLCLN_DIV8, 22, 0, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi1_clk", CLK_PLLCLN_DIV8, 22, 1, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi2_clk", CLK_PLLCLN_DIV8, 22, 2, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi3_clk", CLK_PLLCLN_DIV8, 22, 3, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi4_clk", CLK_PLLCLN_DIV8, 22, 4, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi5_clk", CLK_PLLCLN_DIV8, 22, 5, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi6_clk", CLK_PLLCLN_DIV8, 22, 6, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi7_clk", CLK_PLLCLN_DIV8, 22, 7, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi8_clk", CLK_PLLCLN_DIV8, 22, 8, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("adg_ssi9_clk", CLK_PLLCLN_DIV8, 22, 9, -1, -1,
+ BUS_MSTOP(2, BIT(2))),
+ DEF_MOD("dvc0_clk", CLK_PLLCLN_DIV8, 23, 0, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("dvc1_clk", CLK_PLLCLN_DIV8, 23, 1, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("ctu0_mix0_clk", CLK_PLLCLN_DIV8, 23, 2, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("ctu1_mix1_clk", CLK_PLLCLN_DIV8, 23, 3, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src0_clk", CLK_PLLCLN_DIV8, 23, 4, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src1_clk", CLK_PLLCLN_DIV8, 23, 5, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src2_clk", CLK_PLLCLN_DIV8, 23, 6, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src3_clk", CLK_PLLCLN_DIV8, 23, 7, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src4_clk", CLK_PLLCLN_DIV8, 23, 8, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src5_clk", CLK_PLLCLN_DIV8, 23, 9, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src6_clk", CLK_PLLCLN_DIV8, 23, 10, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src7_clk", CLK_PLLCLN_DIV8, 23, 11, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src8_clk", CLK_PLLCLN_DIV8, 23, 12, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("src9_clk", CLK_PLLCLN_DIV8, 23, 13, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("scu_supply_clk", CLK_PLLCLN_DIV8, 23, 14, -1, -1,
+ BUS_MSTOP(2, BIT(0) | BIT(1))),
+ DEF_MOD("ssif_supply_clk", CLK_PLLCLN_DIV8, 24, 0, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi0_clk", CLK_PLLCLN_DIV8, 24, 1, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi1_clk", CLK_PLLCLN_DIV8, 24, 2, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi2_clk", CLK_PLLCLN_DIV8, 24, 3, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi3_clk", CLK_PLLCLN_DIV8, 24, 4, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi4_clk", CLK_PLLCLN_DIV8, 24, 5, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi5_clk", CLK_PLLCLN_DIV8, 24, 6, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi6_clk", CLK_PLLCLN_DIV8, 24, 7, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi7_clk", CLK_PLLCLN_DIV8, 24, 8, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi8_clk", CLK_PLLCLN_DIV8, 24, 9, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
+ DEF_MOD("ssi9_clk", CLK_PLLCLN_DIV8, 24, 10, -1, -1,
+ BUS_MSTOP(2, BIT(3) | BIT(4))),
};
static const struct rzv2h_reset r9a09g047_resets[] __initconst = {
@@ -538,6 +651,20 @@ static const struct rzv2h_reset r9a09g047_resets[] __initconst = {
DEF_RST(13, 13, 6, 14), /* GE3D_RESETN */
DEF_RST(13, 14, 6, 15), /* GE3D_AXI_RESETN */
DEF_RST(13, 15, 6, 16), /* GE3D_ACE_RESETN */
+ DEF_RST(14, 1, 6, 18), /* SSIF_0_ASYNC_RESET_SSI */
+ DEF_RST(14, 2, 6, 19), /* SSIF_0_SYNC_RESET_SSI0 */
+ DEF_RST(14, 3, 6, 20), /* SSIF_0_SYNC_RESET_SSI1 */
+ DEF_RST(14, 4, 6, 21), /* SSIF_0_SYNC_RESET_SSI2 */
+ DEF_RST(14, 5, 6, 22), /* SSIF_0_SYNC_RESET_SSI3 */
+ DEF_RST(14, 6, 6, 23), /* SSIF_0_SYNC_RESET_SSI4 */
+ DEF_RST(14, 7, 6, 24), /* SSIF_0_SYNC_RESET_SSI5 */
+ DEF_RST(14, 8, 6, 25), /* SSIF_0_SYNC_RESET_SSI6 */
+ DEF_RST(14, 9, 6, 26), /* SSIF_0_SYNC_RESET_SSI7 */
+ DEF_RST(14, 10, 6, 27), /* SSIF_0_SYNC_RESET_SSI8 */
+ DEF_RST(14, 11, 6, 28), /* SSIF_0_SYNC_RESET_SSI9 */
+ DEF_RST(14, 12, 6, 29), /* SCU_RESET_SRU */
+ DEF_RST(14, 13, 6, 30), /* ADMAC_ARESETN */
+ DEF_RST(14, 14, 6, 31), /* ADG_RST_RESET_ADG */
DEF_RST(15, 8, 7, 9), /* TSU_1_PRESETN */
};
--
2.25.1
^ permalink raw reply related
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