Skip to content

arm64: dts: overlay: add radxa display 8hd for rock5t#498

Open
Ken-Vamrs wants to merge 2 commits into
armbian:rk-6.1-rkr5.1from
Ken-Vamrs:rk-6.1-rkr5.1
Open

arm64: dts: overlay: add radxa display 8hd for rock5t#498
Ken-Vamrs wants to merge 2 commits into
armbian:rk-6.1-rkr5.1from
Ken-Vamrs:rk-6.1-rkr5.1

Conversation

@Ken-Vamrs
Copy link
Copy Markdown
Contributor

No description provided.

Signed-off-by: Ken Wang <ken@radxa.com>
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Jun 4, 2026

Review Change Stack

Walkthrough

This pull request adds and registers many Rockchip device-tree overlay plugins (camera and display) and updates the overlay Makefile. Each overlay configures hardware nodes (clocks/regulators/I2C sensors), enables CSI/DPHY/MIPI/CIF/ISP pipeline nodes, wires media ports/endpoints, and defines pinctrl groups; display overlays also configure DSI panels and PWM backlights, and several overlays add Goodix touch controllers.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name Status Explanation Resolution
Description check ⚠️ Warning No pull request description was provided by the author, making it impossible to assess the intent and scope of the changeset. Add a detailed description explaining what the PR accomplishes, why these changes are needed, and which components are affected.
Title check ❓ Inconclusive The title mentions 'radxa display 8hd for rock5t' but the changeset also includes 35+ device-tree overlays for various rock-5b and rock-5t camera modules, displays, and industrial variants. Clarify if the PR focuses primarily on the Radxa Display 8HD, or update the title to reflect the broader scope of camera/display overlays being added.
✅ Passed checks (3 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Signed-off-by: Ken Wang <ken@radxa.com>
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 20

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-radxa-camera-13m-214.dts`:
- Around line 31-33: The CAM0 overlay sets rockchip,camera-module-index = <0>
but incorrectly uses rockchip,camera-module-facing = "front"; change the facing
value to "back" to match the other CAM0 overlays (update the
rockchip,camera-module-facing property in the CAM0 node that contains
rockchip,camera-module-index = <0>), and make the same correction for the second
CAM0 block referenced (the block around the other rockchip,camera-module-index =
<0> instance).

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-13m-214.dts`:
- Around line 48-52: The device tree overlay still sets the property
rockchip,camera-module-name to the wrong value ("RADXA-CAMERA-4K"); update that
property in the overlay (the rock-5b-plus-cam1-radxa-camera-13m-214.dts snippet)
to the correct module name used for the IMX214 board (e.g. "RADXA-CAMERA-13M" or
the exact IMX214 module string your userspace/IQ lookup expects) so userspace
and IQ-file lookups correctly identify the IMX214 module.
- Around line 10-15: The metadata.exclusive key is wrong: it currently reserves
"csi2_dphy1" but this overlay actually occupies the CAM1 path via csi2_dphy3 /
mipi4_csi2; update the metadata.exclusive value to use the same CAM1 exclusivity
key used by the other CAM1 overlays (i.e. replace "csi2_dphy1" with the CAM1 key
corresponding to csi2_dphy3/mipi4_csi2 so it matches the other
rock-5b-plus-cam1-* overlays).

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-4k.dts`:
- Around line 10-15: The exclusivity token in the overlay metadata is wrong:
update the metadata.exclusive value from "csi2_dphy1" to the token that matches
the CAM1 pipeline used by this overlay (e.g., "csi2_dphy3" or the exact mipi4
token used downstream such as "mipi4_csi2") so the overlay's exclusive field
aligns with the wiring in this overlay (metadata.title / metadata.exclusive and
the downstream nodes referencing csi2_dphy3/mipi4_csi2).

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-rpi-camera-v1p3.dts`:
- Around line 34-40: The ov5647@36 node doesn't reference the cam_pwdn_gpio
pinctrl, so its PWDN pin mux/pull isn't applied; update the ov5647 (ov5647@36)
device node to reference the &cam_pwdn_gpio pinctrl by adding pinctrl-names
(e.g., "default") and pinctrl-0 = <&cam_pwdn_gpio> to the ov5647 node so the
cam_pwdn_gpio state defined under &pinctrl is activated for the sensor.

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5b-radxa-camera-8m-219.dts`:
- Around line 8-13: Update the metadata.exclusive property to include the I2C
bus and PWDN GPIO alongside csi2_dphy0 so conflict detection is accurate: add
"i2c3" and "GPIO1_B0" (the resources used by camera_imx219 and camera_pwdn_gpio)
to the exclusive list in the metadata block where metadata.exclusive currently
contains only "csi2_dphy0".

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5b-rpi-camera-v1_3.dts`:
- Around line 32-38: The OV5647 device node enables the power-down GPIO via
pwdn-gpios but never applies the cam_pwdn_gpio pinctrl state; update the ov5647
node (ov5647@36) to reference the pinctrl by adding pinctrl-names (e.g.,
"default") and pinctrl-0 = <&cam_pwdn_gpio> so the cam_pwdn_gpio config defined
later is applied to the same pin used by pwdn-gpios.
- Around line 8-13: The metadata.exclusive entry currently only lists
"csi2_dphy0" but the overlay also consumes the I2C bus and a GPIO pin; update
metadata.exclusive to include "i2c3" and "GPIO1_B0" alongside "csi2_dphy0" so
tooling can detect resource conflicts—modify the metadata block
(metadata.exclusive) to list the full set: csi2_dphy0, i2c3, GPIO1_B0.

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-okdo-5mp-camera.dts`:
- Line 14: The overlay's exclusive property currently only lists "csi2_dphy0"
but should also claim all other hardware resources it consumes to prevent
conflicts; update the node that contains exclusive = "csi2_dphy0" to include
"i2c3" and "GPIO1_D3" (the same identifiers used elsewhere in this overlay) so
the exclusive array reflects csi2_dphy0, i2c3, and GPIO1_D3 together, ensuring
the overlay reserves the CSI DPHY, the I2C controller, and the GPIO pin.

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-radxa-camera-4k.dts`:
- Around line 35-37: The camera overlay sets rockchip,camera-module-index = <0>
but incorrectly labels rockchip,camera-module-facing = "front"; update the
facing metadata to "back" for this CAM0 overlay so module-index 0 consistently
uses back-facing camera role—locate the block containing
rockchip,camera-module-index, rockchip,camera-module-facing, and
rockchip,camera-module-name and change the facing value to "back".

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-okdo-5mp-camera.dts`:
- Around line 8-13: The overlay's metadata.exclusive currently only lists
"csi2_dphy1" but the overlay also drives i2c4 and GPIO2_A6 on CAM1; update the
metadata.exclusive string list to include those shared resources (e.g. add
"i2c4" and "GPIO2_A6" alongside "csi2_dphy1") so the overlay correctly
advertises exclusive use of the CAM1 I2C bus and PWDN GPIO (refer to the
metadata node and the exclusive property in this DTS overlay).

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-radxa-camera-13m-214.dts`:
- Around line 24-33: dw9714_1 currently declares rockchip,camera-module-index =
<0> which mismatches the paired imx214_1 sensor (module index <1>) and will
collide with CAM0; update the dw9714_1 node to use rockchip,camera-module-index
= <1> so the VCM and imx214_1 share the same module index, and apply the same
fix to the other dw9714 instance mentioned (the similar block around the 46-50
range) to ensure both autofocus device nodes use the correct module index
matching their paired sensor.
- Around line 19-22: The &i2c4 node currently enables I2C but does not restore
the CAM1 pinmux; update the CAM1 overlay to select the i2c4 CAM1 pinmux by
adding pinctrl-0 = <&i2c4m1_xfer> and pinctrl-names = "default" (or equivalent)
to the &i2c4 node so the IMX214 and DW9714 can probe; ensure the &i2c4 node
keeps status = "okay" and the existing `#address-cells` / `#size-cells` entries.

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-radxa-camera-4k.dts`:
- Around line 10-15: The metadata.exclusive currently only lists "csi2_dphy1"
but must also advertise the hardware resources the overlay reuses to prevent
unsafe combinability; update the metadata.exclusive property in this overlay
(rock-5t-cam1-radxa-camera-4k.dts) to include the I2C and GPIO tokens used by
the overlay—specifically add "i2c4", "GPIO2_A6" and "GPIO2_B0" alongside
"csi2_dphy1" so sibling CAM1 overlays that touch the same connector cannot be
combined.

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-radxa-camera-8m-219.dts`:
- Around line 8-13: The metadata node's exclusive property currently only lists
"csi2_dphy4", which allows conflicting CAM1 overlays to be enabled; update the
metadata.exclusive value in this overlay to include the shared bus and GPIO
resources used by CAM1 (add "i2c4" and "GPIO2_A6" alongside "csi2_dphy4") so the
overlay manager treats overlays that use the same I2C bus and PWDN GPIO as
mutually exclusive; edit the metadata block (the metadata node and its exclusive
field) to include these additional tokens.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-radxa-camera-4k.dts`:
- Around line 40-42: The imx415_out4 endpoint is wired to the wrong DPHY node
(&mipidphy4_in_ucam0); change the endpoint's remote-endpoint to the port-4 DPHY
input used by the mipi4_csi2 → rkcif_mipi_lvds4 → rkisp1_vir1 CAM1 path (replace
&mipidphy4_in_ucam0 with the port-4 DPHY node that mipi4_csi2 uses), and apply
the same correction to the other identical CAM1 endpoint blocks in the file (the
repeated sections around lines 52–79) so all CAM1 variants target the same DPHY
instance.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-radxa-camera-8m-219.dts`:
- Around line 8-13: The metadata block in this overlay (metadata { ... })
incorrectly sets exclusive = "csi2_dphy4", causing inconsistent conflict
detection with the other industrial CAM1 overlays; update the exclusive property
in this file for the "radxa,rock-5t-industrial" overlay to exclusive =
"csi2_dphy1" so it matches the sibling CAM1 overlays and prevents multiple CAM1
overlays from being selected simultaneously.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-radxa-display-10fhd.dts`:
- Around line 76-77: width-mm and height-mm are incorrectly set to 62 x 110 (a
~5" panel) for the 10FHD overlay; replace those hardcoded values in the
device-tree properties width-mm and height-mm with the actual physical width and
height (in millimetres) from the 10FHD panel datasheet (ensure you update both
properties and keep the unit as mm so userspace computes correct DPI).
- Around line 11-16: The metadata node's exclusive property in the overlay
(metadata { ... exclusive = "dsi1", "GPIO1_A2"; }) must also reserve i2c6 and
pwm4 to prevent conflicting overlays; update the exclusive list for the metadata
node to include "i2c6" and "pwm4" alongside "dsi1" and "GPIO1_A2" so the overlay
manager will block combinations that would share the touchscreen I2C bus or
backlight PWM.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-radxa-display-8hd.dts`:
- Around line 10-15: The metadata.exclusive list currently only includes "dsi1"
and "GPIO1_A2" but must also reserve the I2C and PWM resources used by this
overlay; update the metadata block (the metadata node in the overlay file) to
add "i2c6" and "pwm4" to the exclusive property so the overlay cannot be applied
alongside other overlays that bind the Goodix controller on i2c6 or use pwm4.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 757c77d7-4bd6-4617-bf9d-0958e318ac12

📥 Commits

Reviewing files that changed from the base of the PR and between 2734d8a and df13749.

📒 Files selected for processing (35)
  • arch/arm64/boot/dts/rockchip/overlay/Makefile
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-okdo-5mp-camera.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-okdo-5mp-camera.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-radxa-camera-13m-214.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-radxa-camera-8m-219.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-rpi-camera-v1p3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-rpi-camera-v2.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-okdo-5mp-camera.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-13m-214.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-4k.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-8m-219.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-rpi-camera-v1p3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-rpi-camera-v2.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-radxa-camera-13m-214.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-radxa-camera-8m-219.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-rpi-camera-v1_3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-okdo-5mp-camera.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-radxa-camera-13m-214.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-radxa-camera-4k.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-radxa-camera-8m-219.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-rpi-camera-v1p3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-rpi-camera-v2.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-okdo-5mp-camera.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-radxa-camera-13m-214.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-radxa-camera-4k.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-radxa-camera-8m-219.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-rpi-camera-v1p3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-rpi-camera-v2.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-okdo-5mp-camera.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-radxa-camera-4k.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-radxa-camera-8m-219.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-rpi-camera-v1p3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-rpi-camera-v2.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-radxa-display-10fhd.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-radxa-display-8hd.dts
✅ Files skipped from review due to trivial changes (5)
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam1-rpi-camera-v1p3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-rpi-camera-v2.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-rpi-camera-v2.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-rpi-camera-v1p3.dts
  • arch/arm64/boot/dts/rockchip/overlay/rock-5t-cam0-rpi-camera-v2.dts

Comment on lines +31 to +33
rockchip,camera-module-index = <0>;
rockchip,camera-module-facing = "front";
};
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

