[PATCH v4 0/5] arm64: dts: renesas: Enable ISP and IVC on RZ/V2H EVK

[PATCH v4 0/5] arm64: dts: renesas: Enable ISP and IVC on RZ/V2H EVK

[Linus Walleij]

Describe the optional ISP DMA line-tick and IVC frame-start/frame-stop
interrupts. Add the RZ/V2H(P) IVC and Arm Mali-C55 ISP nodes, connect their
video endpoints, and enable both blocks on the RZ/V2H EVK.

After these patches, and enabling the right Linux drivers, we get
this in the console:
mali-c55 16080000.isp: Detected Mali-C55 ISP 9000043.31032022.0

This was done in order to enable booting mainline with mainline
device trees.

Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Changes in v4:
- Provide interrupt names in both bindings, their examples and SoC nodes.
- Use Renesas RZ/V2H interrupt numbers in the binding examples.
- Link to v3: https://patch.msgid.link/20260928-mali-c55-renesas-dts-v3-0-2cf7eb746ebb@kernel.org

Changes in v3:
- Correct the ISP video and register clock/reset mappings by swapping
  vclk/hclk and vresetn/hresetn.
- Add an optional ISP power-domain binding and attach the RZ/V2H ISP
  to the CPG power domain.
- Link to v2: https://patch.msgid.link/20260925-mali-c55-renesas-dts-v2-0-69f728a474a2@kernel.org

Changes in v2:
- Add separate IVC and ISP binding patches describing the optional IVC
  frame-start/frame-stop completion and ISP DMA line-tick IRQs.
  Show all six IRQs in the examples using consecutive mock numbers.
- Add the IVC frame-start/stop and ISP DMA line-tick interrupt lines
  using the confirmed SPI assignments, addressing Geert's IRQ review.
- Correct the IVC and ISP register sizes to 64 KiB and 512 KiB,
  respectively, as requested by Geert. GPV_VIDEO0 is a separate bus
  interconnect region.
- Compact the clock and reset properties and remove blank lines between
  properties, following Geert's review.
- Link to v1: https://patch.msgid.link/20260922-mali-c55-renesas-dts-v1-0-cd63cdb51033@kernel.org

---
Daniel Scally (2):
      arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes
      arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add ISP and IVC nodes

Linus Walleij (3):
      dt-bindings: media: renesas,r9a09g057-ivc: Describe additional interrupts
      dt-bindings: media: arm,mali-c55: Describe DMA line-tick interrupts
      dt-bindings: media: arm,mali-c55: Add power domain

 .../devicetree/bindings/media/arm,mali-c55.yaml    | 27 ++++++++++++-
 .../bindings/media/renesas,r9a09g057-ivc.yaml      | 22 +++++++++-
 arch/arm64/boot/dts/renesas/r9a09g057.dtsi         | 47 ++++++++++++++++++++++
 .../boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts    |  8 ++++
 4 files changed, 100 insertions(+), 4 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260922-mali-c55-renesas-dts-74d4727f59e5

Best regards,
--  
Linus Walleij <linusw@kernel.org>

[PATCH v4 1/5] dt-bindings: media: renesas,r9a09g057-ivc: Describe additional interrupts

[Linus Walleij]

The RZ/V2H IVC provides input frame-start and frame-stop completion
interrupts alongside its input frame-end interrupt.

Describe these optional interrupts and their signal names from Table 3.1
of the RZ/V2H(P) hardware manual's ISP additional document. Require frame
end first for compatibility with drivers using index-based IRQ lookup.
Keep interrupt-names optional and require only the first interrupt to
preserve support for existing device trees. Extend the example to show
all three interrupts with their names and RZ/V2H interrupt numbers.

Assisted-by: LLM
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 .../bindings/media/renesas,r9a09g057-ivc.yaml      | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml b/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml
index c09cbd8c9e35..75ecb47422b2 100644
--- a/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml
@@ -21,7 +21,21 @@ properties:
     maxItems: 1
 
   interrupts:
-    maxItems: 1
+    description:
+      The image input frame-end interrupt must be specified first to remain
+      compatible with drivers that retrieve it by index.
+    minItems: 1
+    items:
+      - description: Image input frame-end interrupt
+      - description: Image input frame-start interrupt
+      - description: Frame-stop processing completion interrupt
+
+  interrupt-names:
+    minItems: 1
+    items:
+      - const: isp_vvalid_ifp
+      - const: isp_vvalid_irp
+      - const: isp_int_fstop
 
   clocks:
     items:
@@ -92,7 +106,11 @@ examples:
                <&cpg 0xd3>;
       reset-names = "reg", "axi", "isp";
 
