[PATCH v2 0/5] arm64: dts: rockchip: Add device tree for the Orange Pi CM5 Base board

[Laurent Pinchart]

On Mon, Oct 20, 2025 at 04:44:21PM +0200, Heiko Stuebner wrote:
> Am Montag, 6. Oktober 2025, 01:55:36 Mitteleuropäische Sommerzeit schrieb Laurent Pinchart:
> > Hello,
> > 
> > This patch series adds a device tree for the Orange Pi CM5 Base board
> > from Xunlong. This is a combination of a compute module and a carrier
> > board, so the device tree is split in two files.
> > 
> > The work is based on a combination of upstream device trees for other
> > RK3588-based Orange Pi boards and the downstream device tree, all
> > checked against the available schematics for the carrier board. The
> > compute module schematics is unfortunately not available.
> > 
> > The series starts with three patches that add a new tmds-enable-gpios
> > property to the rk3588-dw-hdmi-qp DT binding (1/5) and update the driver
> > accordingly (2/5 and 3/5). Those patches have been authored by Cristian
> > Ciocaltea as part of a larger series, I have incorporated them here
> > as-is.
> > 
> > Patch 4/5 then add a new compatible for the board to arm/rockchip.yaml.
> > The last patch (5/5) adds the device tree for the board.
> > 
> > Patches 2/5 and 3/5 could be merged separately through the DRM tree,
> > but patch 1/5 needs to be merged with the device tree in 5/5 to avoid
> > introducing DT validation warnings. I'd appreciate advice from the DT
> > maintainers regarding how to handle this, as I have been told before
> > that DT bindings and DT sources can't be merged through the same tree.
> 
> I think we generally only care about binding warnings happening
> in linux-next.
> 
> I.e. in most cases, the binding is merged with the driver and
> the dts then into a separate tree - sort of ignoring the local
> binding error, because everything will be fine once stuff comes
> together in linux-next.

Assuming they get merged together in linux-next. If there's a delay,
linux-next will exhibit warnings for some time. I don't know what the
rule is regarding that.

> Speaking of bindings, does your board _need_ the frl-gpio to produce
> any hdmi output? Like could we merge the board without the (optional)
> gpio and then add it later, once the binding+driver have made it in?

With a suitable pull-up I think so. I can submit a v3 with that.

> Just me trying to grab the big chunks earlier in the cycle.

-- 
Regards,

Laurent Pinchart