CAM0 facing metadata is inconsistent with the other CAM0 overlays.

rockchip,camera-module-facing is "front" here, while the CAM0 overlays in this cohort use "back". This can mislabel camera role/orientation in user space.

Suggested fix
-		rockchip,camera-module-facing = "front";
+		rockchip,camera-module-facing = "back";
...
-		rockchip,camera-module-facing = "front";
+		rockchip,camera-module-facing = "back";

Also applies to: 46-48

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam0-radxa-camera-13m-214.dts`
around lines 31 - 33, The CAM0 overlay sets rockchip,camera-module-index = <0>
but incorrectly uses rockchip,camera-module-facing = "front"; change the facing
value to "back" to match the other CAM0 overlays (update the
rockchip,camera-module-facing property in the CAM0 node that contains
rockchip,camera-module-index = <0>), and make the same correction for the second
CAM0 block referenced (the block around the other rockchip,camera-module-index =
<0> instance).

Comment on lines +10 to +15
metadata {
title ="Enable Radxa Camera 13M 214 on CAM1";
compatible = "radxa,rock-5b-plus";
category = "camera";
exclusive = "csi2_dphy1";
description = "Enable Radxa Camera 13M 214 on CAM1.";
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use the same CAM1 exclusivity key as the other CAM1 overlays.

Line 14 reserves csi2_dphy1, but this overlay actually occupies the CAM1 capture path through csi2_dphy3/mipi4_csi2. That breaks the cross-file exclusivity contract in this series: another rock-5b-plus-cam1-* overlay can slip through even though both target the same CAM1 pipeline.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-13m-214.dts`
around lines 10 - 15, The metadata.exclusive key is wrong: it currently reserves
"csi2_dphy1" but this overlay actually occupies the CAM1 path via csi2_dphy3 /
mipi4_csi2; update the metadata.exclusive value to use the same CAM1 exclusivity
key used by the other CAM1 overlays (i.e. replace "csi2_dphy1" with the CAM1 key
corresponding to csi2_dphy3/mipi4_csi2 so it matches the other
rock-5b-plus-cam1-* overlays).

