Am Freitag, 26. November 2021, 08:40:21 CET schrieb Sascha Hauer:
On Thu, Nov 25, 2021 at 09:25:28PM +0100, Johan Jonker wrote:
Hi Sascha,
On 11/17/21 3:33 PM, Sascha Hauer wrote:
The VOP2 is the display output controller on the RK3568. Add the node for it to the dtsi file along with the required display-subsystem node and the iommu node.
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 52 ++++++++++++++++++++++++ 1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi index 46d9552f60284..6ebf7c14e096a 100644 --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi @@ -447,6 +447,58 @@ gmac1_mtl_tx_setup: tx-queues-config { }; };
- display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";ports = <&vop_out>;- };
Some DT sort rules:
For nodes: Sort things without reg alphabetical first, then sort the rest by reg address.
- vop: vop@fe040000 {
compatible = "rockchip,rk3568-vop";From rockchip-vop2.yaml: +properties:
compatible:
enum:
- rockchip,rk3568-vop- rockchip,rk3566-vopMaybe sort yaml compatibles in alphabetical order.
rockchip,rk3566-vop is not used in the dtsi I think.
Comment by Andy Yan:
But take care that the vop on rk3566 has a special limitation: there are three
windows(Cluster1/Esmart1/Smart1) that have a mirror lock, that means they
can't be programed framebuffer address independently , they can only
share framebuffer address with Cluster0/Esmart0/Smart0.
Question: Given Andy's comment could someone explain weather the vop and hdmi nodes should be in rk3566.dtsi and rk3568.dtsi with an extra rockchip,rk3566-dw-hdmi compatible?
We could put the vop/hdmi nodes into rk356x.dtsi and just add the compatible properties to rk3566.dtsi and rk3568.dtsi.
sounds about right. We have similar solutions in place in other socs.
Heiko