devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Jonas Karlman <jonas@kwiboo.se>,
	Detlev Casanova <detlev.casanova@collabora.com>
Cc: linux-kernel@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	Dragan Simic <dsimic@manjaro.org>,
	Alexey Charkov <alchark@gmail.com>,
	Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
	Diederik de Haas <didi.debian@cknow.org>,
	Andy Yan <andy.yan@rock-chips.com>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	linux-staging@lists.linux.dev
Subject: Re: [PATCH 2/3] media: dt-bindings: rockchip: Document RK3588 Video Decoder 2 bindings
Date: Sun, 16 Jun 2024 00:58:13 +0200	[thread overview]
Message-ID: <4352466.CQOukoFCf9@phil> (raw)
In-Reply-To: <14930500.uLZWGnKmhe@arisu>

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


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




  reply	other threads:[~2024-06-15 22:58 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-15  1:56 [PATCH 0/3] media: rockchip: Add rkvdec2 driver Detlev Casanova
2024-06-15  1:56 ` [PATCH 1/3] media: rockchip: Introduce the " Detlev Casanova
2024-06-15  8:51   ` Diederik de Haas
2024-06-15 19:44     ` Detlev Casanova
2024-06-16  8:40       ` Diederik de Haas
2024-06-17 13:52         ` Nicolas Dufresne
2025-01-29 14:48       ` Piotr Oniszczuk
2025-01-29 16:20         ` Nicolas Dufresne
2025-01-30 10:22           ` Piotr Oniszczuk
2025-01-29 16:50         ` Detlev Casanova
2025-01-30 10:46           ` Piotr Oniszczuk
2025-01-30 14:54             ` Piotr Oniszczuk
2024-06-15 13:55   ` kernel test robot
2024-06-15 17:21   ` kernel test robot
2024-06-15 22:24   ` Dmitry Osipenko
2024-06-15 22:32   ` Dmitry Osipenko
2024-06-16  6:58   ` Andy Yan
2024-06-17 13:40     ` [PATCH " Detlev Casanova
2024-06-17 13:59     ` Nicolas Dufresne
2024-06-16 21:40   ` Jonas Karlman
2024-06-17 13:56     ` Detlev Casanova
2024-06-17  4:49   ` Alex Bee
2024-06-17 14:17     ` Detlev Casanova
2024-06-17 15:10     ` Nicolas Dufresne
2024-06-17  9:47   ` Jianfeng Liu
2024-06-17 14:04     ` Nicolas Dufresne
2024-06-17 14:20       ` Detlev Casanova
2024-06-17 15:22         ` Nicolas Dufresne
2024-06-18 12:13         ` Jianfeng Liu
2024-06-18 12:39           ` Detlev Casanova
2024-06-18 16:34             ` Nicolas Dufresne
2024-06-19  7:41               ` Jianfeng Liu
2024-06-17 15:21       ` Jianfeng Liu
2024-06-17 12:02   ` Dan Carpenter
2024-06-17 14:23     ` Detlev Casanova
2024-06-15  1:56 ` [PATCH 2/3] media: dt-bindings: rockchip: Document RK3588 Video Decoder 2 bindings Detlev Casanova
2024-06-15  3:15   ` Rob Herring (Arm)
2024-06-15  8:11   ` Jonas Karlman
2024-06-15 19:49     ` Detlev Casanova
2024-06-15 22:58       ` Heiko Stuebner [this message]
2024-06-15  1:56 ` [PATCH 3/3] arm64: dts: rockchip: Add rkvdec2 Video Decoder on rk3588(s) Detlev Casanova
2024-06-15  8:25   ` Jonas Karlman
2024-06-15 19:55     ` Detlev Casanova
2024-06-16  7:28       ` Heiko Stuebner
2024-06-17 14:31         ` Detlev Casanova
2024-06-16  9:17       ` Jonas Karlman
2024-06-16 11:55         ` Dragan Simic
2024-06-17 14:36         ` Detlev Casanova

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=4352466.CQOukoFCf9@phil \
    --to=heiko@sntech.de \
    --cc=alchark@gmail.com \
    --cc=andy.yan@rock-chips.com \
    --cc=conor+dt@kernel.org \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=detlev.casanova@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.org \
    --cc=dsimic@manjaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonas@kwiboo.se \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=robh@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).