[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <171891591943.88443.4575073298967084067.b4-ty@sntech.de>
Date: Thu, 20 Jun 2024 22:39:56 +0200
From: Heiko Stuebner <heiko@...ech.de>
To: Dragan Simic <dsimic@...jaro.org>,
linux-rockchip@...ts.infradead.org
Cc: Heiko Stuebner <heiko@...ech.de>,
jonas@...boo.se,
robh+dt@...nel.org,
conor+dt@...nel.org,
devicetree@...r.kernel.org,
didi.debian@...ow.org,
alchark@...il.com,
krzk+dt@...nel.org,
linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs
On Sun, 9 Jun 2024 10:58:19 +0200, Dragan Simic wrote:
> Rename the Rockchip RK3588 SoC dtsi files and, consequently, adjust their
> contents appropriately, to prepare them for the ability to specify different
> CPU and GPU OPPs for each of the supported RK3588 SoC variants.
>
> As already discussed, [1][2][3][4] some of the RK3588 SoC variants require
> different OPPs, and it makes more sense to have the OPPs already defined when
> a board dts(i) file includes one of the SoC variant dtsi files (rk3588.dtsi,
> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts(i) file
> to also include a separate rk3588*-opp.dtsi file. The choice of the SoC
> variant is already made by the inclusion of the SoC dtsi file into the board
> dts(i) file, and it doesn't make much sense to, effectively, allow the board
> dts(i) file to include and use an incompatible set of OPPs for the already
> selected RK3588 SoC variant.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs
commit: 0866aef9b478a50a4035c90428c990485e9d2d6d
Best regards,
--
Heiko Stuebner <heiko@...ech.de>
Powered by blists - more mailing lists