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