-      interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>;
+      /* RZ/V2H interrupt numbers. */
+      interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>,
+                   <GIC_SPI 860 IRQ_TYPE_EDGE_RISING>,
+                   <GIC_SPI 864 IRQ_TYPE_LEVEL_HIGH>;
+      interrupt-names = "isp_vvalid_ifp", "isp_vvalid_irp", "isp_int_fstop";
 
       port {
         ivc_out: endpoint {

-- 
2.56.0

[PATCH v4 2/5] dt-bindings: media: arm,mali-c55: Describe DMA line-tick interrupts

[Linus Walleij]

Mali-C55 exposes separate full-resolution and UV DMA writer line-tick
interrupts in addition to its combined core interrupt.

Describe these optional interrupts from Tables 6-14 and 6-24 of the
Mali-C55 Configuration and Integration Manual. Use combined_interrupt
for the combined core interrupt and the signal names for the line-tick
interrupts.

Require the core interrupt first for compatibility with drivers using
index-based IRQ lookup. Keep interrupt-names optional and require only
the first interrupt to preserve support for existing device trees.
Extend the example to show all three interrupts with their names and
RZ/V2H interrupt numbers.

Assisted-by: LLM
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 .../devicetree/bindings/media/arm,mali-c55.yaml    | 23 ++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/arm,mali-c55.yaml b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
index fc4fcd19922a..d04105cd1ecc 100644
--- a/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
+++ b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
@@ -18,7 +18,21 @@ properties:
     maxItems: 1
 
   interrupts:
-    maxItems: 1
+    description:
+      The combined ISP core interrupt must be specified first to remain
+      compatible with drivers that retrieve it by index.
+    minItems: 1
+    items:
+      - description: Combined ISP core interrupt
+      - description: Full-resolution DMA writer line-tick interrupt
+      - description: Full-resolution UV DMA writer line-tick interrupt
+
+  interrupt-names:
+    minItems: 1
+    items:
+      - const: combined_interrupt
+      - const: fr_dma_writer_linetick_out
+      - const: fr_uv_dma_writer_linetick_out
 
   clocks:
     items:
@@ -75,7 +89,12 @@ examples:
       clock-names = "vclk", "aclk", "hclk";
       resets = <&resets 0>, <&resets 1>, <&resets 2>;
       reset-names = "vresetn", "aresetn", "hresetn";
-      interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>;
+      /* RZ/V2H interrupt numbers. */
+      interrupts = <GIC_SPI 859 IRQ_TYPE_LEVEL_HIGH>,
+                   <GIC_SPI 865 IRQ_TYPE_EDGE_RISING>,
+                   <GIC_SPI 866 IRQ_TYPE_EDGE_RISING>;
+      interrupt-names = "combined_interrupt", "fr_dma_writer_linetick_out",
+                        "fr_uv_dma_writer_linetick_out";
 
       port {
         isp_in: endpoint {

-- 
2.56.0

[PATCH v4 3/5] dt-bindings: media: arm,mali-c55: Add power domain

[Linus Walleij]

Some Mali-C55 integrations place the ISP in a power domain. In
particular, RZ/V2H uses the CPG domain to manage its module clocks
through runtime PM.

Allow a single power domain and describe it in the example. Keep the
property optional for integrations that do not expose a power domain.

Assisted-by: LLM
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 Documentation/devicetree/bindings/media/arm,mali-c55.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/arm,mali-c55.yaml b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
index d04105cd1ecc..23b53faec73d 100644
--- a/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
+++ b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
@@ -46,6 +46,9 @@ properties:
       - const: aclk
       - const: hclk
 
+  power-domains:
+    maxItems: 1
+
   resets:
     items:
       - description: vclk domain reset
@@ -87,6 +90,7 @@ examples:
       reg = <0x400000 0x200000>;
       clocks = <&clk 0>, <&clk 1>, <&clk 2>;
       clock-names = "vclk", "aclk", "hclk";
+      power-domains = <&power>;
       resets = <&resets 0>, <&resets 1>, <&resets 2>;
       reset-names = "vresetn", "aresetn", "hresetn";
       /* RZ/V2H interrupt numbers. */

-- 
2.56.0

[PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Linus Walleij]

From: Daniel Scally <dan.scally@ideasonboard.com>

Add the Input Video Control Block and Arm Mali-C55 ISP to the device
tree file for the RZ/V2H(P) SoC.

[Rebase onto v7.3-rc1, place the nodes in address order, add the missing
 interrupts in binding order and name them. - Linus Walleij]

Assisted-by: LLM
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 47 ++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
index 639693d464a7..228155fa3c76 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
@@ -1839,6 +1839,53 @@ queue3 {
 			};
 		};
 
+		ivc: isp-input@16040000 {
+			compatible = "renesas,r9a09g057-ivc";
+			reg = <0 0x16040000 0 0x10000>;
+			clocks = <&cpg CPG_MOD 0xe3>, <&cpg CPG_MOD 0xe4>,
+				 <&cpg CPG_MOD 0xe5>;
+			clock-names = "reg", "axi", "isp";
+			interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 860 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 864 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "isp_vvalid_ifp", "isp_vvalid_irp",
+					  "isp_int_fstop";
+			power-domains = <&cpg>;
+			resets = <&cpg 0xd4>, <&cpg 0xd1>, <&cpg 0xd3>;
+			reset-names = "reg", "axi", "isp";
+			status = "disabled";
+
+			port {
+				ivc_out: endpoint {
+					remote-endpoint = <&isp_in>;
+				};
+			};
+		};
+
+		isp: isp@16080000 {
+			compatible = "arm,mali-c55";
+			reg = <0 0x16080000 0 0x80000>;
+			clocks = <&cpg CPG_MOD 0xe5>, <&cpg CPG_MOD 0xe4>,
+				 <&cpg CPG_MOD 0xe2>;
+			clock-names = "vclk", "aclk", "hclk";
+			interrupts = <GIC_SPI 859 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 865 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 866 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "combined_interrupt",
+					  "fr_dma_writer_linetick_out",
+					  "fr_uv_dma_writer_linetick_out";
+			power-domains = <&cpg>;
+			resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
+			reset-names = "vresetn", "aresetn", "hresetn";
+			status = "disabled";
+
+			port {
+				isp_in: endpoint {
+					remote-endpoint = <&ivc_out>;
+				};
+			};
+		};
+
 		dsi: dsi@16430000 {
 			compatible = "renesas,r9a09g057-mipi-dsi";
 			reg = <0 0x16430000 0 0x20000>;

-- 
2.56.0

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Jacopo Mondi]

Hi Linus

On Mon, Oct 12, 2026 at 01:56:26PM +0200, Linus Walleij wrote:
> From: Daniel Scally <dan.scally@ideasonboard.com>
>
> Add the Input Video Control Block and Arm Mali-C55 ISP to the device
> tree file for the RZ/V2H(P) SoC.
>
> [Rebase onto v7.3-rc1, place the nodes in address order, add the missing
>  interrupts in binding order and name them. - Linus Walleij]
>
> Assisted-by: LLM
> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
> Signed-off-by: Linus Walleij <linusw@kernel.org>

How was this patch tested ?

I am rebasing my rz/v2h tree on v7.2 and I've backported this patch.

Unfortunately I don't get any frame from the camera, but rather the
system hangs in unrecoverable state

> ---
>  arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 47 ++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> index 639693d464a7..228155fa3c76 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> @@ -1839,6 +1839,53 @@ queue3 {
>  			};
>  		};
>
> +		ivc: isp-input@16040000 {
> +			compatible = "renesas,r9a09g057-ivc";
> +			reg = <0 0x16040000 0 0x10000>;
> +			clocks = <&cpg CPG_MOD 0xe3>, <&cpg CPG_MOD 0xe4>,
> +				 <&cpg CPG_MOD 0xe5>;

Compared to Dan's original patch I was carrying my tree the first and
third ids of clock and reset properties in the ivc and isp nodes respectivelty
are swapped

This patch

--- a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
@@ -1709,8 +1709,8 @@ ivc_out: endpoint {
                isp: isp@16080000 {
                        compatible = "arm,mali-c55";
                        reg = <0 0x16080000 0 0x80000>;
-                       clocks = <&cpg CPG_MOD 0xe5>, <&cpg CPG_MOD 0xe4>,
-                                <&cpg CPG_MOD 0xe2>;
+                       clocks = <&cpg CPG_MOD 0xe2>, <&cpg CPG_MOD 0xe4>,
+                                <&cpg CPG_MOD 0xe5>;
                        clock-names = "vclk", "aclk", "hclk";
                        interrupts = <GIC_SPI 859 IRQ_TYPE_LEVEL_HIGH>,
                                     <GIC_SPI 865 IRQ_TYPE_EDGE_RISING>,
@@ -1719,7 +1719,7 @@ isp: isp@16080000 {
                                          "fr_dma_writer_linetick_out",
                                          "fr_uv_dma_writer_linetick_out";
                        power-domains = <&cpg>;
-                       resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
+                       resets = <&cpg 0xd2>, <&cpg 0xd1>, <&cpg 0xd3>;
                        reset-names = "vresetn", "aresetn", "hresetn";
                        status = "disabled";

Fixes the issue for me

Why is this an issue it's not 100% clear to me.

The driver handles both reset and regulators with the bulk API which
does not guarantee ordering (and no ordering is specified in the
datasheet as far as I can tell). All clocks and resets names are used,
so the ordering shouldn't make much difference as far as I can tell.

I can't access the "additional documentation" from the Renesas website
where the clock/reset ids are reported. Could you please check ?


> +			clock-names = "reg", "axi", "isp";
> +			interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>,
> +				     <GIC_SPI 860 IRQ_TYPE_EDGE_RISING>,
> +				     <GIC_SPI 864 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "isp_vvalid_ifp", "isp_vvalid_irp",
> +					  "isp_int_fstop";
> +			power-domains = <&cpg>;
> +			resets = <&cpg 0xd4>, <&cpg 0xd1>, <&cpg 0xd3>;
> +			reset-names = "reg", "axi", "isp";
> +			status = "disabled";
> +
> +			port {
> +				ivc_out: endpoint {
> +					remote-endpoint = <&isp_in>;
> +				};
> +			};
> +		};
> +
> +		isp: isp@16080000 {
> +			compatible = "arm,mali-c55";
> +			reg = <0 0x16080000 0 0x80000>;
> +			clocks = <&cpg CPG_MOD 0xe5>, <&cpg CPG_MOD 0xe4>,
> +				 <&cpg CPG_MOD 0xe2>;
> +			clock-names = "vclk", "aclk", "hclk";
> +			interrupts = <GIC_SPI 859 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 865 IRQ_TYPE_EDGE_RISING>,
> +				     <GIC_SPI 866 IRQ_TYPE_EDGE_RISING>;
> +			interrupt-names = "combined_interrupt",
> +					  "fr_dma_writer_linetick_out",
> +					  "fr_uv_dma_writer_linetick_out";
> +			power-domains = <&cpg>;
> +			resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
> +			reset-names = "vresetn", "aresetn", "hresetn";
> +			status = "disabled";
> +
> +			port {
> +				isp_in: endpoint {
> +					remote-endpoint = <&ivc_out>;
> +				};
> +			};
> +		};
> +
>  		dsi: dsi@16430000 {
>  			compatible = "renesas,r9a09g057-mipi-dsi";
>  			reg = <0 0x16430000 0 0x20000>;
>
> --
> 2.56.0
>

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Lad, Prabhakar]

Hi Jacopo,

Thank you for looking into this.

On Mon, Oct 12, 2026 at 4:47 PM Jacopo Mondi
<jacopo.mondi@ideasonboard.com> wrote:
>
> Hi Linus
>
> On Mon, Oct 12, 2026 at 01:56:26PM +0200, Linus Walleij wrote:
> > From: Daniel Scally <dan.scally@ideasonboard.com>
> >
> > Add the Input Video Control Block and Arm Mali-C55 ISP to the device
> > tree file for the RZ/V2H(P) SoC.
> >
> > [Rebase onto v7.3-rc1, place the nodes in address order, add the missing
> >  interrupts in binding order and name them. - Linus Walleij]
> >
> > Assisted-by: LLM
> > Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
>
> How was this patch tested ?
>
> I am rebasing my rz/v2h tree on v7.2 and I've backported this patch.
>
> Unfortunately I don't get any frame from the camera, but rather the
> system hangs in unrecoverable state
>
> > ---
> >  arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 47 ++++++++++++++++++++++++++++++
> >  1 file changed, 47 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> > index 639693d464a7..228155fa3c76 100644
> > --- a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> > @@ -1839,6 +1839,53 @@ queue3 {
> >                       };
> >               };
> >
> > +             ivc: isp-input@16040000 {
> > +                     compatible = "renesas,r9a09g057-ivc";
> > +                     reg = <0 0x16040000 0 0x10000>;
> > +                     clocks = <&cpg CPG_MOD 0xe3>, <&cpg CPG_MOD 0xe4>,
> > +                              <&cpg CPG_MOD 0xe5>;
>
> Compared to Dan's original patch I was carrying my tree the first and
> third ids of clock and reset properties in the ivc and isp nodes respectivelty
> are swapped
>
> This patch
>
> --- a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
> @@ -1709,8 +1709,8 @@ ivc_out: endpoint {
>                 isp: isp@16080000 {
>                         compatible = "arm,mali-c55";
>                         reg = <0 0x16080000 0 0x80000>;
> -                       clocks = <&cpg CPG_MOD 0xe5>, <&cpg CPG_MOD 0xe4>,
> -                                <&cpg CPG_MOD 0xe2>;
> +                       clocks = <&cpg CPG_MOD 0xe2>, <&cpg CPG_MOD 0xe4>,
> +                                <&cpg CPG_MOD 0xe5>;
>                         clock-names = "vclk", "aclk", "hclk";
>                         interrupts = <GIC_SPI 859 IRQ_TYPE_LEVEL_HIGH>,
>                                      <GIC_SPI 865 IRQ_TYPE_EDGE_RISING>,
> @@ -1719,7 +1719,7 @@ isp: isp@16080000 {
>                                           "fr_dma_writer_linetick_out",
>                                           "fr_uv_dma_writer_linetick_out";
>                         power-domains = <&cpg>;
> -                       resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
> +                       resets = <&cpg 0xd2>, <&cpg 0xd1>, <&cpg 0xd3>;
>                         reset-names = "vresetn", "aresetn", "hresetn";
>                         status = "disabled";
>
> Fixes the issue for me
>
It also fixes the issues on my side; I tested it with the RZ/V2H EVK
using the imx708 sensor,

root@192:~# cam -c2 -C10
[0:10:13.102940291] [1010]  INFO Camera camera_manager.cpp:330
libcamera v0.0.0+5679-0b4b0ef3
[0:10:13.136058708] [1013]  INFO Camera camera_manager.cpp:220 Adding
camera 'mali-c55 tpg' for pipeline handler mali-c55
[0:10:13.143446208] [1013]  WARN CameraSensor
camera_sensor_legacy.cpp:354 'imx708': Recommended V4L2 control
0x009a0922 not supported
[0:10:13.143574833] [1013]  WARN CameraSensor
camera_sensor_legacy.cpp:426 'imx708': The sensor kernel driver needs
to be fixed
[0:10:13.143612416] [1013]  WARN CameraSensor
camera_sensor_legacy.cpp:428 'imx708': See
Documentation/sensor_driver_requirements.rst in the libcamera sources
for more information
[0:10:13.147022541] [1013]  WARN CameraSensor
camera_sensor_legacy.cpp:594 'imx708': Failed to retrieve the camera
location
[0:10:13.147073666] [1013]  WARN CameraSensor
camera_sensor_legacy.cpp:616 'imx708': Rotation control not available,
default to 0 degrees
[0:10:13.254700791] [1013]  INFO Camera camera_manager.cpp:220 Adding
camera 'imx708' for pipeline handler mali-c55
Using camera imx708 as cam0
[0:10:13.258077083] [1010]  INFO Camera camera.cpp:1214 configuring
streams: (0) 1920x1080-RGB565/Unset
cam0: Capture 10 frames
613.444141 (0.00 fps) cam0-stream0 seq: 000000 bytesused: 4147200
613.459953 (63.24 fps) cam0-stream0 seq: 000001 bytesused: 4147200
613.478004 (55.40 fps) cam0-stream0 seq: 000002 bytesused: 4147200
613.496112 (55.22 fps) cam0-stream0 seq: 000003 bytesused: 4147200
613.514060 (55.72 fps) cam0-stream0 seq: 000004 bytesused: 4147200
613.532173 (55.21 fps) cam0-stream0 seq: 000005 bytesused: 4147200
613.550287 (55.21 fps) cam0-stream0 seq: 000006 bytesused: 4147200
613.568400 (55.21 fps) cam0-stream0 seq: 000007 bytesused: 4147200
613.586458 (55.38 fps) cam0-stream0 seq: 000008 bytesused: 4147200
613.604489 (55.46 fps) cam0-stream0 seq: 000009 bytesused: 4147200
root@192:~#

I was also able to test this with camshark using my older setup.

> Why is this an issue it's not 100% clear to me.
>
> The driver handles both reset and regulators with the bulk API which
> does not guarantee ordering (and no ordering is specified in the
> datasheet as far as I can tell). All clocks and resets names are used,
> so the ordering shouldn't make much difference as far as I can tell.
>
Indeed.

> I can't access the "additional documentation" from the Renesas website
> where the clock/reset ids are reported. Could you please check ?
>
I will also double check this.

Cheers,
Prabhakar
>
> > +                     clock-names = "reg", "axi", "isp";
> > +                     interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>,
> > +                                  <GIC_SPI 860 IRQ_TYPE_EDGE_RISING>,
> > +                                  <GIC_SPI 864 IRQ_TYPE_LEVEL_HIGH>;
> > +                     interrupt-names = "isp_vvalid_ifp", "isp_vvalid_irp",
> > +                                       "isp_int_fstop";
> > +                     power-domains = <&cpg>;
> > +                     resets = <&cpg 0xd4>, <&cpg 0xd1>, <&cpg 0xd3>;
> > +                     reset-names = "reg", "axi", "isp";
> > +                     status = "disabled";
> > +
> > +                     port {
> > +                             ivc_out: endpoint {
> > +                                     remote-endpoint = <&isp_in>;
> > +                             };
> > +                     };
> > +             };
> > +
> > +             isp: isp@16080000 {
> > +                     compatible = "arm,mali-c55";
> > +                     reg = <0 0x16080000 0 0x80000>;
> > +                     clocks = <&cpg CPG_MOD 0xe5>, <&cpg CPG_MOD 0xe4>,
> > +                              <&cpg CPG_MOD 0xe2>;
> > +                     clock-names = "vclk", "aclk", "hclk";
> > +                     interrupts = <GIC_SPI 859 IRQ_TYPE_LEVEL_HIGH>,
> > +                                  <GIC_SPI 865 IRQ_TYPE_EDGE_RISING>,
> > +                                  <GIC_SPI 866 IRQ_TYPE_EDGE_RISING>;
> > +                     interrupt-names = "combined_interrupt",
> > +                                       "fr_dma_writer_linetick_out",
> > +                                       "fr_uv_dma_writer_linetick_out";
> > +                     power-domains = <&cpg>;
> > +                     resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
> > +                     reset-names = "vresetn", "aresetn", "hresetn";
> > +                     status = "disabled";
> > +
> > +                     port {
> > +                             isp_in: endpoint {
> > +                                     remote-endpoint = <&ivc_out>;
> > +                             };
> > +                     };
> > +             };
> > +
> >               dsi: dsi@16430000 {
> >                       compatible = "renesas,r9a09g057-mipi-dsi";
> >                       reg = <0 0x16430000 0 0x20000>;
> >
> > --
> > 2.56.0
> >
>

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Linus Walleij]

Hi Jacopo,

On Mon, Oct 12, 2026 at 5:39 PM Jacopo Mondi
<jacopo.mondi@ideasonboard.com> wrote:

> How was this patch tested ?

I was using the TPG only so far, a camera module is in the mail.

I do have the RPi camera module 3 but didn't get it to work, this
may explain why...

> > +             ivc: isp-input@16040000 {
> > +                     compatible = "renesas,r9a09g057-ivc";
> > +                     reg = <0 0x16040000 0 0x10000>;
> > +                     clocks = <&cpg CPG_MOD 0xe3>, <&cpg CPG_MOD 0xe4>,
> > +                              <&cpg CPG_MOD 0xe5>;
>
> Compared to Dan's original patch I was carrying my tree the first and
> third ids of clock and reset properties in the ivc and isp nodes respectivelty
> are swapped

OK

> -                       resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
> +                       resets = <&cpg 0xd2>, <&cpg 0xd1>, <&cpg 0xd3>;
>                         reset-names = "vresetn", "aresetn", "hresetn";
>                         status = "disabled";
>
> Fixes the issue for me

OK

> Why is this an issue it's not 100% clear to me.

Can you try this?

diff --git a/drivers/media/platform/arm/mali-c55/mali-c55-core.c
b/drivers/media/platform/arm/mali-c55/mali-c55-core.c
--- a/drivers/media/platform/arm/mali-c55/mali-c55-core.c
+++ b/drivers/media/platform/arm/mali-c55/mali-c55-core.c
@@ -703,6 +703,12 @@
                return ret;
        }

+       /*
+        * Allow the ISP's 2500-vclk reset recovery time.
+        * 200 us cover the RZ/V2H's documented minimum of 20 MHz.
+        */
+       usleep_range(200, 300);
+
        /* Use "software only" context management. */
        mali_c55_update_bits(mali_c55, MALI_C55_REG_MCU_CONFIG,
                             MALI_C55_REG_MCU_CONFIG_OVERRIDE_MASK, 0x01);

When we now retrieve the reset and assert it, it matters that
we give the hardware time to recover. (If this works I will make
a separate patch.)

> I can't access the "additional documentation" from the Renesas website
> where the clock/reset ids are reported. Could you please check ?

These changes contradicts the manual so we can't change things
like this unless we know more, it'd be too much trial-and-horror.

The manual says:

Video/ISP core
0xe5, isp_sclk
0xd3, isp_sresetn

Register-interface bridge
0xe2, reg_aclk
0xd2, reg_aresetn

Yours,
Linus Walleij

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Jacopo Mondi]

Hi Linus

On Thu, Oct 15, 2026 at 02:36:00PM +0200, Linus Walleij wrote:
> Hi Jacopo,
>
> On Mon, Oct 12, 2026 at 5:39 PM Jacopo Mondi
> <jacopo.mondi@ideasonboard.com> wrote:
>
> > How was this patch tested ?
>
> I was using the TPG only so far, a camera module is in the mail.
>
> I do have the RPi camera module 3 but didn't get it to work, this
> may explain why...
>
> > > +             ivc: isp-input@16040000 {
> > > +                     compatible = "renesas,r9a09g057-ivc";
> > > +                     reg = <0 0x16040000 0 0x10000>;
> > > +                     clocks = <&cpg CPG_MOD 0xe3>, <&cpg CPG_MOD 0xe4>,
> > > +                              <&cpg CPG_MOD 0xe5>;
> >
> > Compared to Dan's original patch I was carrying my tree the first and
> > third ids of clock and reset properties in the ivc and isp nodes respectivelty
> > are swapped
>
> OK
>
> > -                       resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
> > +                       resets = <&cpg 0xd2>, <&cpg 0xd1>, <&cpg 0xd3>;
> >                         reset-names = "vresetn", "aresetn", "hresetn";
> >                         status = "disabled";
> >
> > Fixes the issue for me
>
> OK
>
> > Why is this an issue it's not 100% clear to me.
>
> Can you try this?
>
> diff --git a/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> b/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> --- a/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> +++ b/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> @@ -703,6 +703,12 @@
>                 return ret;
>         }
>
> +       /*
> +        * Allow the ISP's 2500-vclk reset recovery time.
> +        * 200 us cover the RZ/V2H's documented minimum of 20 MHz.
> +        */
> +       usleep_range(200, 300);
> +
>         /* Use "software only" context management. */
>         mali_c55_update_bits(mali_c55, MALI_C55_REG_MCU_CONFIG,
>                              MALI_C55_REG_MCU_CONFIG_OVERRIDE_MASK, 0x01);
>
> When we now retrieve the reset and assert it, it matters that
> we give the hardware time to recover. (If this works I will make
> a separate patch.)

Unfortunately this doesn't help

>
> > I can't access the "additional documentation" from the Renesas website
> > where the clock/reset ids are reported. Could you please check ?
>

I mapped the dts entries to the clock/reset signals.

This is what is implemented by your patch:

* means the clock/reset is only handled by the IVC/ISP drivers
** means the clock/reset is handled by both the IVC/ISP drivers

(why the IVC has three entries as well, it's not 100% clear to me, but
this is unrelated)

ivc:
   clocks:
   - reg: e3 (227)  -> CGC_ISP_0_pclk         *
   - axi: e4 (228)  -> CGC_ISP_0_vin_aclk     **
   - isp: e5 (229)  -> CGC_ISP_0_isp_sclk     **

   resets:
   - reg: d4 (212)  -> ISP_0_PRESETN          *
   - axi: d1 (209)  -> ISP_0_REG_ARESETN      **
   - isp: d3 (211)  -> ISP_0_ISP_SRESETN      **

isp:
   clocks:
   - vclk e5  (229)  -> CGC_ISP_0_isp_sclk    **
   - aclk e4  (228)  -> CGC_ISP_0_vin_aclk    **
   - hclk e2  (226)  -> CGC_ISP_0_reg_aclk    *

   resets:
   - vresetn d3 (211) -> ISP_0_ISP_SRESETN    **
   - aresetn d1 (209) -> ISP_0_VIN_ARESETN    **
   - hresetn d2 (210) -> ISP_0_REG_ARESETN    *

As libcamera calls start_streaming on the IVC first the sequence in
which resets/clocks are bulk_enabled is:

* = number of time the clock/reset signal has been enabled:

        [IVC        ][ISP          ]
        [e3* e4* e5*][e5** e4** e2*]

        [IVC        ][ISP          ]
        [d4* d1* d3*][d3** d1** d2*]

This results in the following overall ordering

        e3: CGC_ISP_0_pclk
        e4: CGC_ISP_0_vin_aclk
        e5: CGC_ISP_0_isp_sclk
        e2: CGC_ISP_0_reg_aclk

        d4: ISP_0_PRESETN
        d1: ISP_0_REG_ARESETN
        d3: ISP_0_ISP_SRESETN
        d2: ISP_0_REG_ARESETN

Now, my proposed patch switches e5 with e2 and d3 with d2

        [IVC        ][ISP          ]
        [e3* e4* e5*][e2* e4** e5**]

        [IVC        ][ISP          ]
        [d4* d1* d3*][d2* d1** d3**]

What I don't get is why this should make any difference as the overall
ordering wouldn't change. When the IVC resumes the 0xe5 clock will
anyway be enabled before the 0xe2 one, regardless of the order in
which they are specified in the isp node.

        [IVC    ][ISP]
        e3 e4 e5  e2
        d4 d1 d3  d2

Unless I don't understand something about the enablement of
reset/clocks with multiple users...

Also the only indication I find on the V2H manual on the expected
enablment ordering is:

    All clocks should be turned on and off simultaneously.

Something the doesn't happen today. Maybe we're *very* lucky that
enabling e2 first in the ISP driver matches some window that is missed
by enabling it last, but this seems very very far fetched, isn't it ?

> These changes contradicts the manual so we can't change things
> like this unless we know more, it'd be too much trial-and-horror.
>
> The manual says:
>
> Video/ISP core
> 0xe5, isp_sclk
> 0xd3, isp_sresetn
>
> Register-interface bridge
> 0xe2, reg_aclk
> 0xd2, reg_aresetn

Do you maybe have any information on how the above signal maps to the
C55 clocks/reset and if there's any indication that might help better
understand the issue ?

>
> Yours,
> Linus Walleij

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Linus Walleij]

Hi Jacopo, and Prabhakar,

thanks a lot for your help testing this!

On Mon, Oct 19, 2026 at 12:23 PM Jacopo Mondi
<jacopo.mondi@ideasonboard.com> wrote:

> > +       /*
> > +        * Allow the ISP's 2500-vclk reset recovery time.
> > +        * 200 us cover the RZ/V2H's documented minimum of 20 MHz.
> > +        */
> > +       usleep_range(200, 300);
> > +
> >         /* Use "software only" context management. */
> >         mali_c55_update_bits(mali_c55, MALI_C55_REG_MCU_CONFIG,
> >                              MALI_C55_REG_MCU_CONFIG_OVERRIDE_MASK, 0x01);
> >
> > When we now retrieve the reset and assert it, it matters that
> > we give the hardware time to recover. (If this works I will make
> > a separate patch.)
>
> Unfortunately this doesn't help

Since it is clear that:

1, The clock and/or reset ordering matters.

2. The device tree order does not in any way impiy any sequencing
  or such sematics. (I.e. we can't really change these DTS patches)

3. The bulk APIs for clocks and resets have unpredictable ordering
  (clocks will process from left to right and resets in the reverse order...)

I have concluded we need to request each clock and reset explicitly
in the driver and sequence them in code.

I sent a new patch series with two additional patches to explicitly
order clock and reset enblement.

See if this helps and how it looks... Try dropping the reset patch
because I suspect that ordering to not be as important as the
clock ordering but I could be wrong.

Yours,
Linus Walleij

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Geert Uytterhoeven]

Hi Linus,

On Tue, 27 Oct 2026 at 19:01, Linus Walleij <linusw@kernel.org> wrote:
> On Mon, Oct 19, 2026 at 12:23 PM Jacopo Mondi
> <jacopo.mondi@ideasonboard.com> wrote:
>
> > > +       /*
> > > +        * Allow the ISP's 2500-vclk reset recovery time.
> > > +        * 200 us cover the RZ/V2H's documented minimum of 20 MHz.
> > > +        */
> > > +       usleep_range(200, 300);
> > > +
> > >         /* Use "software only" context management. */
> > >         mali_c55_update_bits(mali_c55, MALI_C55_REG_MCU_CONFIG,
> > >                              MALI_C55_REG_MCU_CONFIG_OVERRIDE_MASK, 0x01);
> > >
> > > When we now retrieve the reset and assert it, it matters that
> > > we give the hardware time to recover. (If this works I will make
> > > a separate patch.)
> >
> > Unfortunately this doesn't help
>
> Since it is clear that:
>
> 1, The clock and/or reset ordering matters.
>
> 2. The device tree order does not in any way impiy any sequencing
>   or such sematics. (I.e. we can't really change these DTS patches)
>
> 3. The bulk APIs for clocks and resets have unpredictable ordering
>   (clocks will process from left to right and resets in the reverse order...)
>
> I have concluded we need to request each clock and reset explicitly
> in the driver and sequence them in code.
>
> I sent a new patch series with two additional patches to explicitly
> order clock and reset enblement.
>
> See if this helps and how it looks... Try dropping the reset patch
> because I suspect that ordering to not be as important as the
> clock ordering but I could be wrong.

The driver uses Runtime PM, but I see no calls to
pm_runtime_resume_and_get()?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Linus Walleij]

On Tue, Oct 27, 2026 at 7:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> The driver uses Runtime PM, but I see no calls to
> pm_runtime_resume_and_get()?

It gets grabbed in *params.c and *stats.c:

linux/drivers/media/platform/arm/mali-c55$ git grep pm_runtime*
mali-c55-capture.c:#include <linux/pm_runtime.h>
mali-c55-capture.c:     ret = pm_runtime_resume_and_get(mali_c55->dev);
mali-c55-capture.c:     pm_runtime_put_autosuspend(mali_c55->dev);
mali-c55-capture.c:     pm_runtime_put_autosuspend(mali_c55->dev);
mali-c55-core.c:#include <linux/pm_runtime.h>
mali-c55-core.c:        SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
mali-c55-core.c:                                pm_runtime_force_resume)
mali-c55-core.c:        pm_runtime_set_autosuspend_delay(&pdev->dev, 2000);
mali-c55-core.c:        pm_runtime_use_autosuspend(&pdev->dev);
mali-c55-core.c:        pm_runtime_set_active(&pdev->dev);
mali-c55-core.c:        pm_runtime_enable(&pdev->dev);
mali-c55-core.c:                goto err_pm_runtime_disable;
mali-c55-core.c:        pm_runtime_idle(&pdev->dev);
mali-c55-core.c:err_pm_runtime_disable:
mali-c55-core.c:        pm_runtime_set_suspended(&pdev->dev);
mali-c55-core.c:        pm_runtime_disable(&pdev->dev);
mali-c55-core.c:        if (!pm_runtime_suspended(&pdev->dev)) {
mali-c55-core.c:                pm_runtime_set_suspended(&pdev->dev);
mali-c55-core.c:        pm_runtime_disable(&pdev->dev);
mali-c55-params.c:#include <linux/pm_runtime.h>
mali-c55-params.c:      ret = pm_runtime_resume_and_get(mali_c55->dev);
mali-c55-params.c:      pm_runtime_put_autosuspend(mali_c55->dev);
mali-c55-params.c:      pm_runtime_put_autosuspend(params->mali_c55->dev);
mali-c55-stats.c:#include <linux/pm_runtime.h>
mali-c55-stats.c:       ret = pm_runtime_resume_and_get(mali_c55->dev);
mali-c55-stats.c:       pm_runtime_put_autosuspend(mali_c55->dev);
mali-c55-stats.c:       pm_runtime_put_autosuspend(stats->mali_c55->dev);
mali-c55-tpg.c:#include <linux/pm_runtime.h>
mali-c55-tpg.c: if (!pm_runtime_get_if_in_use(mali_c55->dev))
mali-c55-tpg.c: pm_runtime_put_autosuspend(mali_c55->dev);

So are you saying these runpaths are not necessarily getting exercised,
so the reference doesn't go up on normal use cases?

Yours,
Linus Walleij

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Jacopo Mondi]

On Wed, Oct 28, 2026 at 09:38:05AM +0100, Linus Walleij wrote:
> On Tue, Oct 27, 2026 at 7:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > The driver uses Runtime PM, but I see no calls to
> > pm_runtime_resume_and_get()?
>
> It gets grabbed in *params.c and *stats.c:
>

pm_runtime_resume_and_get() is called in the .start_streaming handler
for all video nodes (capture, params and stats)

> linux/drivers/media/platform/arm/mali-c55$ git grep pm_runtime*
> mali-c55-capture.c:#include <linux/pm_runtime.h>
> mali-c55-capture.c:     ret = pm_runtime_resume_and_get(mali_c55->dev);
> mali-c55-capture.c:     pm_runtime_put_autosuspend(mali_c55->dev);
> mali-c55-capture.c:     pm_runtime_put_autosuspend(mali_c55->dev);
> mali-c55-core.c:#include <linux/pm_runtime.h>
> mali-c55-core.c:        SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> mali-c55-core.c:                                pm_runtime_force_resume)
> mali-c55-core.c:        pm_runtime_set_autosuspend_delay(&pdev->dev, 2000);
> mali-c55-core.c:        pm_runtime_use_autosuspend(&pdev->dev);
> mali-c55-core.c:        pm_runtime_set_active(&pdev->dev);
> mali-c55-core.c:        pm_runtime_enable(&pdev->dev);
> mali-c55-core.c:                goto err_pm_runtime_disable;
> mali-c55-core.c:        pm_runtime_idle(&pdev->dev);
> mali-c55-core.c:err_pm_runtime_disable:
> mali-c55-core.c:        pm_runtime_set_suspended(&pdev->dev);
> mali-c55-core.c:        pm_runtime_disable(&pdev->dev);
> mali-c55-core.c:        if (!pm_runtime_suspended(&pdev->dev)) {
> mali-c55-core.c:                pm_runtime_set_suspended(&pdev->dev);
> mali-c55-core.c:        pm_runtime_disable(&pdev->dev);
> mali-c55-params.c:#include <linux/pm_runtime.h>
> mali-c55-params.c:      ret = pm_runtime_resume_and_get(mali_c55->dev);
> mali-c55-params.c:      pm_runtime_put_autosuspend(mali_c55->dev);
> mali-c55-params.c:      pm_runtime_put_autosuspend(params->mali_c55->dev);
> mali-c55-stats.c:#include <linux/pm_runtime.h>
> mali-c55-stats.c:       ret = pm_runtime_resume_and_get(mali_c55->dev);
> mali-c55-stats.c:       pm_runtime_put_autosuspend(mali_c55->dev);
> mali-c55-stats.c:       pm_runtime_put_autosuspend(stats->mali_c55->dev);
> mali-c55-tpg.c:#include <linux/pm_runtime.h>
> mali-c55-tpg.c: if (!pm_runtime_get_if_in_use(mali_c55->dev))
> mali-c55-tpg.c: pm_runtime_put_autosuspend(mali_c55->dev);
>
> So are you saying these runpaths are not necessarily getting exercised,

They are when you start streaming on those video devices, if I got
what you mean here.


> so the reference doesn't go up on normal use cases?
>
> Yours,
> Linus Walleij
>

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, 28 Oct 2026 at 10:28, Jacopo Mondi
<jacopo.mondi@ideasonboard.com> wrote:
> On Wed, Oct 28, 2026 at 09:38:05AM +0100, Linus Walleij wrote:
> > On Tue, Oct 27, 2026 at 7:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > The driver uses Runtime PM, but I see no calls to
> > > pm_runtime_resume_and_get()?
> >
> > It gets grabbed in *params.c and *stats.c:
>
> pm_runtime_resume_and_get() is called in the .start_streaming handler
> for all video nodes (capture, params and stats)

OK, but not from .probe(), which does hardware initialization
before that?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Jacopo Mondi]

On Wed, Oct 28, 2026 at 10:47:37AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Wed, 28 Oct 2026 at 10:28, Jacopo Mondi
> <jacopo.mondi@ideasonboard.com> wrote:
> > On Wed, Oct 28, 2026 at 09:38:05AM +0100, Linus Walleij wrote:
> > > On Tue, Oct 27, 2026 at 7:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > The driver uses Runtime PM, but I see no calls to
> > > > pm_runtime_resume_and_get()?
> > >
> > > It gets grabbed in *params.c and *stats.c:
> >
> > pm_runtime_resume_and_get() is called in the .start_streaming handler
> > for all video nodes (capture, params and stats)
>
> OK, but not from .probe(), which does hardware initialization
> before that?

The driver doesn't depend or select PM (to be honest, I don't see why
we would run without PM these days, but that's how things are the
moment).

So the peripheral is manually powered up and pm_runtime enabled in
'active' state

static int mali_c55_probe(struct platform_device *pdev)
{

	ret = __mali_c55_power_on(mali_c55);
	if (ret)
		return dev_err_probe(dev, ret, "failed to power on\n");

	ret = mali_c55_check_hwcfg(mali_c55);
	if (ret)
		goto err_power_off;

	ret = mali_c55_init_context(mali_c55, res);
	if (ret)
		goto err_power_off;

	mali_c55->media_dev.dev = dev;

	pm_runtime_set_autosuspend_delay(&pdev->dev, 2000);
	pm_runtime_use_autosuspend(&pdev->dev);
	pm_runtime_set_active(&pdev->dev);
	pm_runtime_enable(&pdev->dev);

If that wasn't the case, the driver would have failed to identify the
peripheral and would have bailed out in mali_c55_check_hwcfg()



>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v4 4/5] arm64: dts: renesas: r9a09g057: Add IVC and ISP nodes

[Lad, Prabhakar]

Hi

On Thu, Oct 15, 2026 at 1:43 PM Linus Walleij <linusw@kernel.org> wrote:
>
> Hi Jacopo,
>
> On Mon, Oct 12, 2026 at 5:39 PM Jacopo Mondi
> <jacopo.mondi@ideasonboard.com> wrote:
>
> > How was this patch tested ?
>
> I was using the TPG only so far, a camera module is in the mail.
>
> I do have the RPi camera module 3 but didn't get it to work, this
> may explain why...
>
> > > +             ivc: isp-input@16040000 {
> > > +                     compatible = "renesas,r9a09g057-ivc";
> > > +                     reg = <0 0x16040000 0 0x10000>;
> > > +                     clocks = <&cpg CPG_MOD 0xe3>, <&cpg CPG_MOD 0xe4>,
> > > +                              <&cpg CPG_MOD 0xe5>;
> >
> > Compared to Dan's original patch I was carrying my tree the first and
> > third ids of clock and reset properties in the ivc and isp nodes respectivelty
> > are swapped
>
> OK
>
> > -                       resets = <&cpg 0xd3>, <&cpg 0xd1>, <&cpg 0xd2>;
> > +                       resets = <&cpg 0xd2>, <&cpg 0xd1>, <&cpg 0xd3>;
> >                         reset-names = "vresetn", "aresetn", "hresetn";
> >                         status = "disabled";
> >
> > Fixes the issue for me
>
> OK
>
> > Why is this an issue it's not 100% clear to me.
>
> Can you try this?
>
> diff --git a/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> b/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> --- a/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> +++ b/drivers/media/platform/arm/mali-c55/mali-c55-core.c
> @@ -703,6 +703,12 @@
>                 return ret;
>         }
>
> +       /*
> +        * Allow the ISP's 2500-vclk reset recovery time.
> +        * 200 us cover the RZ/V2H's documented minimum of 20 MHz.
> +        */
> +       usleep_range(200, 300);
> +
I tried this too and saw the same issue as Jacopo (Even increasing the
delay didn't help usleep_range(2000, 3000);).

If I add a dummy read of `readl(mali_c55->base +
MALI_C55_REG_PRODUCT);` after the deassert operation all seems OK (cam
application works).

Without any code change what i see when I start cam application is
readl of MALI_C55_REG_MCU_CONFIG doesnt return back and the CPU
stalls. Any idea what is special about MALI_C55_REG_MCU_CONFIG
register?
__mali_c55_power_on()
           mali_c55_update_bits()
                         mali_c55_read()  for MALI_C55_REG_MCU_CONFIG
-> readl never retunrs!


Cheers,
Prabhakar

[PATCH v4 5/5] arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add ISP and IVC nodes

[Linus Walleij]

From: Daniel Scally <dan.scally@ideasonboard.com>

Add nodes to devicetree enabling the ISP and IVC that are found on
the RZ/V2H(P) SoC.

[Rebase onto v7.3-rc1 and sort the board overrides by label.
 - Linus Walleij]

Assisted-by: LLM
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts b/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
index 637fc92dcc26..74b75be599ae 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
+++ b/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
@@ -305,6 +305,14 @@ versa3: clock-generator@69 {
 	};
 };
 
+&isp {
+	status = "okay";
+};
+
+&ivc {
+	status = "okay";
+};
+
 &mdio0 {
 	phy0: ethernet-phy@0 {
 		compatible = "ethernet-phy-id0022.1640";

-- 
2.56.0