mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
synced 2025-09-01 06:39:05 +00:00
loongarch-next
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Dragan Simic
|
e0bd7ecf6b |
arm64: dts: rockchip: Remove overdrive-mode OPPs from RK3588J SoC dtsi
The differences in the vendor-approved CPU and GPU OPPs for the standard Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2] come from the latter, presumably, supporting an extended temperature range that's usually associated with industrial applications, despite the two SoC variant datasheets specifying the same upper limit for the allowed ambient temperature for both variants. However, the lower temperature limit is specified much lower for the RK3588J variant. [1][2] To be on the safe side and to ensure maximum longevity of the RK3588J SoCs, only the CPU and GPU OPPs that are declared by the vendor to be always safe for this SoC variant may be provided. As explained by the vendor [3] and according to the RK3588J datasheet, [2] higher-frequency/higher-voltage CPU and GPU OPPs can be used as well, but at the risk of reducing the SoC lifetime expectancy. Presumably, using the higher OPPs may be safe only when not enjoying the assumed extended temperature range that the RK3588J, as an SoC variant targeted specifically at higher-temperature, industrial applications, is made (or binned) for. Anyone able to keep their RK3588J-based board outside the above-presumed extended temperature range at all times, and willing to take the associated risk of possibly reducing the SoC lifetime expectancy, is free to apply a DT overlay that adds the higher CPU and GPU OPPs. With all this and the downstream RK3588(J) DT definitions [4][5] in mind, let's delete the RK3588J CPU and GPU OPPs that are not considered belonging to the normal operation mode for this SoC variant. To quote the RK3588J datasheet [2], "normal mode means the chipset works under safety voltage and frequency; for the industrial environment, highly recommend to keep in normal mode, the lifetime is reasonably guaranteed", while "overdrive mode brings higher frequency, and the voltage will increase accordingly; under the overdrive mode for a long time, the chipset may shorten the lifetime, especially in high-temperature condition". To sum the RK3588J datasheet [2] and the vendor-provided DTs up, [4][5] the maximum allowed CPU core, GPU and NPU frequencies are as follows: IP core | Normal mode | Overdrive mode ------------+-------------+---------------- Cortex-A55 | 1,296 MHz | 1,704 MHz Cortex-A76 | 1,608 MHz | 2,016 MHz GPU | 700 MHz | 850 MHz NPU | 800 MHz | 950 MHz Unfortunately, when it comes to the actual voltages for the RK3588J CPU and GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and the downstream kernel code. [4][5] The RK3588J datasheet states that "the max. working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while the downstream kernel code actually allows voltage ranges that go up to 0.95 V, which is still within the voltage range allowed by the datasheet. However, the RK3588J datasheet also tells us to "strictly refer to the software configuration of SDK and the hardware reference design", so let's embrace the voltage ranges provided by the downstream kernel code, which also prevents the undesirable theoretical outcome of ending up with no usable OPPs on a particular board, as a result of the board's voltage regulator(s) being unable to deliver the exact voltages, for whatever reason. The above-described voltage ranges for the RK3588J CPU OPPs remain taken from the downstream kernel code [4][5] by picking the highest, worst-bin values, which ensure that all RK3588J bins will work reliably. Yes, with some power inevitably wasted as unnecessarily generated heat, but the reliability is paramount, together with the longevity. This deficiency may be revisited separately at some point in the future. The provided RK3588J CPU OPPs follow the slightly debatable "provide only the highest-frequency OPP from the same-voltage group" approach that's been established earlier, [6] as a result of the "same-voltage, lower-frequency" OPPs being considered inefficient from the IPA governor's standpoint, which may also be revisited separately at some point in the future. [1] https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1.6-20231016.pdf [2] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK3588J_C22364189.pdf [3] https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de/T/#u [4] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi [5] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi [6] https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com/ Fixes: |
||
|
Alexey Charkov
|
a7b2070505 |
arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j
RK3588j uses a different set of OPPs for its GPU, both in terms of allowed frequencies and in terms of voltages. Move the GPU OPPs table into per-variant .dtsi files to accommodate for this difference. The table for RK3588j is adapted from Rockchip downstream sources [1], while RK3588 one is moved verbatim into the per-variant .dtsi file. The values provided for RK3588 in the downstream sources match those in the original commit. [1] |
||
|
Alexey Charkov
|
667885a686 |
arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
RK3588j is the 'industrial' variant of RK3588, and it uses a different
set of OPPs both in terms of allowed frequencies and in terms of
applicable voltages at each frequency setpoint.
Add the OPPs that apply to RK3588j (and apparently RK3588m too) to
enable dynamic CPU frequency scaling.
OPP values are derived from Rockchip downstream sources [1] by taking
only those OPPs which have the highest frequency for a given voltage
level and dropping the rest (if they are included, the kernel complains
at boot time about them being inefficient)
[1]
|
||
|
Dragan Simic
|
def88eb4d8 |
arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs
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. The new naming scheme for the RK3588 SoC dtsi files uses "-base" and "-extra" suffixes to denote the DT data shared between all RK5588 SoC variants, and the DT data shared between the unrestricted SoC variants, respectively. For example, the DT data for the RK3588 includes both rk3588-base.dtsi and rk3588-extra.dtsi, because it's an unrestricted SoC variant, while the DT data for the RK3588S variant includes rk3588-base.dtsi only, because it's a restricted SoC variant, feature- and interface-wise. This achieves a more logical naming of the RK3588 SoC dtsi files, which reflects the way DT data for the SoC variants is built by "stacking" the SoC variant features made available through the "-base" and "-extra" SoC dtsi files. Additionally, the SoC variant dtsi files (rk3588.dtsi, rk3588j.dtsi and rk3588s.dtsi) are no longer parents to any other SoC variant dtsi files, which should help with making the new "stacking" approach cleaner and easier to follow. The RK3588 pinctrl dtsi files are also renamed in the same way, for the sake of consistency. This also keeps the "-base" and "-extra" groups of the dtsi files together when looked at in a directory listing, which is helpful. The per-SoC-variant OPPs should go directly into the SoC dtsi files, if no more than one SoC variant uses those OPPs, or be put into a separate "-opp" dtsi file that's shared between and included from two or more SoC variant dtsi files. An example for the former is the non-shared OPP data that should go directly into the RK3588J SoC variant dtsi file (i.e. rk3588j.dtsi), and an example for the latter is the shared OPP data that should be put into rk3588-opp.dtsi and be included from the RK3588 and RK3588S SoC variant dtsi files (i.e. rk3588.dtsi and rk3588s.dtsi, respectively). Consequently, if the OPPs for the RK3588 and RK3588S SoC variants are ever made different, the shared rk3588-opp.dtsi file should be deleted and the new OPPs should be put directly into rk3588.dtsi and rk3588s.dtsi. [4] No functional changes are introduced, which was validated by decompiling and comparing all affected dtb files before and after these changes. As a side note, due to the nature of introduced changes, this commit is best viewed using the --break-rewrites option for git-log(1). [1] https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/ [2] https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/ [3] https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/ [4] https://lore.kernel.org/linux-rockchip/673dcf47596e7bc8ba065034e339bb1bbf9cdcb0.1716948159.git.dsimic@manjaro.org/T/#u Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/9ffedc0e2ca7f167d9d795b2a8f43cb9f56a653b.1717923308.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> |
||
|
Jagan Teki
|
8274a04ff1 |
arm64: dts: rockchip: Add Rockchip RK3588J
Rockchip RK3588J is the industrial-grade version of RK3588 SoC and is operated with -40 °C to +85 °C temparature. Add rk3588j specific dtsi for adding rk3588j specific operating points and other changes to be add in future. Signed-off-by: Jagan Teki <jagan@edgeble.ai> Link: https://lore.kernel.org/r/20230516163454.997736-2-jagan@edgeble.ai Signed-off-by: Heiko Stuebner <heiko@sntech.de> |