From: Heiko Stuebner <heiko@sntech.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
Alexey Charkov <alchark@gmail.com>,
Algea Cao <algea.cao@rock-chips.com>,
Andy Yan <andy.yan@rock-chips.com>,
Cenk Uluisik <cenk.uluisik@googlemail.com>,
Conor Dooley <conor+dt@kernel.org>,
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Jimmy Hon <honyuenkwun@gmail.com>,
Kever Yang <kever.yang@rock-chips.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Maxime Ripard <mripard@kernel.org>,
Muhammed Efe Cetin <efectn@6tel.net>, Ondrej Jirman <megi@xff.cz>,
Rob Herring <robh@kernel.org>, Sandy Huang <hjc@rock-chips.com>
Subject: Re: [PATCH v2 0/5] arm64: dts: rockchip: Add device tree for the Orange Pi CM5 Base board
Date: Tue, 21 Oct 2025 10:41:11 +0200 [thread overview]
Message-ID: <3720286.R56niFO833@phil> (raw)
In-Reply-To: <20251020154625.GB6159@pendragon.ideasonboard.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
Algea Cao <algea.cao@rock-chips.com>,
Muhammed Efe Cetin <efectn@6tel.net>,
Rob Herring <robh@kernel.org>, Jimmy Hon <honyuenkwun@gmail.com>,
Ondrej Jirman <megi@xff.cz>,
Kever Yang <kever.yang@rock-chips.com>,
dri-devel@lists.freedesktop.org, Sandy Huang <hjc@rock-chips.com>,
linux-rockchip@lists.infradead.org,
Cenk Uluisik <cenk.uluisik@googlemail.com>,
Alexey Charkov <alchark@gmail.com>,
Maxime Ripard <mripard@kernel.org>,
Andy Yan <andy.yan@rock-chips.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/5] arm64: dts: rockchip: Add device tree for the Orange Pi CM5 Base board
Date: Tue, 21 Oct 2025 10:41:11 +0200 [thread overview]
Message-ID: <3720286.R56niFO833@phil> (raw)
In-Reply-To: <20251020154625.GB6159@pendragon.ideasonboard.com>
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
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-10-21 8:41 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-05 23:55 [PATCH v2 0/5] arm64: dts: rockchip: Add device tree for the Orange Pi CM5 Base board Laurent Pinchart
2025-10-05 23:55 ` Laurent Pinchart
2025-10-05 23:55 ` [PATCH v2 1/5] dt-bindings: display: rk3588-dw-hdmi-qp: Add tmds-enable-gpios property Laurent Pinchart
2025-10-05 23:55 ` Laurent Pinchart
2025-10-06 11:19 ` Dmitry Baryshkov
2025-10-06 11:19 ` Dmitry Baryshkov
2025-10-06 16:25 ` Laurent Pinchart
2025-10-06 16:25 ` Laurent Pinchart
2025-10-06 16:42 ` Cristian Ciocaltea
2025-10-06 16:42 ` Cristian Ciocaltea
2025-10-08 8:14 ` Laurent Pinchart
2025-10-08 8:14 ` Laurent Pinchart
2025-10-05 23:55 ` [PATCH v2 2/5] drm/rockchip: dw_hdmi_qp: Improve error handling with dev_err_probe() Laurent Pinchart
2025-10-05 23:55 ` Laurent Pinchart
2025-10-06 12:02 ` Dmitry Baryshkov
2025-10-06 12:02 ` Dmitry Baryshkov
2025-10-06 14:37 ` Cristian Ciocaltea
2025-10-06 14:37 ` Cristian Ciocaltea
2025-10-06 16:26 ` Laurent Pinchart
2025-10-06 16:26 ` Laurent Pinchart
2025-10-09 7:24 ` Cristian Ciocaltea
2025-10-09 7:24 ` Cristian Ciocaltea
2025-10-09 9:41 ` Laurent Pinchart
2025-10-09 9:41 ` Laurent Pinchart
2025-10-15 21:14 ` Cristian Ciocaltea
2025-10-15 21:14 ` Cristian Ciocaltea
2025-10-05 23:55 ` [PATCH v2 3/5] drm/rockchip: dw_hdmi_qp: Fixup usage of enable_gpio member in main struct Laurent Pinchart
2025-10-05 23:55 ` Laurent Pinchart
2025-10-05 23:55 ` [PATCH v2 4/5] dt-bindings: arm: rockchip: Add Orange Pi CM5 Base Laurent Pinchart
2025-10-05 23:55 ` Laurent Pinchart
2025-10-05 23:55 ` [PATCH v2 5/5] arm64: dts: rockchip: Add rk3588s-orangepi-cm5-base device tree Laurent Pinchart
2025-10-05 23:55 ` Laurent Pinchart
2025-10-06 16:12 ` Andrew Lunn
2025-10-06 16:12 ` Andrew Lunn
2025-10-20 14:44 ` [PATCH v2 0/5] arm64: dts: rockchip: Add device tree for the Orange Pi CM5 Base board Heiko Stuebner
2025-10-20 14:44 ` Heiko Stuebner
2025-10-20 15:46 ` Laurent Pinchart
2025-10-20 15:46 ` Laurent Pinchart
2025-10-21 8:41 ` Heiko Stuebner [this message]
2025-10-21 8:41 ` Heiko Stuebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3720286.R56niFO833@phil \
--to=heiko@sntech.de \
--cc=alchark@gmail.com \
--cc=algea.cao@rock-chips.com \
--cc=andy.yan@rock-chips.com \
--cc=cenk.uluisik@googlemail.com \
--cc=conor+dt@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=efectn@6tel.net \
--cc=hjc@rock-chips.com \
--cc=honyuenkwun@gmail.com \
--cc=kever.yang@rock-chips.com \
--cc=krzk+dt@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=megi@xff.cz \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.