* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom: add IPQ9650 pinctrl
From: Krzysztof Kozlowski @ 2026-04-16 9:30 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260415-ipq9650_tlmm-v1-1-bd16ccb06332@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 04:59:24PM +0530, Kathiravan Thirumoorthy wrote:
> Add device tree bindings for IPQ9650 TLMM block.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> .../bindings/pinctrl/qcom,ipq9650-tlmm.yaml | 118 +++++++++++++++++++++
> 1 file changed, 118 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: clock: add Qualcomm IPQ9650 GCC
From: Krzysztof Kozlowski @ 2026-04-16 9:33 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260415-ipq9650_boot_to_shell-v1-1-b37eb4c3a1d1@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 07:03:16PM +0530, Kathiravan Thirumoorthy wrote:
> Add binding for the Qualcomm IPQ9650 Global Clock Controller.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,ipq9650-gcc.yaml | 68 ++++++
> include/dt-bindings/clock/qcom,ipq9650-gcc.h | 190 +++++++++++++++++
> include/dt-bindings/reset/qcom,ipq9650-gcc.h | 228 +++++++++++++++++++++
> 3 files changed, 486 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: interrupt-controller: repurpose binding for unreleased jh8100 for jhb100
From: Changhuang Liang @ 2026-04-16 6:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260416064751.632138-1-changhuang.liang@starfivetech.com>
The StarFive JH8100 SoC was discontinued before production. The
newly taped-out JHB100 SoC uses the same interrupt controller IP.
Rename the binding file, compatible string, and MAINTAINERS entry
from "jh8100" to "jhb100". In JHB100 SoC, The clocks and resets are
not operated by users, but they exist in the hardware. Mark them as
optional.
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
...00-intc.yaml => starfive,jhb100-intc.yaml} | 20 ++++---------------
MAINTAINERS | 2 +-
2 files changed, 5 insertions(+), 17 deletions(-)
rename Documentation/devicetree/bindings/interrupt-controller/{starfive,jh8100-intc.yaml => starfive,jhb100-intc.yaml} (68%)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
similarity index 68%
rename from Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
rename to Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
index ada5788602d6..d8a0a3862ae2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
@@ -1,13 +1,13 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/interrupt-controller/starfive,jh8100-intc.yaml#
+$id: http://devicetree.org/schemas/interrupt-controller/starfive,jhb100-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: StarFive External Interrupt Controller
description:
- StarFive SoC JH8100 contain a external interrupt controller. It can be used
+ StarFive SoC JHB100 contain a external interrupt controller. It can be used
to handle high-level input interrupt signals. It also send the output
interrupt signal to RISC-V PLIC.
@@ -16,19 +16,11 @@ maintainers:
properties:
compatible:
- const: starfive,jh8100-intc
+ const: starfive,jhb100-intc
reg:
maxItems: 1
- clocks:
- description: APB clock for the interrupt controller
- maxItems: 1
-
- resets:
- description: APB reset for the interrupt controller
- maxItems: 1
-
interrupts:
maxItems: 1
@@ -40,8 +32,6 @@ properties:
required:
- compatible
- reg
- - clocks
- - resets
- interrupts
- interrupt-controller
- "#interrupt-cells"
@@ -51,10 +41,8 @@ additionalProperties: false
examples:
- |
interrupt-controller@12260000 {
- compatible = "starfive,jh8100-intc";
+ compatible = "starfive,jhb100-intc";
reg = <0x12260000 0x10000>;
- clocks = <&syscrg_ne 76>;
- resets = <&syscrg_ne 13>;
interrupts = <45>;
interrupt-controller;
#interrupt-cells = <1>;
diff --git a/MAINTAINERS b/MAINTAINERS
index d238590a31f2..a2961727e3d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25312,7 +25312,7 @@ F: drivers/phy/starfive/phy-jh7110-usb.c
STARFIVE JH8100 EXTERNAL INTERRUPT CONTROLLER DRIVER
M: Changhuang Liang <changhuang.liang@starfivetech.com>
S: Supported
-F: Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
+F: Documentation/devicetree/bindings/interrupt-controller/starfive,jhb100-intc.yaml
F: drivers/irqchip/irq-starfive-jh8100-intc.c
STATIC BRANCH/CALL
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 3/5] dt-bindings: qcom: add IPQ9650 boards
From: Krzysztof Kozlowski @ 2026-04-16 9:34 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260415-ipq9650_boot_to_shell-v1-3-b37eb4c3a1d1@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 07:03:18PM +0530, Kathiravan Thirumoorthy wrote:
> Document the new IPQ9650 SoC/board device tree bindings.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 3/5] irqchip/starfive: Use devm_ interfaces to simplify resource release
From: Changhuang Liang @ 2026-04-16 6:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260416064751.632138-1-changhuang.liang@starfivetech.com>
Use devm_ interfaces to simplify resource release. Make clock and reset
get optional as they are not used on the JHB100 SoC. Replace pr_ logging
with dev_* logging. Use __free(kfree) cleanup attribute to auto-free irqc
on error paths
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
drivers/irqchip/irq-starfive-jhb100-intc.c | 77 ++++++----------------
1 file changed, 20 insertions(+), 57 deletions(-)
diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
index 2c9cdad7f377..c33229b39a40 100644
--- a/drivers/irqchip/irq-starfive-jhb100-intc.c
+++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
@@ -7,16 +7,15 @@
* Author: Changhuang Liang <changhuang.liang@starfivetech.com>
*/
-#define pr_fmt(fmt) "irq-starfive-jhb100: " fmt
-
#include <linux/bitops.h>
+#include <linux/cleanup.h>
#include <linux/clk.h>
#include <linux/irq.h>
#include <linux/irqchip.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
-#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/platform_device.h>
#include <linux/reset.h>
#include <linux/spinlock.h>
@@ -117,85 +116,49 @@ static void starfive_intc_irq_handler(struct irq_desc *desc)
static int starfive_intc_probe(struct platform_device *pdev, struct device_node *parent)
{
struct device_node *intc = pdev->dev.of_node;
- struct starfive_irq_chip *irqc;
struct reset_control *rst;
struct clk *clk;
int parent_irq;
- int ret;
- irqc = kzalloc_obj(*irqc);
+ struct starfive_irq_chip *irqc __free(kfree) = kzalloc_obj(*irqc);
if (!irqc)
return -ENOMEM;
- irqc->base = of_iomap(intc, 0);
- if (!irqc->base) {
- pr_err("Unable to map registers\n");
- ret = -ENXIO;
- goto err_free;
- }
+ irqc->base = devm_platform_ioremap_resource(pdev, 0);
+ if (!irqc->base)
+ return dev_err_probe(&pdev->dev, -ENXIO, "unable to map registers\n");
- rst = of_reset_control_get_exclusive(intc, NULL);
- if (IS_ERR(rst)) {
- pr_err("Unable to get reset control %pe\n", rst);
- ret = PTR_ERR(rst);
- goto err_unmap;
- }
+ rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev, NULL);
+ if (IS_ERR(rst))
+ return dev_err_probe(&pdev->dev, PTR_ERR(rst),
+ "Unable to get and deassert reset control\n");
- clk = of_clk_get(intc, 0);
- if (IS_ERR(clk)) {
- pr_err("Unable to get clock %pe\n", clk);
- ret = PTR_ERR(clk);
- goto err_reset_put;
- }
+ clk = devm_clk_get_optional_enabled(&pdev->dev, NULL);
+ if (IS_ERR(clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(clk), "Unable to get and enable clock\n");
- ret = reset_control_deassert(rst);
- if (ret)
- goto err_clk_put;
-
- ret = clk_prepare_enable(clk);
- if (ret)
- goto err_reset_assert;
raw_spin_lock_init(&irqc->lock);
irqc->domain = irq_domain_create_linear(of_fwnode_handle(intc), STARFIVE_INTC_SRC_IRQ_NUM,
&starfive_intc_domain_ops, irqc);
- if (!irqc->domain) {
- pr_err("Unable to create IRQ domain\n");
- ret = -EINVAL;
- goto err_clk_disable;
- }
+ if (!irqc->domain)
+ return dev_err_probe(&pdev->dev, -EINVAL, "Unable to create IRQ domain\n");
parent_irq = of_irq_get(intc, 0);
if (parent_irq < 0) {
- pr_err("Failed to get main IRQ: %d\n", parent_irq);
- ret = parent_irq;
- goto err_remove_domain;
+ irq_domain_remove(irqc->domain);
+ return dev_err_probe(&pdev->dev, parent_irq, "Failed to get main IRQ\n");
}
irq_set_chained_handler_and_data(parent_irq, starfive_intc_irq_handler,
irqc);
- pr_info("Interrupt controller register, nr_irqs %d\n",
- STARFIVE_INTC_SRC_IRQ_NUM);
+ dev_info(&pdev->dev, "Interrupt controller register, nr_irqs %d\n",
+ STARFIVE_INTC_SRC_IRQ_NUM);
+ retain_and_null_ptr(irqc);
return 0;
-
-err_remove_domain:
- irq_domain_remove(irqc->domain);
-err_clk_disable:
- clk_disable_unprepare(clk);
-err_reset_assert:
- reset_control_assert(rst);
-err_clk_put:
- clk_put(clk);
-err_reset_put:
- reset_control_put(rst);
-err_unmap:
- iounmap(irqc->base);
-err_free:
- kfree(irqc);
- return ret;
}
IRQCHIP_PLATFORM_DRIVER_BEGIN(starfive_intc)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 4/5] arm64: dts: qcom: add IPQ9650 SoC and rdp488 board support
From: Krzysztof Kozlowski @ 2026-04-16 9:35 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260415-ipq9650_boot_to_shell-v1-4-b37eb4c3a1d1@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 07:03:19PM +0530, Kathiravan Thirumoorthy wrote:
> + xo_board: xo-board-clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + };
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + CPU0: cpu@0 {
Labels should be lowercase.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: sound: mt2701-afe-pcm: add HDMI audio path clocks
From: Krzysztof Kozlowski @ 2026-04-16 9:38 UTC (permalink / raw)
To: Daniel Golle
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Nícolas F. R. A. Prado, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <50afd83a314cd20c715fb9b0d3bc85fb00f9a6eb.1776265610.git.daniel@makrotopia.org>
On Wed, Apr 15, 2026 at 04:23:27PM +0100, Daniel Golle wrote:
> Document four additional optional clocks feeding the HDMI audio
> output path on MT2701 and MT7623N: the HADDS2 PLL (root of the
There is no MT7623N compatible in this file, so that's confusing. Does
mt7622 have it? If not, then it should be restricted per variant. If
yet, the model name is confusing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Xuyang Dong @ 2026-04-16 9:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley
Cc: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel, ningyu, linmin, xuxiang,
wangguosheng, pinkesh.vaghela
In-Reply-To: <20260416-wandering-solemn-uakari-083ae7@quoll>
> > >
> > > The DesignWare PWM includes separate reset signals dedicated to each clock
> > > domain:
> > > The presetn signal resets logic in pclk domain.
> > > The timer_N_resetn signal resets logic in the timer_N_clk domain.
> > > The resets are active-low.
> > >
> > > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> >
> > This commit implies that your hardware differs from existing devices,
> > I think you should add a device-specific compatible.
> >
Hi Conor and Krzysztof,
The DesignWare PWM Databook for 2.13a says: "The DW_apb_timers includes
separate reset signals dedicated to each clock domain". They are:
The presetn signal resets logic in pclk domain (i.e., the bus clock in DT).
The timer_N_resetn signal resets logic in the timer_N_clk domain (i.e.,
the timer clock in DT).
These reset signals are optional; it is up to the designer's
implementation.
According to [1], the applied YAML is also based on 2.13a, so our
hardware is the same as the existing devices. It's just that these two
reset signals were missing from the original YAML binding.
[1] https://lore.kernel.org/linux-pwm/8bb5103d-803e-90d2-fd93-132bb2aac2d6@sifive.com/
> > > ---
> > > .../devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > index 7523a89a1773..a8bbad0360f8 100644
> > > --- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > +++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> > > @@ -43,6 +43,9 @@ properties:
> > > - const: bus
> > > - const: timer
> > >
> > > + resets:
> > > + maxItems: 2
>
> And this should really be listed with description, because order is
> fixed.
>
The description of resets will be listed in next version.
Best regards,
Xuyang Dong
^ permalink raw reply
* [PATCH v2 0/3] Describe IMEM on Eliza
From: Alexander Koskovich @ 2026-04-16 9:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, Alexander Koskovich
Add a compatible and describe the IMEM for the Eliza SoC.
Also sort nodes by unit address.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Changes in v2:
- Fix sorting of nodes in eliza.dtsi
- Link to v1: https://lore.kernel.org/r/20260415-eliza-imem-v1-0-4a90e8683799@pm.me
---
Alexander Koskovich (3):
arm64: dts: qcom: eliza: Sort nodes by unit address
dt-bindings: sram: Document qcom,eliza-imem
arm64: dts: qcom: eliza: Add IMEM node
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
arch/arm64/boot/dts/qcom/eliza.dtsi | 94 ++++++++++++++----------
2 files changed, 58 insertions(+), 37 deletions(-)
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260415-eliza-imem-e791f44abf1b
Best regards,
--
Alexander Koskovich <akoskovich@pm.me>
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: qcom: eliza: Sort nodes by unit address
From: Alexander Koskovich @ 2026-04-16 9:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, Alexander Koskovich
In-Reply-To: <20260416-eliza-imem-v2-0-fb7a71123451@pm.me>
Qualcomm DTS uses sorting of MMIO nodes by the unit address, so move
few nodes in Eliza DTSI to fix that.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 74 ++++++++++++++++++-------------------
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 4a7a0ac40ce6..6fa5679c1a62 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -662,16 +662,16 @@ &clk_virt SLAVE_QUP_CORE_2 QCOM_ICC_TAG_ALWAYS>,
};
};
- config_noc: interconnect@1600000 {
- compatible = "qcom,eliza-cnoc-cfg";
- reg = <0x0 0x01600000 0x0 0x5200>;
+ cnoc_main: interconnect@1500000 {
+ compatible = "qcom,eliza-cnoc-main";
+ reg = <0x0 0x01500000 0x0 0x16080>;
qcom,bcm-voters = <&apps_bcm_voter>;
#interconnect-cells = <2>;
};
- cnoc_main: interconnect@1500000 {
- compatible = "qcom,eliza-cnoc-main";
- reg = <0x0 0x01500000 0x0 0x16080>;
+ config_noc: interconnect@1600000 {
+ compatible = "qcom,eliza-cnoc-cfg";
+ reg = <0x0 0x01600000 0x0 0x5200>;
qcom,bcm-voters = <&apps_bcm_voter>;
#interconnect-cells = <2>;
};
@@ -862,13 +862,6 @@ tcsr: clock-controller@1fbf000 {
#reset-cells = <1>;
};
- lpass_ag_noc: interconnect@7e40000 {
- compatible = "qcom,eliza-lpass-ag-noc";
- reg = <0x0 0x07e40000 0x0 0xe080>;
- qcom,bcm-voters = <&apps_bcm_voter>;
- #interconnect-cells = <2>;
- };
-
lpass_lpiaon_noc: interconnect@7400000 {
compatible = "qcom,eliza-lpass-lpiaon-noc";
reg = <0x0 0x07400000 0x0 0x19080>;
@@ -883,6 +876,13 @@ lpass_lpicx_noc: interconnect@7420000 {
#interconnect-cells = <2>;
};
+ lpass_ag_noc: interconnect@7e40000 {
+ compatible = "qcom,eliza-lpass-ag-noc";
+ reg = <0x0 0x07e40000 0x0 0xe080>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ #interconnect-cells = <2>;
+ };
+
pdc: interrupt-controller@b220000 {
compatible = "qcom,eliza-pdc", "qcom,pdc";
reg = <0x0 0x0b220000 0x0 0x40000>,
@@ -1005,6 +1005,30 @@ spmi_bus1: spmi@c432000 {
};
};
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,eliza-tlmm";
+ reg = <0x0 0x0f100000 0x0 0xf00000>;
+
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio-ranges = <&tlmm 0 0 184>;
+ wakeup-parent = <&pdc>;
+
+ qup_uart14_default: qup-uart14-default-state {
+ /* TX, RX */
+ pins = "gpio18", "gpio19";
+ function = "qup2_se5";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,eliza-smmu-500", "qcom,smmu-500", "arm,mmu-500";
reg = <0x0 0x15000000 0x0 0x100000>;
@@ -1319,30 +1343,6 @@ cpufreq_hw: cpufreq@17d91000 {
#clock-cells = <1>;
};
- tlmm: pinctrl@f100000 {
- compatible = "qcom,eliza-tlmm";
- reg = <0x0 0x0f100000 0x0 0xf00000>;
-
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- gpio-ranges = <&tlmm 0 0 184>;
- wakeup-parent = <&pdc>;
-
- qup_uart14_default: qup-uart14-default-state {
- /* TX, RX */
- pins = "gpio18", "gpio19";
- function = "qup2_se5";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
-
gem_noc: interconnect@24100000 {
compatible = "qcom,eliza-gem-noc";
reg = <0x0 0x24100000 0x0 0x163080>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: sram: Document qcom,eliza-imem
From: Alexander Koskovich @ 2026-04-16 9:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, Alexander Koskovich
In-Reply-To: <20260416-eliza-imem-v2-0-fb7a71123451@pm.me>
Add compatible for Eliza SoC IMEM.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 8985f89170be..27e5e274c3cb 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -34,6 +34,7 @@ properties:
- nvidia,tegra186-sysram
- nvidia,tegra194-sysram
- nvidia,tegra234-sysram
+ - qcom,eliza-imem
- qcom,hawi-imem
- qcom,kaanapali-imem
- qcom,milos-imem
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: qcom: eliza: Add IMEM node
From: Alexander Koskovich @ 2026-04-16 9:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, Alexander Koskovich
In-Reply-To: <20260416-eliza-imem-v2-0-fb7a71123451@pm.me>
Add a node for the IMEM found on Eliza, which contains pil-reloc-info
and the modem tables for IPA, among others.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 6fa5679c1a62..551df07e44c6 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -1029,6 +1029,26 @@ qup_uart14_default: qup-uart14-default-state {
};
};
+ sram@14680000 {
+ compatible = "qcom,eliza-imem", "mmio-sram";
+ reg = <0x0 0x14680000 0x0 0x2c000>;
+ ranges = <0x0 0x0 0x14680000 0x2c000>;
+
+ no-memory-wc;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pilreloc-sram@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+
+ ipa_modem_tables: modem-tables-sram@3000 {
+ reg = <0x3000 0x2000>;
+ };
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,eliza-smmu-500", "qcom,smmu-500", "arm,mmu-500";
reg = <0x0 0x15000000 0x0 0x100000>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFT] arm64: dts: qcom: sm8650: Fix IPA IMEM slice
From: Konrad Dybcio @ 2026-04-16 9:41 UTC (permalink / raw)
To: Alexander Koskovich, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260415-fix-8650-ipa-modem-tables-v1-1-95f8f425e416@pm.me>
On 4/16/26 1:45 AM, Alexander Koskovich wrote:
> Downstream the IPA IMEM slice for SM8650 is described as:
> qcom,additional-mapping = <0x14683000 0x14683000 0x2000>;
>
> Update upstream ipa_modem_tables to reflect downstream.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Thanks for catching this!
Fixes: 581fc5d5ade6 ("arm64: dts: qcom: sm8650: Explicitly describe the IPA IMEM slice")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [PATCH] arm64: dts: renesas: rzt2h-n2h-evk: Configure eMMC/SDHI pins
From: Fabrizio Castro @ 2026-04-16 9:48 UTC (permalink / raw)
To: Fabrizio Castro, Geert Uytterhoeven, magnus.damm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Biju Das, Prabhakar Mahadev Lad
In-Reply-To: <20260331145221.7974-1-fabrizio.castro.jz@renesas.com>
Hi Geert,
Are you happy with this patch?
Without this patch fast SD cards/eMMCs may fail on the RZ/T2H and RZ/N2H.
If it helps, we may also add a couple of fixes tags to the patch, to fast
track it:
Fixes: 4d7624fc85a2 ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable eMMC")
Fixes: dba8ee27c5de ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable MicroSD card slot")
I haven't added them to the patch because I wanted to avoid being selected
for stable, as it depends on the below series:
https://lore.kernel.org/linux-renesas-soc/20260319141515.2053556-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
Cheers,
Fab
> From: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> Sent: 31 March 2026 15:52
> To: Geert Uytterhoeven <geert+renesas@glider.be>; magnus.damm <magnus.damm@gmail.com>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>
> Cc: Fabrizio Castro <fabrizio.castro.jz@renesas.com>; linux-renesas-soc@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Biju Das <biju.das.jz@bp.renesas.com>;
> Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Subject: [PATCH] arm64: dts: renesas: rzt2h-n2h-evk: Configure eMMC/SDHI pins
>
> The HW user manual for the Renesas RZ/T2H and the RZ/N2H state
> that for SDR104, SDR50, and HS200 to work properly the eMMC/SDHI
> interface pins have to be configured as specified below:
> * SDn_CLK pin - drive strength: Ultra High, slew rate: fast
> * Other SDn_* pins: drive strength: High, slew rate: fast,
> Schmitt trigger: disabled (not applicable to SDn_RST pins).
>
> Adjust the pin definitions accordingly.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> .../dts/renesas/rzt2h-n2h-evk-common.dtsi | 54 ++++++++++++++++---
> 1 file changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi b/arch/arm64/boot/dts/renesas/rzt2h-
> n2h-evk-common.dtsi
> index f87c2492f414..3fae950db603 100644
> --- a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
> @@ -275,12 +275,28 @@ data-pins {
> <RZT2H_PORT_PINMUX(12, 7, 0x29)>, /* SD0_DATA5 */
> <RZT2H_PORT_PINMUX(13, 0, 0x29)>, /* SD0_DATA6 */
> <RZT2H_PORT_PINMUX(13, 1, 0x29)>; /* SD0_DATA7 */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> };
>
> - ctrl-pins {
> - pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
> - <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
> - <RZT2H_PORT_PINMUX(13, 2, 0x29)>; /* SD0_RST# */
> + clk-pins {
> + pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>; /* SD0_CLK */
> + drive-strength-microamp = <11800>;
> + slew-rate = <1>;
> + };
> +
> + cmd-pins {
> + pinmux = <RZT2H_PORT_PINMUX(12, 1, 0x29)>; /* SD0_CMD */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> + };
> +
> + rst-pins {
> + pinmux = <RZT2H_PORT_PINMUX(13, 2, 0x29)>; /* SD0_RST# */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> };
> };
>
> @@ -299,12 +315,23 @@ data-pins {
> <RZT2H_PORT_PINMUX(12, 3, 0x29)>, /* SD0_DATA1 */
> <RZT2H_PORT_PINMUX(12, 4, 0x29)>, /* SD0_DATA2 */
> <RZT2H_PORT_PINMUX(12, 5, 0x29)>; /* SD0_DATA3 */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> + };
> +
> + clk-pins {
> + pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>; /* SD0_CLK */
> + drive-strength-microamp = <11800>;
> + slew-rate = <1>;
> };
>
> ctrl-pins {
> - pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
> - <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
> + pinmux = <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
> <RZT2H_PORT_PINMUX(22, 5, 0x29)>; /* SD0_CD */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> };
> };
>
> @@ -323,12 +350,23 @@ data-pins {
> <RZT2H_PORT_PINMUX(17, 0, 0x29)>, /* SD1_DATA1 */
> <RZT2H_PORT_PINMUX(17, 1, 0x29)>, /* SD1_DATA2 */
> <RZT2H_PORT_PINMUX(17, 2, 0x29)>; /* SD1_DATA3 */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> + };
> +
> + clk-pins {
> + pinmux = <RZT2H_PORT_PINMUX(16, 5, 0x29)>; /* SD1_CLK */
> + drive-strength-microamp = <11800>;
> + slew-rate = <1>;
> };
>
> ctrl-pins {
> - pinmux = <RZT2H_PORT_PINMUX(16, 5, 0x29)>, /* SD1_CLK */
> - <RZT2H_PORT_PINMUX(16, 6, 0x29)>, /* SD1_CMD */
> + pinmux = <RZT2H_PORT_PINMUX(16, 6, 0x29)>, /* SD1_CMD */
> <RZT2H_PORT_PINMUX(17, 4, 0x29)>; /* SD1_CD */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> };
> };
> };
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH 4/5] arm64: dts: qcom: add IPQ9650 SoC and rdp488 board support
From: Kathiravan Thirumoorthy @ 2026-04-16 9:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260416-khaki-goose-of-will-ec76bf@quoll>
On 4/16/2026 3:05 PM, Krzysztof Kozlowski wrote:
> On Wed, Apr 15, 2026 at 07:03:19PM +0530, Kathiravan Thirumoorthy wrote:
>> + xo_board: xo-board-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + };
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + CPU0: cpu@0 {
> Labels should be lowercase.
Ack.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v2 0/2] rtc: bq32000: Add settle delay for aggressive polling
From: Adriana Stancu @ 2026-04-16 9:57 UTC (permalink / raw)
To: alexandre.belloni
Cc: linux-rtc, devicetree, linux-kernel, robh, krzk+dt, conor+dt,
Adriana Stancu
In-Reply-To: <20260416092414.3210383-1-adriana@arista.com>
This series addresses a limitation in the TI BQ32000 RTC where aggressive
I2C polling (done by userspace tools like hwclock on systems where the
interrupt line is not connected to the CPU) can prevent the refresh of
RTC registers.
This results in stale data reads or select() timeouts in userspace. The
series introduces a configurable "settle delay" via device tree to ensure
that the hardware has sufficient idle time between read attempts.
Patch 1: Adds the "ti,read-settle-us" property to the YAML bindings.
Patch 2: Implements the delay in the driver using usleep_range.
Changes in v2:
- Expanded dt-binding property description to explain use case.
- Updated commit messages on dt change to describe the scenario when the
dt property would be necessary.
- Reword the commit messages to respect wrapping at 75 columns.
Adriana Stancu (2):
dt-bindings: rtc: ti,bq32k: Add delay on rtc reads
rtc: bq32000: add configurable delay between RTC reads
.../devicetree/bindings/rtc/ti,bq32000.yaml | 9 +++++
drivers/rtc/rtc-bq32k.c | 34 +++++++++++++++----
2 files changed, 37 insertions(+), 6 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: rtc: ti,bq32k: Add delay on rtc reads
From: Adriana Stancu @ 2026-04-16 9:57 UTC (permalink / raw)
To: alexandre.belloni
Cc: linux-rtc, devicetree, linux-kernel, robh, krzk+dt, conor+dt,
Adriana Stancu
In-Reply-To: <20260416095706.3212158-1-adriana@arista.com>
Add a configurable "ti,read-settle-us" property to resolve a limitation
where aggressive I2C polling prevents the BQ32000's internal register to
update. This ensures the hardware has sufficient idle time to update its
buffer, preventing stale data reads on systems where the "interrupts" are
not configured.
Signed-off-by: Adriana Stancu <adriana@arista.com>
---
Documentation/devicetree/bindings/rtc/ti,bq32000.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml b/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml
index bf9c1c4ddb7e..46403f0c85a5 100644
--- a/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml
+++ b/Documentation/devicetree/bindings/rtc/ti,bq32000.yaml
@@ -29,6 +29,15 @@ properties:
trickle-diode-disable: true
+ ti,read-settle-us:
+ default: 0
+ description:
+ Delay in microseconds to wait before reading RTC registers.
+ Aggressive I2C polling on systems without an interrupt line
+ can prevent the BQ32000's internal refresh cycle, leading to
+ stale data. This delay ensures the hardware has sufficient
+ idle time to update its registers.
+
required:
- compatible
- reg
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/2] rtc: bq32000: add configurable delay between RTC reads
From: Adriana Stancu @ 2026-04-16 9:57 UTC (permalink / raw)
To: alexandre.belloni
Cc: linux-rtc, devicetree, linux-kernel, robh, krzk+dt, conor+dt,
Adriana Stancu
In-Reply-To: <20260416095706.3212158-1-adriana@arista.com>
When the RTC is used on systems without a interrupt line, userspace tools
like "hwclock" fall back to a frequent polling loop to synchronize with
the edge of the next second.
On the BQ32000, this aggressive polling can temporarly lock the register
refresh cycle, because the continuous transfers prevent the hardware from
updating the buffer. This results in stale data reads or select() timeouts
in userspace.
This patch introduces a configurable settle delay via "ti,read-settle-us"
property. If this property is specified, the driver uses a delay before
reading the RTC registers. This provides a sufficient idle time for the
hardware to sync with the register buffer.
Signed-off-by: Adriana Stancu <adriana@arista.com>
---
drivers/rtc/rtc-bq32k.c | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-bq32k.c b/drivers/rtc/rtc-bq32k.c
index 7ad34539be4d..0cbfa0909732 100644
--- a/drivers/rtc/rtc-bq32k.c
+++ b/drivers/rtc/rtc-bq32k.c
@@ -16,6 +16,7 @@
#include <linux/kstrtox.h>
#include <linux/errno.h>
#include <linux/bcd.h>
+#include <linux/delay.h>
#define BQ32K_SECONDS 0x00 /* Seconds register address */
#define BQ32K_SECONDS_MASK 0x7F /* Mask over seconds value */
@@ -48,6 +49,11 @@ struct bq32k_regs {
uint8_t years;
};
+struct bq32k_data {
+ struct rtc_device *rtc;
+ u32 read_delay_us;
+};
+
static struct i2c_driver bq32k_driver;
static int bq32k_read(struct device *dev, void *data, uint8_t off, uint8_t len)
@@ -89,9 +95,17 @@ static int bq32k_write(struct device *dev, void *data, uint8_t off, uint8_t len)
static int bq32k_rtc_read_time(struct device *dev, struct rtc_time *tm)
{
+ struct bq32k_data *bq32k = dev_get_drvdata(dev);
struct bq32k_regs regs;
int error;
+ /*
+ * When the device doesn't have the interrupt connected, prevent
+ * userpace from polling the RTC registers to frequently.
+ */
+ if (bq32k && bq32k->read_delay_us)
+ usleep_range(bq32k->read_delay_us, bq32k->read_delay_us + 50);
+
error = bq32k_read(dev, ®s, 0, sizeof(regs));
if (error)
return error;
@@ -253,13 +267,18 @@ static void bq32k_sysfs_unregister(struct device *dev)
static int bq32k_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
- struct rtc_device *rtc;
+ struct bq32k_data *bq32k;
uint8_t reg;
int error;
+ uint32_t settle_us = 0;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
+ bq32k = devm_kzalloc(dev, sizeof(*bq32k), GFP_KERNEL);
+ if (!bq32k)
+ return -ENOMEM;
+
/* Check Oscillator Stop flag */
error = bq32k_read(dev, ®, BQ32K_SECONDS, 1);
if (!error && (reg & BQ32K_STOP)) {
@@ -280,10 +299,13 @@ static int bq32k_probe(struct i2c_client *client)
if (client->dev.of_node)
trickle_charger_of_init(dev, client->dev.of_node);
- rtc = devm_rtc_device_register(&client->dev, bq32k_driver.driver.name,
- &bq32k_rtc_ops, THIS_MODULE);
- if (IS_ERR(rtc))
- return PTR_ERR(rtc);
+ bq32k->rtc = devm_rtc_device_register(&client->dev, bq32k_driver.driver.name,
+ &bq32k_rtc_ops, THIS_MODULE);
+ if (IS_ERR(bq32k->rtc))
+ return PTR_ERR(bq32k->rtc);
+
+ device_property_read_u32(dev, "ti,read-settle-us", &settle_us);
+ bq32k->read_delay_us = settle_us;
error = bq32k_sysfs_register(&client->dev);
if (error) {
@@ -293,7 +315,7 @@ static int bq32k_probe(struct i2c_client *client)
}
- i2c_set_clientdata(client, rtc);
+ i2c_set_clientdata(client, bq32k);
return 0;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v1 02/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
From: Jacopo Mondi @ 2026-04-16 10:03 UTC (permalink / raw)
To: Antoine Bouyer
Cc: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern, linux-media,
linux-kernel, devicetree, imx, jai.luthra, paul.elder
In-Reply-To: <20260413160331.2611829-3-antoine.bouyer@nxp.com>
Hello Antoine,
thanks for the update
On Mon, Apr 13, 2026 at 06:03:22PM +0200, Antoine Bouyer wrote:
> Extend the v4l2-isp extensible format introduced for isp parameters buffer
> to the statistics buffer as well.
>
> Like for ISP configuration purpose, that will help supporting various ISP
> hardware versions reporting different statistics data with less impact on
> userspace.
>
> The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
> definitions, with similar header, versions and flags. V0 and V1 versions
> are provided to match with params versions. On the other side, ENABLE and
> DISABLE flags are not really meaningfull for statistics purpose. So VALID
> and INVALID flags are introduced. Purpose is to force ISP driver to
> validate a statistics buffer, before it is consumed by userspace.
Is this a leftover ?
I don't see VALID and INVALID in this patch and unless I've missed it
badly I don't see them in the next patches.
I'm fine without them, I'm not sure how you intend to use them to
force drivers to validate a statistics buffer.
>
> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> ---
> include/uapi/linux/media/v4l2-isp.h | 148 +++++++++++++++++++---------
> 1 file changed, 100 insertions(+), 48 deletions(-)
>
> diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
> index 779168f9058e..e84476280d43 100644
> --- a/include/uapi/linux/media/v4l2-isp.h
> +++ b/include/uapi/linux/media/v4l2-isp.h
> @@ -13,25 +13,33 @@
> #include <linux/types.h>
>
> /**
> - * enum v4l2_isp_params_version - V4L2 ISP parameters versioning
> + * enum v4l2_isp_version - V4L2 ISP serialization format versioning
> *
> - * @V4L2_ISP_PARAMS_VERSION_V0: First version of the V4L2 ISP parameters format
> - * (for compatibility)
> - * @V4L2_ISP_PARAMS_VERSION_V1: First version of the V4L2 ISP parameters format
> + * @V4L2_ISP_VERSION_V0: First version of the V4L2 ISP serialization format
> + * (for compatibility)
> + * @V4L2_ISP_VERSION_V1: First version of the V4L2 ISP serialization format
> *
> * V0 and V1 are identical in order to support drivers compatible with the V4L2
> - * ISP parameters format already upstreamed which use either 0 or 1 as their
> - * versioning identifier. Both V0 and V1 refers to the first version of the
> - * V4L2 ISP parameters format.
> + * ISP format already upstreamed which use either 0 or 1 as their versioning
> + * identifier. Both V0 and V1 refers to the first version of the V4L2 ISP
> + * serialization format.
> *
> - * Future revisions of the V4L2 ISP parameters format should start from the
> + * Future revisions of the V4L2 ISP serialization format should start from the
> * value of 2.
> */
> -enum v4l2_isp_params_version {
> - V4L2_ISP_PARAMS_VERSION_V0 = 0,
> - V4L2_ISP_PARAMS_VERSION_V1
> +enum v4l2_isp_version {
> + V4L2_ISP_VERSION_V0 = 0,
> + V4L2_ISP_VERSION_V1
> };
>
> +/*
> + * Compatibility with existing users of v4l2_isp_params which pre-date the
> + * introduction of v4l2_isp_stats.
> + */
> +#define v4l2_isp_params_version v4l2_isp_version
> +#define V4L2_ISP_PARAMS_VERSION_V0 V4L2_ISP_VERSION_V0
> +#define V4L2_ISP_PARAMS_VERSION_V1 V4L2_ISP_VERSION_V1
> +
> #define V4L2_ISP_PARAMS_FL_BLOCK_DISABLE (1U << 0)
> #define V4L2_ISP_PARAMS_FL_BLOCK_ENABLE (1U << 1)
>
> @@ -39,64 +47,108 @@ enum v4l2_isp_params_version {
> * Reserve the first 8 bits for V4L2_ISP_PARAMS_FL_* flag.
> *
> * Driver-specific flags should be defined as:
> - * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(0))
> - * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(1))
> + * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_FL_DRIVER_FLAGS(0))
> + * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_FL_DRIVER_FLAGS(1))
> */
> -#define V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(n) ((n) + 8)
> +#define V4L2_ISP_FL_DRIVER_FLAGS(n) ((n) + 8)
>
> /**
> - * struct v4l2_isp_params_block_header - V4L2 extensible parameters block header
> - * @type: The parameters block type (driver-specific)
> + * struct v4l2_isp_block_header - V4L2 extensible block header
> + * @type: The parameters or statistics block type (driver-specific)
> * @flags: A bitmask of block flags (driver-specific)
> - * @size: Size (in bytes) of the parameters block, including this header
> + * @size: Size (in bytes) of the block, including this header
> *
> - * This structure represents the common part of all the ISP configuration
> - * blocks. Each parameters block shall embed an instance of this structure type
> - * as its first member, followed by the block-specific configuration data.
> + * This structure represents the common part of all the ISP configuration or
> + * statistic blocks. Each block shall embed an instance of this structure type
> + * as its first member, followed by the block-specific configuration or
> + * statistic data.
> *
> * The @type field is an ISP driver-specific value that identifies the block
> - * type. The @size field specifies the size of the parameters block.
> - *
> - * The @flags field is a bitmask of per-block flags V4L2_PARAMS_ISP_FL_* and
> - * driver-specific flags specified by the driver header.
> + * type. The @size field specifies the size of the block, including this
> + * header.
> */
> -struct v4l2_isp_params_block_header {
> +struct v4l2_isp_block_header {
> __u16 type;
> __u16 flags;
> __u32 size;
> } __attribute__((aligned(8)));
>
> /**
> - * struct v4l2_isp_params_buffer - V4L2 extensible parameters configuration
> - * @version: The parameters buffer version (driver-specific)
> - * @data_size: The configuration data effective size, excluding this header
> - * @data: The configuration data
> + * v4l2_isp_params_block_header - V4L2 extensible parameters block header
> *
> - * This structure contains the configuration parameters of the ISP algorithms,
> - * serialized by userspace into a data buffer. Each configuration parameter
> - * block is represented by a block-specific structure which contains a
> - * :c:type:`v4l2_isp_params_block_header` entry as first member. Userspace
> - * populates the @data buffer with configuration parameters for the blocks that
> - * it intends to configure. As a consequence, the data buffer effective size
> - * changes according to the number of ISP blocks that userspace intends to
> - * configure and is set by userspace in the @data_size field.
> - *
> - * The parameters buffer is versioned by the @version field to allow modifying
> - * and extending its definition. Userspace shall populate the @version field to
> - * inform the driver about the version it intends to use. The driver will parse
> - * and handle the @data buffer according to the data layout specific to the
> - * indicated version and return an error if the desired version is not
> + * This structure represents the common part of all the ISP configuration blocks
> + * and is identical to :c:type:`v4l2_isp_block_header`.
> + *
> + * The @flags field is a bitmask of per-block flags V4L2_ISP_PARAMS_FL_* and
> + * driver-specific flags specified by the driver header.
What if we move this to the documentation of struct v4l2_isp_block_header
and we only document the macro for compatibility reasons like you did
for `v4l2_isp_params_version` ?
We could add the above to the documentation of `struct
v4l2_isp_block_header`:
* The @flags field is a bitmask of per-block flags. If a block is used for
* configuration parameters this field can be a combination of
* V4L2_ISP_PARAMS_FL_ and driver-specific flags.
Depending on the answer on VALID/INVALID we can document the usage of
flags for stats as:
* The @flags field is a bitmask of per-block flags. If a block is used for
* configuration parameters this field can be a combination of
* V4L2_ISP_PARAMS_FL_ and driver-specific flags. If a block is used
* for statistics this fields is used to report optional
* driver-specific flags, if any.
> + */
> +#define v4l2_isp_params_block_header v4l2_isp_block_header
If you accept the above suggestion we can simply document this
/**
* v4l2_isp_params_block_header - V4L2 extensible parameters compatibility
*
* Compatibility with existing users of v4l2_isp_params_block_header
* which pre-date the introduction of v4l2_isp_block_header.
*.
> +
> +/**
> + * v4l2_isp_stats_block_header - V4L2 extensible statistics block header
> + *
> + * This structure represents the common part of all the ISP statistics blocks
> + * and is identical to :c:type:`v4l2_isp_block_header`.
> + *
> + * The @flags field is a bitmask of driver-specific flags specified by the
> + * driver header, as there is no generic flags for statistics.
> + */
> +#define v4l2_isp_stats_block_header v4l2_isp_block_header
Do we need this or should we use v4l2_isp_block_header unconditionally ?
> +
> +/**
> + * struct v4l2_isp_buffer - V4L2 extensible buffer
> + * @version: The extensible buffer version (driver-specific)
> + * @data_size: The data effective size, excluding this header
> + * @data: The configuration or statistics data
> + *
> + * This structure contains ISP configuration parameters or ISP hardware
> + * statistics serialized into a data buffer. Each block is represented by a
> + * block-specific structure which contains a :c:type:`v4l2_isp_block_header`
> + * entry as first member.
> + *
> + * For a parameters block, userspace populates the @data buffer with
Or:
* When used for ISP parameters userspace ..
> + * configuration parameters for the blocks that it intends to configure.
> + * As a consequence, the data buffer effective size changes according to the
> + * number of ISP blocks that userspace intends to configure and is set by
> + * userspace in the @data_size field.
> + *
> + * For a statistics block, behavior is the same as for parameters, except that
Or:
* When used to report ISP statistics the driver populates the
* @data buffer with statistics for each supported measurement
* block. The buffer effective size is set by the driver in the
* @data_size field.
> + * buffer is filled by the ISP driver.
> + *
> + * The buffer is versioned by the @version field to allow modifying
> + * and extending its definition. The writer shall populate the @version field
> + * to inform the reader about the version it intends to use. The reader will
> + * parse and handle the @data buffer according to the data layout specific to
> + * the indicated version and return an error if the desired version is not
> * supported.
Ack, I think using "writer" and "reader" is clear enough to support
both the params and stats use case. If we want more clarity we can add
to "driver" and "userspace" a "(role)" in the two previous paragraph.
Something like:
* When used for ISP parameters userspace (the writer) populates
* the @data buffer ...
> *
> - * For each ISP block that userspace wants to configure, a block-specific
> - * structure is appended to the @data buffer, one after the other without gaps
> - * in between. Userspace shall populate the @data_size field with the effective
> - * size, in bytes, of the @data buffer.
> + * For each ISP block, a block-specific structure is appended to the @data
> + * buffer, one after the other without gaps in between. The writer shall
> + * populate the @data_size field with the effective size, in bytes, of the
> + * @data buffer.
If we want to describe @data_size here we can remove it from the above
two paragraphs maybe. I think it's fine to have it here only.
> */
> -struct v4l2_isp_params_buffer {
> +struct v4l2_isp_buffer {
> __u32 version;
> __u32 data_size;
> __u8 data[] __counted_by(data_size);
> };
>
> +/**
> + * v4l2_isp_params_buffer - V4L2 extensible parameters configuration
s/configuration/compatibility
> + *
> + * This structure contains the configuration parameters of the ISP algorithms,
> + * serialized into a data buffer. It is identical to
> + * :c:type:`v4l2_isp_buffer`.
And here only
* Compatibility with existing users of v4l2_isp_params_buffer which
* pre-date the introduction of v4l2_isp_buffer
> + */
> +#define v4l2_isp_params_buffer v4l2_isp_buffer
> +
> +/**
> + * v4l2_isp_stats_buffer - V4L2 extensible statistics buffer
> + *
> + * This structure contains the statistics data from the ISP hardware,
> + * serialized into a data buffer. It is identical to
> + * :c:type:`v4l2_isp_buffer`.
> + */
> +#define v4l2_isp_stats_buffer v4l2_isp_buffer
Same question as per `v4l2_isp_stats_block_header`. Do we need it ?
Thanks
j
> +
> #endif /* _UAPI_V4L2_ISP_H_ */
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: rtc: ti,bq32k: Add delay on rtc reads
From: Alexandre Belloni @ 2026-04-16 10:03 UTC (permalink / raw)
To: Adriana Stancu
Cc: linux-rtc, devicetree, linux-kernel, robh, krzk+dt, conor+dt
In-Reply-To: <20260416095706.3212158-2-adriana@arista.com>
On 16/04/2026 02:57:05-0700, Adriana Stancu wrote:
> Add a configurable "ti,read-settle-us" property to resolve a limitation
> where aggressive I2C polling prevents the BQ32000's internal register to
> update. This ensures the hardware has sufficient idle time to update its
> buffer, preventing stale data reads on systems where the "interrupts" are
> not configured.
>
Why does it need to be configured?
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: qcom: eliza: Sort nodes by unit address
From: Krzysztof Kozlowski @ 2026-04-16 10:04 UTC (permalink / raw)
To: Alexander Koskovich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260416-eliza-imem-v2-1-fb7a71123451@pm.me>
On 16/04/2026 11:39, Alexander Koskovich wrote:
> Qualcomm DTS uses sorting of MMIO nodes by the unit address, so move
> few nodes in Eliza DTSI to fix that.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 74 ++++++++++++++++++-------------------
> 1 file changed, 37 insertions(+), 37 deletions(-)
>
One patchset per 24h.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/8] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Luca Weiss @ 2026-04-16 10:06 UTC (permalink / raw)
To: Dmitry Baryshkov, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Jeff Johnson,
Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Krzysztof Kozlowski,
Bartosz Golaszewski
In-Reply-To: <20260119-wcn3990-pwrctl-v3-3-948df19f5ec2@oss.qualcomm.com>
Hi Dmitry,
On Mon Jan 19, 2026 at 6:07 PM CET, Dmitry Baryshkov wrote:
> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
> voltages over internal rails. Implement support for using powersequencer
> for this family of ATH10k devices in addition to using regulators.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/snoc.c | 53 ++++++++++++++++++++++++++++++++--
> drivers/net/wireless/ath/ath10k/snoc.h | 3 ++
> 2 files changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
> index b3f6424c17d3..f72f236fb9eb 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: ISC
> /*
> * Copyright (c) 2018 The Linux Foundation. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> #include <linux/bits.h>
> @@ -11,6 +12,7 @@
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/property.h>
> +#include <linux/pwrseq/consumer.h>
> #include <linux/regulator/consumer.h>
> #include <linux/remoteproc/qcom_rproc.h>
> #include <linux/of_reserved_mem.h>
> @@ -1023,10 +1025,14 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power on\n");
>
> - ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> + ret = pwrseq_power_on(ar_snoc->pwrseq);
> if (ret)
> return ret;
>
> + ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> + if (ret)
> + goto pwrseq_off;
> +
> ret = clk_bulk_prepare_enable(ar_snoc->num_clks, ar_snoc->clks);
> if (ret)
> goto vreg_off;
> @@ -1035,18 +1041,28 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> vreg_off:
> regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +pwrseq_off:
> + pwrseq_power_off(ar_snoc->pwrseq);
> +
> return ret;
> }
>
> static int ath10k_hw_power_off(struct ath10k *ar)
> {
> struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> + int ret_seq = 0;
> + int ret_vreg;
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power off\n");
>
> clk_bulk_disable_unprepare(ar_snoc->num_clks, ar_snoc->clks);
>
> - return regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> + ret_vreg = regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +
> + if (ar_snoc->pwrseq)
> + ret_seq = pwrseq_power_off(ar_snoc->pwrseq);
> +
> + return ret_vreg ? : ret_seq;
> }
>
> static void ath10k_snoc_wlan_disable(struct ath10k *ar)
> @@ -1762,7 +1778,38 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
> goto err_release_resource;
> }
>
> - ar_snoc->num_vregs = ARRAY_SIZE(ath10k_regulators);
> + /*
> + * devm_pwrseq_get() can return -EPROBE_DEFER in two cases:
> + * - it is not supposed to be used
> + * - it is supposed to be used, but the driver hasn't probed yet.
> + *
> + * There is no simple way to distinguish between these two cases, but:
> + * - if it is not supposed to be used, then regulator_bulk_get() will
> + * return all regulators as expected, continuing the probe
> + * - if it is supposed to be used, but wasn't probed yet, we will get
> + * -EPROBE_DEFER from regulator_bulk_get() too.
> + *
> + * For backwards compatibility with DTs specifying regulators directly
> + * rather than using the PMU device, ignore the defer error from
> + * pwrseq.
> + */
> + ar_snoc->pwrseq = devm_pwrseq_get(&pdev->dev, "wlan");
> + if (IS_ERR(ar_snoc->pwrseq)) {
> + ret = PTR_ERR(ar_snoc->pwrseq);
> + ar_snoc->pwrseq = NULL;
> + if (ret != -EPROBE_DEFER)
> + goto err_free_irq;
I'm fairly sure this is now broken with CONFIG_POWER_SEQUENCING=n since
then pwrseq_get() is returning ERR_PTR(-ENOSYS) which is not handled
here.
I'm observing my ath10k_snoc is now failing to probe "with error -38"
which definitely seems to be related, but I haven't debugged it further
yet.
Regards
Luca
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: eliza: Add IMEM node
From: Krzysztof Kozlowski @ 2026-04-16 10:09 UTC (permalink / raw)
To: Alexander Koskovich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260416-eliza-imem-v2-3-fb7a71123451@pm.me>
On 16/04/2026 11:40, Alexander Koskovich wrote:
> Add a node for the IMEM found on Eliza, which contains pil-reloc-info
> and the modem tables for IPA, among others.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index 6fa5679c1a62..551df07e44c6 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> @@ -1029,6 +1029,26 @@ qup_uart14_default: qup-uart14-default-state {
> };
> };
>
> + sram@14680000 {
> + compatible = "qcom,eliza-imem", "mmio-sram";
> + reg = <0x0 0x14680000 0x0 0x2c000>;
> + ranges = <0x0 0x0 0x14680000 0x2c000>;
> +
> + no-memory-wc;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + pilreloc-sram@94c {
> + compatible = "qcom,pil-reloc-info";
> + reg = <0x94c 0xc8>;
> + };
> +
> + ipa_modem_tables: modem-tables-sram@3000 {
> + reg = <0x3000 0x2000>;
I don't think these two should be in the main SoC DTSI. The non-modem
version obviously does not have modem-tables.
Either this is part of board or common DTSI for SMxxxx SoC. Whatever is
chosen here, should be consistent with other platforms.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 02/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
From: Jacopo Mondi @ 2026-04-16 10:13 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Antoine Bouyer, julien.vuillaumier, alexi.birlinger,
daniel.baluta, peng.fan, frank.li, laurent.pinchart, mchehab,
robh, krzk+dt, conor+dt, michael.riesch, anthony.mcgivern,
linux-media, linux-kernel, devicetree, imx, jai.luthra,
paul.elder
In-Reply-To: <aeCscV9eJbfswiAY@zed>
Hi Antoine
On Thu, Apr 16, 2026 at 12:03:24PM +0200, Jacopo Mondi wrote:
> Hello Antoine,
> thanks for the update
>
> On Mon, Apr 13, 2026 at 06:03:22PM +0200, Antoine Bouyer wrote:
> > Extend the v4l2-isp extensible format introduced for isp parameters buffer
> > to the statistics buffer as well.
> >
> > Like for ISP configuration purpose, that will help supporting various ISP
> > hardware versions reporting different statistics data with less impact on
> > userspace.
> >
> > The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
> > definitions, with similar header, versions and flags. V0 and V1 versions
> > are provided to match with params versions. On the other side, ENABLE and
> > DISABLE flags are not really meaningfull for statistics purpose. So VALID
> > and INVALID flags are introduced. Purpose is to force ISP driver to
> > validate a statistics buffer, before it is consumed by userspace.
>
> Is this a leftover ?
>
> I don't see VALID and INVALID in this patch and unless I've missed it
> badly I don't see them in the next patches.
>
> I'm fine without them, I'm not sure how you intend to use them to
> force drivers to validate a statistics buffer.
>
> >
> > Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> > ---
> > include/uapi/linux/media/v4l2-isp.h | 148 +++++++++++++++++++---------
> > 1 file changed, 100 insertions(+), 48 deletions(-)
> >
> > diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
> > index 779168f9058e..e84476280d43 100644
> > --- a/include/uapi/linux/media/v4l2-isp.h
> > +++ b/include/uapi/linux/media/v4l2-isp.h
> > @@ -13,25 +13,33 @@
> > #include <linux/types.h>
> >
> > /**
> > - * enum v4l2_isp_params_version - V4L2 ISP parameters versioning
> > + * enum v4l2_isp_version - V4L2 ISP serialization format versioning
> > *
> > - * @V4L2_ISP_PARAMS_VERSION_V0: First version of the V4L2 ISP parameters format
> > - * (for compatibility)
> > - * @V4L2_ISP_PARAMS_VERSION_V1: First version of the V4L2 ISP parameters format
> > + * @V4L2_ISP_VERSION_V0: First version of the V4L2 ISP serialization format
> > + * (for compatibility)
> > + * @V4L2_ISP_VERSION_V1: First version of the V4L2 ISP serialization format
> > *
> > * V0 and V1 are identical in order to support drivers compatible with the V4L2
> > - * ISP parameters format already upstreamed which use either 0 or 1 as their
> > - * versioning identifier. Both V0 and V1 refers to the first version of the
> > - * V4L2 ISP parameters format.
> > + * ISP format already upstreamed which use either 0 or 1 as their versioning
> > + * identifier. Both V0 and V1 refers to the first version of the V4L2 ISP
> > + * serialization format.
> > *
> > - * Future revisions of the V4L2 ISP parameters format should start from the
> > + * Future revisions of the V4L2 ISP serialization format should start from the
> > * value of 2.
> > */
> > -enum v4l2_isp_params_version {
> > - V4L2_ISP_PARAMS_VERSION_V0 = 0,
> > - V4L2_ISP_PARAMS_VERSION_V1
> > +enum v4l2_isp_version {
> > + V4L2_ISP_VERSION_V0 = 0,
> > + V4L2_ISP_VERSION_V1
> > };
> >
> > +/*
> > + * Compatibility with existing users of v4l2_isp_params which pre-date the
> > + * introduction of v4l2_isp_stats.
> > + */
> > +#define v4l2_isp_params_version v4l2_isp_version
> > +#define V4L2_ISP_PARAMS_VERSION_V0 V4L2_ISP_VERSION_V0
> > +#define V4L2_ISP_PARAMS_VERSION_V1 V4L2_ISP_VERSION_V1
> > +
> > #define V4L2_ISP_PARAMS_FL_BLOCK_DISABLE (1U << 0)
> > #define V4L2_ISP_PARAMS_FL_BLOCK_ENABLE (1U << 1)
> >
> > @@ -39,64 +47,108 @@ enum v4l2_isp_params_version {
> > * Reserve the first 8 bits for V4L2_ISP_PARAMS_FL_* flag.
> > *
> > * Driver-specific flags should be defined as:
> > - * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(0))
> > - * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(1))
> > + * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_FL_DRIVER_FLAGS(0))
> > + * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_FL_DRIVER_FLAGS(1))
> > */
> > -#define V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(n) ((n) + 8)
> > +#define V4L2_ISP_FL_DRIVER_FLAGS(n) ((n) + 8)
> >
> > /**
> > - * struct v4l2_isp_params_block_header - V4L2 extensible parameters block header
> > - * @type: The parameters block type (driver-specific)
> > + * struct v4l2_isp_block_header - V4L2 extensible block header
> > + * @type: The parameters or statistics block type (driver-specific)
> > * @flags: A bitmask of block flags (driver-specific)
> > - * @size: Size (in bytes) of the parameters block, including this header
> > + * @size: Size (in bytes) of the block, including this header
> > *
> > - * This structure represents the common part of all the ISP configuration
> > - * blocks. Each parameters block shall embed an instance of this structure type
> > - * as its first member, followed by the block-specific configuration data.
> > + * This structure represents the common part of all the ISP configuration or
> > + * statistic blocks. Each block shall embed an instance of this structure type
> > + * as its first member, followed by the block-specific configuration or
> > + * statistic data.
> > *
> > * The @type field is an ISP driver-specific value that identifies the block
> > - * type. The @size field specifies the size of the parameters block.
> > - *
> > - * The @flags field is a bitmask of per-block flags V4L2_PARAMS_ISP_FL_* and
> > - * driver-specific flags specified by the driver header.
> > + * type. The @size field specifies the size of the block, including this
> > + * header.
> > */
> > -struct v4l2_isp_params_block_header {
> > +struct v4l2_isp_block_header {
> > __u16 type;
> > __u16 flags;
> > __u32 size;
> > } __attribute__((aligned(8)));
> >
> > /**
> > - * struct v4l2_isp_params_buffer - V4L2 extensible parameters configuration
> > - * @version: The parameters buffer version (driver-specific)
> > - * @data_size: The configuration data effective size, excluding this header
> > - * @data: The configuration data
> > + * v4l2_isp_params_block_header - V4L2 extensible parameters block header
> > *
> > - * This structure contains the configuration parameters of the ISP algorithms,
> > - * serialized by userspace into a data buffer. Each configuration parameter
> > - * block is represented by a block-specific structure which contains a
> > - * :c:type:`v4l2_isp_params_block_header` entry as first member. Userspace
> > - * populates the @data buffer with configuration parameters for the blocks that
> > - * it intends to configure. As a consequence, the data buffer effective size
> > - * changes according to the number of ISP blocks that userspace intends to
> > - * configure and is set by userspace in the @data_size field.
> > - *
> > - * The parameters buffer is versioned by the @version field to allow modifying
> > - * and extending its definition. Userspace shall populate the @version field to
> > - * inform the driver about the version it intends to use. The driver will parse
> > - * and handle the @data buffer according to the data layout specific to the
> > - * indicated version and return an error if the desired version is not
> > + * This structure represents the common part of all the ISP configuration blocks
> > + * and is identical to :c:type:`v4l2_isp_block_header`.
> > + *
> > + * The @flags field is a bitmask of per-block flags V4L2_ISP_PARAMS_FL_* and
> > + * driver-specific flags specified by the driver header.
>
> What if we move this to the documentation of struct v4l2_isp_block_header
> and we only document the macro for compatibility reasons like you did
> for `v4l2_isp_params_version` ?
>
> We could add the above to the documentation of `struct
> v4l2_isp_block_header`:
>
> * The @flags field is a bitmask of per-block flags. If a block is used for
> * configuration parameters this field can be a combination of
> * V4L2_ISP_PARAMS_FL_ and driver-specific flags.
>
> Depending on the answer on VALID/INVALID we can document the usage of
> flags for stats as:
>
> * The @flags field is a bitmask of per-block flags. If a block is used for
> * configuration parameters this field can be a combination of
> * V4L2_ISP_PARAMS_FL_ and driver-specific flags. If a block is used
Just one note, please use V4L2_ISP_PARAMS_FL_* as otherwise building
documentation will raise warnings.
> * for statistics this fields is used to report optional
> * driver-specific flags, if any.
>
>
> > + */
> > +#define v4l2_isp_params_block_header v4l2_isp_block_header
>
> If you accept the above suggestion we can simply document this
>
> /**
> * v4l2_isp_params_block_header - V4L2 extensible parameters compatibility
> *
> * Compatibility with existing users of v4l2_isp_params_block_header
> * which pre-date the introduction of v4l2_isp_block_header.
> *.
>
> > +
> > +/**
> > + * v4l2_isp_stats_block_header - V4L2 extensible statistics block header
> > + *
> > + * This structure represents the common part of all the ISP statistics blocks
> > + * and is identical to :c:type:`v4l2_isp_block_header`.
> > + *
> > + * The @flags field is a bitmask of driver-specific flags specified by the
> > + * driver header, as there is no generic flags for statistics.
> > + */
> > +#define v4l2_isp_stats_block_header v4l2_isp_block_header
>
> Do we need this or should we use v4l2_isp_block_header unconditionally ?
>
> > +
> > +/**
> > + * struct v4l2_isp_buffer - V4L2 extensible buffer
> > + * @version: The extensible buffer version (driver-specific)
> > + * @data_size: The data effective size, excluding this header
> > + * @data: The configuration or statistics data
> > + *
> > + * This structure contains ISP configuration parameters or ISP hardware
> > + * statistics serialized into a data buffer. Each block is represented by a
> > + * block-specific structure which contains a :c:type:`v4l2_isp_block_header`
> > + * entry as first member.
> > + *
> > + * For a parameters block, userspace populates the @data buffer with
>
> Or:
>
> * When used for ISP parameters userspace ..
>
> > + * configuration parameters for the blocks that it intends to configure.
> > + * As a consequence, the data buffer effective size changes according to the
> > + * number of ISP blocks that userspace intends to configure and is set by
> > + * userspace in the @data_size field.
> > + *
> > + * For a statistics block, behavior is the same as for parameters, except that
>
> Or:
>
> * When used to report ISP statistics the driver populates the
> * @data buffer with statistics for each supported measurement
> * block. The buffer effective size is set by the driver in the
> * @data_size field.
>
> > + * buffer is filled by the ISP driver.
> > + *
> > + * The buffer is versioned by the @version field to allow modifying
> > + * and extending its definition. The writer shall populate the @version field
> > + * to inform the reader about the version it intends to use. The reader will
> > + * parse and handle the @data buffer according to the data layout specific to
> > + * the indicated version and return an error if the desired version is not
> > * supported.
>
> Ack, I think using "writer" and "reader" is clear enough to support
> both the params and stats use case. If we want more clarity we can add
> to "driver" and "userspace" a "(role)" in the two previous paragraph.
> Something like:
>
> * When used for ISP parameters userspace (the writer) populates
> * the @data buffer ...
>
> > *
> > - * For each ISP block that userspace wants to configure, a block-specific
> > - * structure is appended to the @data buffer, one after the other without gaps
> > - * in between. Userspace shall populate the @data_size field with the effective
> > - * size, in bytes, of the @data buffer.
> > + * For each ISP block, a block-specific structure is appended to the @data
> > + * buffer, one after the other without gaps in between. The writer shall
> > + * populate the @data_size field with the effective size, in bytes, of the
> > + * @data buffer.
>
> If we want to describe @data_size here we can remove it from the above
> two paragraphs maybe. I think it's fine to have it here only.
>
> > */
> > -struct v4l2_isp_params_buffer {
> > +struct v4l2_isp_buffer {
> > __u32 version;
> > __u32 data_size;
> > __u8 data[] __counted_by(data_size);
> > };
> >
> > +/**
> > + * v4l2_isp_params_buffer - V4L2 extensible parameters configuration
>
> s/configuration/compatibility
>
> > + *
> > + * This structure contains the configuration parameters of the ISP algorithms,
> > + * serialized into a data buffer. It is identical to
> > + * :c:type:`v4l2_isp_buffer`.
>
> And here only
>
> * Compatibility with existing users of v4l2_isp_params_buffer which
> * pre-date the introduction of v4l2_isp_buffer
>
> > + */
> > +#define v4l2_isp_params_buffer v4l2_isp_buffer
> > +
> > +/**
> > + * v4l2_isp_stats_buffer - V4L2 extensible statistics buffer
> > + *
> > + * This structure contains the statistics data from the ISP hardware,
> > + * serialized into a data buffer. It is identical to
> > + * :c:type:`v4l2_isp_buffer`.
> > + */
> > +#define v4l2_isp_stats_buffer v4l2_isp_buffer
>
> Same question as per `v4l2_isp_stats_block_header`. Do we need it ?
>
> Thanks
> j
>
> > +
> > #endif /* _UAPI_V4L2_ISP_H_ */
> > --
> > 2.51.0
> >
^ permalink raw reply
* Re: [PATCH v3 07/12] rvtrace: Add trace ramsink driver
From: Eric Lin @ 2026-04-16 10:14 UTC (permalink / raw)
To: Anup Patel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Palmer Dabbelt,
Paul Walmsley, Greg KH, Alexander Shishkin, Ian Rogers,
Alexandre Ghiti, Peter Zijlstra, Ingo Molnar, Namhyung Kim,
Mark Rutland, Jiri Olsa, Adrian Hunter, Liang Kan,
Mayuresh Chitale, Anup Patel, Atish Patra, Andrew Jones,
Sunil V L, linux-riscv, devicetree, linux-kernel,
Mayuresh Chitale, Nick Hu, Vincent Chen, Greentime Hu
In-Reply-To: <20260225062448.4027948-8-anup.patel@oss.qualcomm.com>
On Wed, Feb 25, 2026 at 11:54:43AM +0530, Anup Patel wrote:
Hi Anup,
> From: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
>
> Add initial implementation of RISC-V trace ramsink driver. The ramsink
> is defined in the RISC-V Trace Control Interface specification.
>
> Co-developed-by: Anup Patel <anup.patel@oss.qualcomm.com>
> Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com>
> Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
> ---
> drivers/hwtracing/rvtrace/Kconfig | 9 +
> drivers/hwtracing/rvtrace/Makefile | 1 +
> drivers/hwtracing/rvtrace/rvtrace-ramsink.c | 322 ++++++++++++++++++++
> 3 files changed, 332 insertions(+)
> create mode 100644 drivers/hwtracing/rvtrace/rvtrace-ramsink.c
>
> diff --git a/drivers/hwtracing/rvtrace/Kconfig b/drivers/hwtracing/rvtrace/Kconfig
> index ba35c05f3f54..0577f9acb858 100644
> --- a/drivers/hwtracing/rvtrace/Kconfig
> +++ b/drivers/hwtracing/rvtrace/Kconfig
> @@ -21,3 +21,12 @@ config RVTRACE_ENCODER
> default y
> help
> This driver provides support for RISC-V Trace Encoder component.
> +
> +config RVTRACE_RAMSINK
> + tristate "RISC-V Trace Ramsink driver"
> + depends on RVTRACE
> + select DMA_SHARED_BUFFER
> + default y
> + help
> + This driver provides support for Risc-V E-Trace Ramsink
> + component.
> diff --git a/drivers/hwtracing/rvtrace/Makefile b/drivers/hwtracing/rvtrace/Makefile
> index f320693a1fc5..122e575da9fb 100644
> --- a/drivers/hwtracing/rvtrace/Makefile
> +++ b/drivers/hwtracing/rvtrace/Makefile
> @@ -3,3 +3,4 @@
> obj-$(CONFIG_RVTRACE) += rvtrace.o
> rvtrace-y := rvtrace-core.o rvtrace-platform.o
> obj-$(CONFIG_RVTRACE_ENCODER) += rvtrace-encoder.o
> +obj-$(CONFIG_RVTRACE_RAMSINK) += rvtrace-ramsink.o
> diff --git a/drivers/hwtracing/rvtrace/rvtrace-ramsink.c b/drivers/hwtracing/rvtrace/rvtrace-ramsink.c
> new file mode 100644
> index 000000000000..5393423c8f28
> --- /dev/null
> +++ b/drivers/hwtracing/rvtrace/rvtrace-ramsink.c
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2026 Qualcomm Technologies, Inc.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/rvtrace.h>
> +#include <linux/types.h>
> +#include <linux/sizes.h>
> +
> +#define RVTRACE_RAMSINK_STARTLOW_OFF 0x010
> +#define RVTRACE_RAMSINK_STARTHIGH_OFF 0x014
> +#define RVTRACE_RAMSINK_LIMITLOW_OFF 0x018
> +#define RVTRACE_RAMSINK_LIMITHIGH_OFF 0x01c
> +#define RVTRACE_RAMSINK_WPLOW_OFF 0x020
> +#define RVTRACE_RAMSINK_WPHIGH_OFF 0x024
> +#define RVTRACE_RAMSINK_WPLOW_WRAP 0x1
> +#define RVTRACE_RAMSINK_CTRL_MODE_SHIFT 0x4
> +#define RVTRACE_RAMSINK_CTRL_STP_WRAP_SHIFT 0x8
> +
> +enum rvtrace_ramsink_mode {
> + MODE_SRAM,
> + MODE_SMEM
> +};
> +
> +struct rvtrace_ramsink_priv {
> + size_t size;
> + void *va;
> + dma_addr_t start;
> + dma_addr_t end;
> + enum rvtrace_ramsink_mode mode;
> + bool stop_on_wrap;
> + int mem_acc_width;
> +};
> +
> +struct trace_buf {
> + void *base;
> + long cur;
> + size_t len;
> +};
> +
> +static int rvtrace_ramsink_start(struct rvtrace_component *comp)
> +{
> + int ret;
> + u32 val;
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val |= BIT(RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT, 1,
> + comp->pdata->control_poll_timeout_usecs);
> + if (ret)
> + dev_err(&comp->dev, "failed to start ramsink.\n");
> +
> + return ret;
> +}
> +
> +static int rvtrace_ramsink_stop(struct rvtrace_component *comp)
> +{
> + int ret;
> + u32 val;
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val &= ~BIT(RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT, 0,
> + comp->pdata->control_poll_timeout_usecs);
> + if (ret) {
> + dev_err(&comp->dev, "failed to stop ramsink.\n");
> + return ret;
> + }
> +
> + return rvtrace_comp_poll_empty(comp);
> +}
> +
> +static void tbuf_to_pbuf_copy(struct trace_buf *src, struct trace_buf *dst, size_t size)
> +{
> + int bytes_dst, bytes_src, bytes;
> + void *dst_addr, *src_addr;
> +
> + while (size) {
> + src_addr = src->base + src->cur;
> + dst_addr = dst->base + dst->cur;
> +
> + /* Ensure that there are no OOB memory accesses */
> + if (dst->len - dst->cur < size)
> + bytes_dst = dst->len - dst->cur;
> + else
> + bytes_dst = size;
> +
> + if (src->len - src->cur < size)
> + bytes_src = src->len - src->cur;
> + else
> + bytes_src = size;
> + bytes = bytes_dst < bytes_src ? bytes_dst : bytes_src;
> + memcpy(dst_addr, src_addr, bytes);
> + dst->cur = (dst->cur + bytes) % dst->len;
> + src->cur = (src->cur + bytes) % src->len;
> + size -= bytes;
> + }
> +}
> +
> +static size_t rvtrace_ramsink_copyto_auxbuf(struct rvtrace_component *comp,
> + struct rvtrace_perf_auxbuf *buf)
> +{
> + struct rvtrace_ramsink_priv *priv = dev_get_drvdata(&comp->dev);
> + size_t size_wp_end = 0, size_start_wp = 0;
> + struct trace_buf src, dst;
> + u32 wp_low, wp_high, trram_ctrl;
> + u64 buf_cur_head;
> +
> + dst.base = buf->base;
> + dst.len = buf->length;
> + dst.cur = buf->pos;
> + src.base = priv->va;
> + src.len = priv->size;
> + wp_low = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_WPLOW_OFF);
> + wp_high = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_WPHIGH_OFF);
> + buf_cur_head = (u64)(wp_high) << 32 | wp_low;
> + trram_ctrl = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
The trram_ctrl is not used. I think we should remove it.
> + if (buf_cur_head & 0x1) {
> + buf_cur_head &= ~RVTRACE_RAMSINK_WPLOW_WRAP;
> + rvtrace_write32(comp->pdata, lower_32_bits(priv->start),
> + RVTRACE_RAMSINK_WPLOW_OFF);
> + rvtrace_write32(comp->pdata, upper_32_bits(priv->start),
> + RVTRACE_RAMSINK_WPHIGH_OFF);
> + src.cur = buf_cur_head - priv->start;
> + size_wp_end = priv->end - buf_cur_head;
> + tbuf_to_pbuf_copy(&src, &dst, size_wp_end);
> + }
> +
> + src.cur = 0;
> + size_start_wp = buf_cur_head - priv->start;
> + tbuf_to_pbuf_copy(&src, &dst, size_start_wp);
> + dev_dbg(&comp->dev, "Copied %zu bytes\n", size_wp_end + size_start_wp);
Currently, rvtrace_ramsink_copyto_auxbuf() only resets the RAM sink
Write Pointer (WP) if a trace buffer wrap has occurred. If no wrap
occurs, it copies the trace data from the buffer's start address to
the current WP, but the WP is not reset to buffer's start address.
This causes an issue during process context switches. When a traced
program is context-switched out, the trace data is copied to the
perf AUX buffer. If the WP is not reset at this point, the next
time the program is scheduled and subsequently switched out, the
function will once again copy from the start of the buffer up to the
new WP. This unintentionally re-copies the old trace data from the
previous scheduled slice.
Regards,
Eric Lin
> + return (size_wp_end + size_start_wp);
> +}
> +
> +static int rvtrace_ramsink_setup_buf(struct rvtrace_component *comp,
> + struct rvtrace_ramsink_priv *priv)
> +{
> + struct device *pdev = comp->pdata->dev;
> + u64 start_min, limit_max, end;
> + u32 low, high;
> + int ret;
> +
> + /* Probe min and max values for start and limit registers */
> + rvtrace_write32(comp->pdata, 0, RVTRACE_RAMSINK_STARTLOW_OFF);
> + rvtrace_write32(comp->pdata, 0, RVTRACE_RAMSINK_STARTHIGH_OFF);
> + low = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_STARTLOW_OFF);
> + high = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_STARTHIGH_OFF);
> + start_min = (u64)(high) << 32 | low;
> +
> + rvtrace_write32(comp->pdata, 0xffffffff, RVTRACE_RAMSINK_LIMITLOW_OFF);
> + rvtrace_write32(comp->pdata, 0xffffffff, RVTRACE_RAMSINK_LIMITHIGH_OFF);
> + low = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_LIMITLOW_OFF);
> + high = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_LIMITHIGH_OFF);
> + limit_max = (u64)(high) << 32 | low;
> +
> + /* Set DMA mask based on the maximum allowed limit address */
> + ret = dma_set_mask_and_coherent(pdev, DMA_BIT_MASK(fls64(limit_max)));
> + if (ret)
> + return ret;
> +
> + priv->va = dma_alloc_coherent(pdev, priv->size, &priv->start, GFP_KERNEL);
> + if (!priv->va)
> + return -ENOMEM;
> +
> + priv->end = priv->start + priv->size;
> + if (priv->end <= start_min || priv->start >= limit_max) {
> + dma_free_coherent(pdev, priv->size, priv->va, priv->start);
> + dev_err(&comp->dev, "DMA memory not addressable by device\n");
> + return -EINVAL;
> + }
> +
> + /* Setup ram sink start addresses */
> + if (priv->start < start_min) {
> + dev_warn(&comp->dev, "Ramsink start address updated from %pad to %pad\n",
> + &priv->start, &start_min);
> + priv->va += start_min - priv->start;
> + priv->start = start_min;
> + }
> +
> + rvtrace_write32(comp->pdata, lower_32_bits(priv->start), RVTRACE_RAMSINK_STARTLOW_OFF);
> + rvtrace_write32(comp->pdata, upper_32_bits(priv->start), RVTRACE_RAMSINK_STARTHIGH_OFF);
> + rvtrace_write32(comp->pdata, lower_32_bits(priv->start), RVTRACE_RAMSINK_WPLOW_OFF);
> + rvtrace_write32(comp->pdata, upper_32_bits(priv->start), RVTRACE_RAMSINK_WPHIGH_OFF);
> + /* Setup ram sink limit addresses */
> + if (priv->end > limit_max) {
> + dev_warn(&comp->dev, "Ramsink limit address updated from %pad to %pad\n",
> + &priv->end, &limit_max);
> + priv->end = limit_max;
> + priv->size = priv->end - priv->start;
> + }
> +
> + /* Limit address needs to be set to end - mem_access_width to avoid overflow */
> + end = priv->end - priv->mem_acc_width;
> + rvtrace_write32(comp->pdata, lower_32_bits(end), RVTRACE_RAMSINK_LIMITLOW_OFF);
> + rvtrace_write32(comp->pdata, upper_32_bits(end), RVTRACE_RAMSINK_LIMITHIGH_OFF);
> + low = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_LIMITLOW_OFF);
> + high = rvtrace_read32(comp->pdata, RVTRACE_RAMSINK_LIMITHIGH_OFF);
> + end = (u64)(high) << 32 | low;
> + if (end != (priv->end - 4)) {
> + dev_warn(&comp->dev, "Ramsink limit address updated from %pad to %pad\n",
> + &priv->end, &end);
> + priv->end = end;
> + priv->size = priv->end - priv->start;
> + }
> +
> + return 0;
> +}
> +
> +static int rvtrace_ramsink_setup(struct rvtrace_component *comp)
> +{
> + struct rvtrace_ramsink_priv *priv;
> + u32 trram_ctrl;
> + int ret;
> +
> + priv = devm_kzalloc(&comp->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + /* Derive RAM sink memory size based on component implementation ID */
> + switch (comp->pdata->impid) {
> + default:
> + priv->size = SZ_1M;
> + priv->mode = MODE_SMEM;
> + priv->stop_on_wrap = false;
> + priv->mem_acc_width = 4;
> + break;
> + }
> +
> + trram_ctrl = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + trram_ctrl |= priv->mode << RVTRACE_RAMSINK_CTRL_MODE_SHIFT;
> + rvtrace_write32(comp->pdata, trram_ctrl, RVTRACE_COMPONENT_CTRL_OFFSET);
> + trram_ctrl = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + dev_dbg(&comp->dev, "mode: %s\n", (trram_ctrl >> RVTRACE_RAMSINK_CTRL_MODE_SHIFT) & 0x1 ?
> + "SMEM" : "SRAM");
> +
> + trram_ctrl |= priv->stop_on_wrap << RVTRACE_RAMSINK_CTRL_STP_WRAP_SHIFT;
> + rvtrace_write32(comp->pdata, trram_ctrl, RVTRACE_COMPONENT_CTRL_OFFSET);
> +
> + ret = rvtrace_ramsink_setup_buf(comp, priv);
> + if (!ret)
> + dev_set_drvdata(&comp->dev, priv);
> +
> + return ret;
> +}
> +
> +static void rvtrace_ramsink_cleanup(struct rvtrace_component *comp)
> +{
> + struct rvtrace_ramsink_priv *priv = dev_get_drvdata(&comp->dev);
> +
> + dma_free_coherent(comp->pdata->dev, priv->size, priv->va, priv->start);
> +}
> +
> +static int rvtrace_ramsink_probe(struct rvtrace_component *comp)
> +{
> + int ret;
> +
> + ret = rvtrace_ramsink_setup(comp);
> + if (ret)
> + return dev_err_probe(&comp->dev, ret, "failed to setup ramsink.\n");
> +
> + ret = rvtrace_enable_component(comp->pdata);
> + if (ret)
> + return dev_err_probe(&comp->dev, ret, "failed to enable ramsink.\n");
> +
> + return ret;
> +}
> +
> +static void rvtrace_ramsink_remove(struct rvtrace_component *comp)
> +{
> + int ret;
> +
> + ret = rvtrace_disable_component(comp->pdata);
> + if (ret)
> + dev_err(&comp->dev, "failed to disable ramsink.\n");
> +
> + rvtrace_ramsink_cleanup(comp);
> +}
> +
> +static struct rvtrace_component_id rvtrace_ramsink_ids[] = {
> + { .type = RVTRACE_COMPONENT_TYPE_RAMSINK,
> + .version = rvtrace_component_mkversion(1, 0), },
> + {},
> +};
> +
> +static struct rvtrace_driver rvtrace_ramsink_driver = {
> + .id_table = rvtrace_ramsink_ids,
> + .copyto_auxbuf = rvtrace_ramsink_copyto_auxbuf,
> + .stop = rvtrace_ramsink_stop,
> + .start = rvtrace_ramsink_start,
> + .probe = rvtrace_ramsink_probe,
> + .remove = rvtrace_ramsink_remove,
> + .driver = {
> + .name = "rvtrace-ramsink",
> + },
> +};
> +
> +static int __init rvtrace_ramsink_init(void)
> +{
> + return rvtrace_register_driver(&rvtrace_ramsink_driver);
> +}
> +
> +static void __exit rvtrace_ramsink_exit(void)
> +{
> + rvtrace_unregister_driver(&rvtrace_ramsink_driver);
> +}
> +
> +module_init(rvtrace_ramsink_init);
> +module_exit(rvtrace_ramsink_exit);
> +
> +/* Module information */
> +MODULE_AUTHOR("Mayuresh Chitale");
> +MODULE_DESCRIPTION("RISC-V Trace Ramsink Driver");
> +MODULE_LICENSE("GPL");
> --
> 2.43.0
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ 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