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

[Heiko Stuebner <heiko@sntech.de>]

Am Montag, 20. Oktober 2025, 17:46:25 Mitteleuropäische Sommerzeit schrieb 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.

Normally once the driver-maintainer has applied binding + driver
change, I also pick up the devicetree shortly change after that.

And in most cases the driver change will be in -next the next day,
and the dts change as well or 1-2 days later.

If a CI bot complains, one then goes looking if something went wrong :-) .
But in 99.9% of cases, things just work out.


> > 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.

I guess that might be a nice way to go, as then the main board dts
doesn't has to wait for the drm changes to be finalized :-)


Heiko