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

From: Heiko Stuebner
Date: Sat Jun 15 2024 - 18:59:01 EST


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:
> > Hi Detlev,
> >
> > On 2024-06-15 03:56, Detlev Casanova wrote:
> > > 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.
>
> > > Signed-off-by: Detlev Casanova <detlev.casanova@xxxxxxxxxxxxx>
> > > ---
> > >
> > > .../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@xxxxxxxxx>
> > > +
> > > +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.


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