linux-kernel - Re: [PATCH v2 4/6] arm64: dts: rockchip: Add device tree support for HDMI RX Controller

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: <7657358.31r3eYUQgx@diego>
Date: Tue, 05 Mar 2024 15:11:14 +0100
From: Heiko Stübner <heiko@...ech.de>
To: mchehab@...nel.org, robh@...nel.org, krzysztof.kozlowski+dt@...aro.org,
 conor+dt@...nel.org, mturquette@...libre.com, sboyd@...nel.org,
 p.zabel@...gutronix.de, jose.abreu@...opsys.com, nelson.costa@...opsys.com,
 dmitry.osipenko@...labora.com, sebastian.reichel@...labora.com,
 shawn.wen@...k-chips.com, nicolas.dufresne@...labora.com, hverkuil@...all.nl,
 hverkuil-cisco@...all.nl, Shreeya Patel <shreeya.patel@...labora.com>
Cc: kernel@...labora.com, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-clk@...r.kernel.org, linux-arm@...ts.infradead.org,
 Shreeya Patel <shreeya.patel@...labora.com>
Subject:
 Re: [PATCH v2 4/6] arm64: dts: rockchip: Add device tree support for HDMI RX
 Controller

Hi,


Am Dienstag, 5. März 2024, 13:36:46 CET schrieb Shreeya Patel:
> Add device tree support for Synopsys DesignWare HDMI RX
> Controller.
> 
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@...labora.com>
> Tested-by: Dmitry Osipenko <dmitry.osipenko@...labora.com>
> Co-developed-by: Dingxian Wen <shawn.wen@...k-chips.com>
> Signed-off-by: Dingxian Wen <shawn.wen@...k-chips.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@...labora.com>
> ---
> Changes in v2 :-
>   - Fix some of the checkpatch errors and warnings
>   - Rename resets, vo1-grf and HPD
>   - Move hdmirx_cma node to the rk3588.dtsi file
> 
>  .../boot/dts/rockchip/rk3588-pinctrl.dtsi     | 41 ++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3588.dtsi      | 55 +++++++++++++++++++
>  2 files changed, 96 insertions(+)

> diff --git a/arch/arm64/boot/dts/rockchip/rk3588.dtsi b/arch/arm64/boot/dts/rockchip/rk3588.dtsi
> index 5519c1430cb7..8adb98b99701 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588.dtsi
> @@ -7,6 +7,24 @@
>  #include "rk3588-pinctrl.dtsi"
>  
>  / {
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;

add blank line here

> +		/*
> +		 * The 4k HDMI capture controller works only with 32bit
> +		 * phys addresses and doesn't support IOMMU. HDMI RX CMA
> +		 * must be reserved below 4GB.
> +		 */
> +		hdmirx_cma: hdmirx_cma {

phandles use "_", but node-names "-"

> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x0 0x0 0xffffffff>;
> +			size = <0x0 (160 * 0x100000)>; /* 160MiB */

The comment above that node, could elaborate where the value of 160MB
originates from. I assume it is to hold n-times of 4K frames or whatever,
but it would be helpful for people to be able to read that.


> +			no-map;
> +			status = "disabled";
> +		};
> +	};
> +
>  	pcie30_phy_grf: syscon@...b8000 {
>  		compatible = "rockchip,rk3588-pcie3-phy-grf", "syscon";
>  		reg = <0x0 0xfd5b8000 0x0 0x10000>;
> @@ -85,6 +103,38 @@ i2s10_8ch: i2s@...00000 {
>  		status = "disabled";
>  	};
>  
> +	hdmi_receiver: hdmi-receiver@...e0000 {

Maybe rename the label to "hdmirx:" ... that way in a board enabling the
cma region, both nodes would stay close to each other?


> +		compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
> +		reg = <0x0 0xfdee0000 0x0 0x6000>;
> +		power-domains = <&power RK3588_PD_VO1>;
> +		rockchip,grf = <&sys_grf>;
> +		rockchip,vo1-grf = <&vo1_grf>;
> +		interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
> +		interrupt-names = "cec", "hdmi", "dma";
> +		clocks = <&cru ACLK_HDMIRX>,
> +			 <&cru CLK_HDMIRX_AUD>,
> +			 <&cru CLK_CR_PARA>,
> +			 <&cru PCLK_HDMIRX>,
> +			 <&cru CLK_HDMIRX_REF>,
> +			 <&cru PCLK_S_HDMIRX>,
> +			 <&cru HCLK_VO1>;
> +		clock-names = "aclk",
> +			      "audio",
> +			      "cr_para",
> +			      "pclk",
> +			      "ref",
> +			      "hclk_s_hdmirx",
> +			      "hclk_vo1";

the driver uses of_reserved_mem_device_init(), so doesn't this node need
a "memory-region = <&hdmirx_cma>; or similar?


> +		resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
> +			 <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
> +		reset-names = "axi", "apb", "ref", "biu";
> +		pinctrl-0 = <&hdmim1_rx>;
> +		pinctrl-names = "default";
> +		status = "disabled";
> +	};
> +
>  	pcie3x4: pcie@...50000 {
>  		compatible = "rockchip,rk3588-pcie", "rockchip,rk3568-pcie";
>  		#address-cells = <3>;
> @@ -339,3 +389,8 @@ pcie30phy: phy@...80000 {
>  		status = "disabled";
>  	};
>  };
> +
> +&hdmirx_cma {
> +	status = "okay";
> +};

I'd assume a board that enables &hdmi_receiver would also enable hdmirx_cma
and not the soc dtsi for _all_ boards?


Thanks
Heiko