Thread (45 messages) flat view 45 messages, 13 authors, 2025-01-30

Re: [PATCH 2/3] media: dt-bindings: rockchip: Document RK3588 Video Decoder 2 bindings

From: Heiko Stuebner <heiko@sntech.de>
Date: 2024-06-15 22:58:48
Also in: linux-devicetree, linux-media, linux-rockchip, linux-staging, lkml

Am Samstag, 15. Juni 2024, 21:49:21 CEST schrieb Detlev Casanova:
On Saturday, June 15, 2024 4:11:00 A.M. EDT Jonas Karlman wrote:
quoted
Hi Detlev,

On 2024-06-15 03:56, Detlev Casanova wrote:
quoted
Document the Rockchip RK3588 Video Decoder 2 bindings.
Why the need for a new schema file and not just extending existing
rockchip,vdec.yaml with a new compatible and the new clock?
Yes, that can work as well indeed. I wasn't sure if different drivers could 
share a schema file.
quoted
quoted
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---

 .../bindings/media/rockchip,vdec2.yaml        | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644
 Documentation/devicetree/bindings/media/rockchip,vdec2.yaml> 
diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec2.yaml
b/Documentation/devicetree/bindings/media/rockchip,vdec2.yaml new file
mode 100644
index 000000000000..e54891b46986
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip,vdec2.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip,vdec2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Video Decoder 2 (VDec2)
+
+maintainers:
+  - Heiko Stuebner <heiko@sntech.de>
+
+description: |-
+  The Rockchip rk3588 has a stateless Video Decoder that can decodes
H.264, +  HEVC, VP9 and AVS2 streams.
+
+properties:
+  compatible:
+    const: rockchip,rk3588-vdec2
I fail to see the need to call this vdec2 instead of established vdec.

Suggest this is changed to rockchip,rk3588-vdec.
Wouldn't that be misleading if rockchip,rk3399-vdec and rockchip,rk3588-vdec 
use different drivers ?
Devicetrees and their binding don't care about how operating system
implement things in drivers. 

While they come with the Linux-kernel most of the time, they are pretty
much independent from implementation details.

quoted
quoted
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: The Video decoder AXI interface clock
+      - description: The Video decoder AHB interface clock
+      - description: The Video decoder core clock
+      - description: The Video decoder CABAC clock
+      - description: The Video decoder HEVC CABAC clock
+
+  clock-names:
+    items:
+      - const: axi
+      - const: ahb
+      - const: core
+      - const: cabac
+      - const: hevc_cabac
+
+  assigned-clocks: true
+
+  assigned-clock-rates: true
+
+  power-domains:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+    #include <dt-bindings/power/rk3588-power.h>
+
+    vdec2: video-codec@fdc38100 {
+        compatible = "rockchip,rk3588-vdec2";
+        reg = <0x0 0xfdc38100 0x0 0x500>;
+        interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH 0>;
+        clocks = <&cru ACLK_RKVDEC0>, <&cru HCLK_RKVDEC0>, <&cru
CLK_RKVDEC0_CORE>, +                 <&cru CLK_RKVDEC0_CA>, <&cru
CLK_RKVDEC0_HEVC_CA>; +        clock-names = "axi", "ahc", "core",
+                      "cabac", "hevc_cabac";
+        assigned-clocks = <&cru ACLK_RKVDEC0>, <&cru CLK_RKVDEC0_CORE>,
+                          <&cru CLK_RKVDEC0_CA>, <&cru
CLK_RKVDEC0_HEVC_CA>; +        assigned-clock-rates = <800000000>,
<600000000>,
+                               <600000000>, <1000000000>;
+        power-domains = <&power RK3588_PD_RKVDEC0>;
iommus and resets seem to be missing?
Indeed, even if their are not used yet, I'd make sens to already have them 
here to stabilize the device tree, right ?
correct. DT only ever describes the hardware. And while it is possible
to extend bindings later, having the obvious things in it from the start
makes a lot of sense.



Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help