Comment on lines +48 to +52
rockchip,camera-module-index = <1>;
rockchip,camera-module-facing = "back";
rockchip,camera-module-name = "RADXA-CAMERA-4K";
rockchip,camera-module-lens-name = "DEFAULT";
lens-focus = <&dw9714_1>;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Fix the copied camera module name.

Line 50 still advertises RADXA-CAMERA-4K in the IMX214 overlay. Any userspace or IQ-file lookup that keys off rockchip,camera-module-name will misidentify this module as the IMX415 variant.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-13m-214.dts`
around lines 48 - 52, The device tree overlay still sets the property
rockchip,camera-module-name to the wrong value ("RADXA-CAMERA-4K"); update that
property in the overlay (the rock-5b-plus-cam1-radxa-camera-13m-214.dts snippet)
to the correct module name used for the IMX214 board (e.g. "RADXA-CAMERA-13M" or
the exact IMX214 module string your userspace/IQ lookup expects) so userspace
and IQ-file lookups correctly identify the IMX214 module.

Comment on lines +10 to +15
metadata {
title ="Enable Radxa Camera 4K on CAM1";
compatible = "radxa,rock-5b-plus";
category = "camera";
exclusive = "csi2_dphy1";
description = "Enable Radxa Camera 4K on CAM1.";
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Align the exclusivity token with the CAM1 pipeline this overlay uses.

Line 14 reserves csi2_dphy1, but the overlay itself is wiring the CAM1 path through csi2_dphy3/mipi4_csi2. With the token out of sync, this variant no longer conflicts cleanly with the other rock-5b-plus-cam1-* overlays that target the same downstream path.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-radxa-camera-4k.dts`
around lines 10 - 15, The exclusivity token in the overlay metadata is wrong:
update the metadata.exclusive value from "csi2_dphy1" to the token that matches
the CAM1 pipeline used by this overlay (e.g., "csi2_dphy3" or the exact mipi4
token used downstream such as "mipi4_csi2") so the overlay's exclusive field
aligns with the wiring in this overlay (metadata.title / metadata.exclusive and
the downstream nodes referencing csi2_dphy3/mipi4_csi2).

