lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c73a32b0-cc58-4d07-a0e5-719e5434adc3@kwiboo.se>
Date: Tue, 8 Apr 2025 20:34:23 +0200
From: Jonas Karlman <jonas@...boo.se>
To: Detlev Casanova <detlev.casanova@...labora.com>
Cc: linux-kernel@...r.kernel.org,
 Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Hans Verkuil <hverkuil@...all.nl>,
 Nicolas Dufresne <nicolas.dufresne@...labora.com>,
 Andrzej Pietrasiewicz <andrzej.p@...labora.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Niklas Cassel <cassel@...nel.org>, Alexey Charkov <alchark@...il.com>,
 Dragan Simic <dsimic@...jaro.org>, Jianfeng Liu <liujianfeng1994@...il.com>,
 Jacopo Mondi <jacopo.mondi@...asonboard.com>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>,
 Kieran Bingham <kieran.bingham@...asonboard.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Umang Jain <umang.jain@...asonboard.com>,
 Naushir Patuck <naush@...pberrypi.com>,
 Jean-Michel Hautbois <jeanmichel.hautbois@...asonboard.com>,
 Dmitry Perchanov <dmitry.perchanov@...el.com>,
 Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-staging@...ts.linux.dev, kernel@...labora.com
Subject: Re: [PATCH v4 6/6] arm64: dts: rockchip: Add rkvdec2 Video Decoder on
 rk3588(s)

Hi Detlev,

On 2025-03-25 22:22, Detlev Casanova wrote:
> Add the rkvdec2 Video Decoder to the RK3588s devicetree.
> 
> Signed-off-by: Detlev Casanova <detlev.casanova@...labora.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 74 +++++++++++++++++++
>  1 file changed, 74 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> index c3abdfb04f8f4..636c287b94e0a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> @@ -1237,6 +1237,70 @@ vepu121_3_mmu: iommu@...ac800 {
>  		#iommu-cells = <0>;
>  	};
>  
> +	vdec0: video-decoder@...38000 {

All other Rockchip decoder/encoder nodes use the video-codec nodename,
e.g. see the av1d related node below. Is there any special reason why
this cannot follow that pattern for nodename consistency?

This was something I tried to bring up in v3 [1], however only the reg
range part was addressed in v4.

My main concern is that I want to send an updated U-Boot RK3582 support
series [2][3] that will need to mark one or both of the two rkvdec cores
as status=fail depending on a value in OTP. This is done in a DT fixup
and uses the nodename for simplicity.

[1] https://lore.kernel.org/r/311770c3-d3ea-4650-ae11-7c278e043d0a@kwiboo.se/
[2] https://patchwork.ozlabs.org/patch/2020972/
[3] https://github.com/Kwiboo/u-boot-rockchip/commit/0d748524aa67ce0debdb87c6e4a0df0f041b1618

> +		compatible = "rockchip,rk3588-vdec";
> +		reg = <0x0 0xfdc38000 0x0 0x100>,
> +		      <0x0 0xfdc38100 0x0 0x500>,
> +		      <0x0 0xfdc38600 0x0 0x100>;
> +		reg-names = "link", "function", "cache";
> +		interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH 0>;
> +		clocks = <&cru ACLK_RKVDEC0>, <&cru HCLK_RKVDEC0>, <&cru CLK_RKVDEC0_CA>,
> +			 <&cru CLK_RKVDEC0_CORE>, <&cru CLK_RKVDEC0_HEVC_CA>;
> +		clock-names = "axi", "ahb", "cabac", "core", "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>;
> +		iommus = <&vdec0_mmu>;
> +		power-domains = <&power RK3588_PD_RKVDEC0>;
> +		resets = <&cru SRST_A_RKVDEC0>, <&cru SRST_H_RKVDEC0>, <&cru SRST_RKVDEC0_CA>,
> +			 <&cru SRST_RKVDEC0_CORE>, <&cru SRST_RKVDEC0_HEVC_CA>;
> +		reset-names = "axi", "ahb", "cabac", "core", "hevc_cabac";
> +		sram = <&vdec0_sram>;
> +	};
> +
> +	vdec0_mmu: iommu@...38700 {
> +		compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
> +		reg = <0x0 0xfdc38700 0x0 0x40>, <0x0 0xfdc38740 0x0 0x40>;
> +		interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH 0>;
> +		clocks = <&cru ACLK_RKVDEC0>, <&cru HCLK_RKVDEC0>;
> +		clock-names = "aclk", "iface";
> +		power-domains = <&power RK3588_PD_RKVDEC0>;
> +		#iommu-cells = <0>;
> +	};
> +
> +	vdec1: video-decoder@...40000 {

Same here :)

Regards,
Jonas

> +		compatible = "rockchip,rk3588-vdec";
> +		reg = <0x0 0xfdc40000 0x0 0x100>,
> +		      <0x0 0xfdc40100 0x0 0x500>,
> +		      <0x0 0xfdc40600 0x0 0x100>;
> +		reg-names = "link", "function", "cache";
> +		interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH 0>;
> +		clocks = <&cru ACLK_RKVDEC1>, <&cru HCLK_RKVDEC1>, <&cru CLK_RKVDEC1_CA>,
> +			 <&cru CLK_RKVDEC1_CORE>, <&cru CLK_RKVDEC1_HEVC_CA>;
> +		clock-names = "axi", "ahb", "cabac", "core", "hevc_cabac";
> +		assigned-clocks = <&cru ACLK_RKVDEC1>, <&cru CLK_RKVDEC1_CORE>,
> +				  <&cru CLK_RKVDEC1_CA>, <&cru CLK_RKVDEC1_HEVC_CA>;
> +		assigned-clock-rates = <800000000>, <600000000>,
> +				       <600000000>, <1000000000>;
> +		iommus = <&vdec1_mmu>;
> +		power-domains = <&power RK3588_PD_RKVDEC1>;
> +		resets = <&cru SRST_A_RKVDEC1>, <&cru SRST_H_RKVDEC1>, <&cru SRST_RKVDEC1_CA>,
> +			 <&cru SRST_RKVDEC1_CORE>, <&cru SRST_RKVDEC1_HEVC_CA>;
> +		reset-names = "axi", "ahb", "cabac", "core", "hevc_cabac";
> +		sram = <&vdec1_sram>;
> +	};
> +
> +	vdec1_mmu: iommu@...40700 {
> +		compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
> +		reg = <0x0 0xfdc40700 0x0 0x40>, <0x0 0xfdc40740 0x0 0x40>;
> +		interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH 0>;
> +		clocks = <&cru ACLK_RKVDEC0>, <&cru HCLK_RKVDEC0>;
> +		clock-names = "aclk", "iface";
> +		power-domains = <&power RK3588_PD_RKVDEC0>;
> +		#iommu-cells = <0>;
> +	};
> +
>  	av1d: video-codec@...70000 {
>  		compatible = "rockchip,rk3588-av1-vpu";
>  		reg = <0x0 0xfdc70000 0x0 0x800>;
> @@ -2883,6 +2947,16 @@ system_sram2: sram@...01000 {
>  		ranges = <0x0 0x0 0xff001000 0xef000>;
>  		#address-cells = <1>;
>  		#size-cells = <1>;
> +
> +		vdec0_sram: codec-sram@0 {
> +			reg = <0x0 0x78000>;
> +			pool;
> +		};
> +
> +		vdec1_sram: codec-sram@...00 {
> +			reg = <0x78000 0x77000>;
> +			pool;
> +		};
>  	};
>  
>  	pinctrl: pinctrl {


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