Comment on lines +34 to +40
ov5647: ov5647@36 {
status = "okay";
compatible = "ovti,ov5647";
reg = <0x36>;
clocks = <&clk_cam_25m_1>;
pwdn-gpios = <&gpio2 RK_PA6 GPIO_ACTIVE_LOW>;
clock-names = "ext_cam_clk_1";
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-rpi-camera-v1p3.dts"

echo "== File exists? =="
ls -l "$FILE"

echo
echo "== Lines around sensor node (34-60 approx) =="
nl -ba "$FILE" | sed -n '1,120p'

echo
echo "== Lines around pinctrl definition (150-220 approx) =="
nl -ba "$FILE" | sed -n '130,240p'

echo
echo "== Find references to cam_pwdn_gpio =="
rg -n "cam_pwdn_gpio" "$FILE" || true

echo
echo "== Find any pinctrl-names/pinctrl-0 on ov5647 node =="
rg -n "ov5647@36|ov5647:|pinctrl-names|pinctrl-0|pwdn-gpios" "$FILE" || true

Repository: armbian/linux-rockchip

Length of output: 318


🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-rpi-camera-v1p3.dts"

echo "== Lines around sensor node (1-120) =="
cat -n "$FILE" | sed -n '1,120p'

echo
echo "== Lines around pinctrl definition (120-260) =="
cat -n "$FILE" | sed -n '120,260p'

echo
echo "== Find references to cam_pwdn_gpio =="
rg -n "cam_pwdn_gpio" "$FILE" || true

echo
echo "== Find any pinctrl bindings on ov5647 node =="
rg -n "(ov5647@36|ov5647:|pinctrl-names|pinctrl-0|pwdn-gpios)" "$FILE" || true

Repository: armbian/linux-rockchip

Length of output: 4477


Hook cam_pwdn_gpio into the ov5647 node’s pinctrl state.
cam_pwdn_gpio is defined under &pinctrl (lines 172-176) for gpio2 RK_PA6, but ov5647@36 (lines 34-40) never references it—so PWDN pin mux/pull config is left to whatever the base DTS sets.

Suggested fix
 	ov5647: ov5647@36 {
 		status = "okay";
 		compatible = "ovti,ov5647";
 		reg = <0x36>;
 		clocks = <&clk_cam_25m_1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cam_pwdn_gpio>;
 		pwdn-gpios = <&gpio2 RK_PA6 GPIO_ACTIVE_LOW>;
 		clock-names = "ext_cam_clk_1";
 		rockchip,camera-module-index = <1>;
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@arch/arm64/boot/dts/rockchip/overlay/rock-5b-plus-cam1-rpi-camera-v1p3.dts`
around lines 34 - 40, The ov5647@36 node doesn't reference the cam_pwdn_gpio
pinctrl, so its PWDN pin mux/pull isn't applied; update the ov5647 (ov5647@36)
device node to reference the &cam_pwdn_gpio pinctrl by adding pinctrl-names
(e.g., "default") and pinctrl-0 = <&cam_pwdn_gpio> to the ov5647 node so the
cam_pwdn_gpio state defined under &pinctrl is activated for the sensor.

Comment on lines +40 to +42
imx415_out4: endpoint {
remote-endpoint = <&mipidphy4_in_ucam0>;
data-lanes = <1 2 3 4>;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Fix the CAM1 sensor routing to use the port-4 DPHY input.

This CAM1 overlay is wired into &csi2_dphy3 / mipidphy4_in_ucam0, while the rest of the file targets the mipi4_csi2rkcif_mipi_lvds4rkisp1_vir1 CAM1 path. As written, the IMX415 is connected to the wrong DPHY instance, so this overlay will not drive the same pipeline as the other industrial CAM1 variants.

Suggested fix
 		port {
 			imx415_out4: endpoint {
-				remote-endpoint = <&mipidphy4_in_ucam0>;
+				remote-endpoint = <&mipidphy4_in_ucam1>;
 				data-lanes = <1 2 3 4>;
 			};
 		};
 	};
 };
@@
-&csi2_dphy3 {
+&csi2_dphy4 {
 	status = "okay";
@@
-			mipidphy4_in_ucam0: endpoint@1 {
-				reg = <1>;
+			mipidphy4_in_ucam1: endpoint@2 {
+				reg = <2>;
 				remote-endpoint = <&imx415_out4>;
 				data-lanes = <1 2 3 4>;
 			};

Also applies to: 52-79

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-radxa-camera-4k.dts`
around lines 40 - 42, The imx415_out4 endpoint is wired to the wrong DPHY node
(&mipidphy4_in_ucam0); change the endpoint's remote-endpoint to the port-4 DPHY
input used by the mipi4_csi2 → rkcif_mipi_lvds4 → rkisp1_vir1 CAM1 path (replace
&mipidphy4_in_ucam0 with the port-4 DPHY node that mipi4_csi2 uses), and apply
the same correction to the other identical CAM1 endpoint blocks in the file (the
repeated sections around lines 52–79) so all CAM1 variants target the same DPHY
instance.

Comment on lines +8 to +13
metadata {
title ="Enable Radxa Camera 8M 219 on CAM1";
compatible = "radxa,rock-5t-industrial";
category = "camera";
exclusive = "csi2_dphy4";
description = "Enable Radxa Camera 8M 219 on CAM1.";
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use the same exclusive group as the other industrial CAM1 overlays.

This file advertises exclusive = "csi2_dphy4", but the sibling industrial CAM1 overlays in this PR use exclusive = "csi2_dphy1". That mismatch weakens overlay conflict detection and allows two CAM1 overlays to be selected together even though they all claim the same i2c6/mipi4_csi2/rkisp1_vir1 path.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-cam1-radxa-camera-8m-219.dts`
around lines 8 - 13, The metadata block in this overlay (metadata { ... })
incorrectly sets exclusive = "csi2_dphy4", causing inconsistent conflict
detection with the other industrial CAM1 overlays; update the exclusive property
in this file for the "radxa,rock-5t-industrial" overlay to exclusive =
"csi2_dphy1" so it matches the sibling CAM1 overlays and prevents multiple CAM1
overlays from being selected simultaneously.

Comment on lines +11 to +16
metadata {
title ="Enable Radxa Display 10FHD";
compatible = "radxa,rock-5t-industrial";
category = "display";
exclusive = "dsi1", "GPIO1_A2";
description = "Enable Radxa Display 10FHD.";
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Add i2c6 to the exclusivity metadata.

Line 15 only reserves dsi1 and GPIO1_A2, but this overlay also instantiates the touchscreen on i2c6. In the supplied PR stack, the industrial CAM1 overlays also consume i2c6, so the overlay manager can currently allow a broken combination. Please reserve i2c6 here as well; pwm4 is worth listing too since the backlight claims it.

Suggested update
-		exclusive = "dsi1", "GPIO1_A2";
+		exclusive = "dsi1", "i2c6", "pwm4", "GPIO1_A2";
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-radxa-display-10fhd.dts`
around lines 11 - 16, The metadata node's exclusive property in the overlay
(metadata { ... exclusive = "dsi1", "GPIO1_A2"; }) must also reserve i2c6 and
pwm4 to prevent conflicting overlays; update the exclusive list for the metadata
node to include "i2c6" and "pwm4" alongside "dsi1" and "GPIO1_A2" so the overlay
manager will block combinations that would share the touchscreen I2C bus or
backlight PWM.

Comment on lines +76 to +77
width-mm = <62>;
height-mm = <110>;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use the actual 10FHD panel size.

Lines 76-77 expose 62 x 110 mm, which is roughly a 5-inch diagonal and does not match a 10FHD panel. Userspace will derive the wrong physical DPI from this.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-radxa-display-10fhd.dts`
around lines 76 - 77, width-mm and height-mm are incorrectly set to 62 x 110 (a
~5" panel) for the 10FHD overlay; replace those hardcoded values in the
device-tree properties width-mm and height-mm with the actual physical width and
height (in millimetres) from the 10FHD panel datasheet (ensure you update both
properties and keep the unit as mm so userspace computes correct DPI).

Comment on lines +10 to +15
metadata {
title ="Enable Radxa Display 8HD";
compatible = "radxa,rock-5t-industrial";
category = "display";
exclusive = "dsi1", "GPIO1_A2";
description = "Enable Radxa Display 8HD.";
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Reserve i2c6 in exclusive too.

Line 14 only declares dsi1 and GPIO1_A2 as exclusive, but this overlay also binds a Goodix controller on i2c6. The industrial CAM1 overlays in this stack also use i2c6, so this metadata currently fails to block an invalid overlay combination. pwm4 should be reserved as well for the same reason.

Suggested update
-		exclusive = "dsi1", "GPIO1_A2";
+		exclusive = "dsi1", "i2c6", "pwm4", "GPIO1_A2";
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@arch/arm64/boot/dts/rockchip/overlay/rock-5t-industrial-radxa-display-8hd.dts`
around lines 10 - 15, The metadata.exclusive list currently only includes "dsi1"
and "GPIO1_A2" but must also reserve the I2C and PWM resources used by this
overlay; update the metadata block (the metadata node in the overlay file) to
add "i2c6" and "pwm4" to the exclusive property so the overlay cannot be applied
alongside other overlays that bind the Goodix controller on i2c6 or use pwm4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants