[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4432e7f5dd9cb75584fb36e1f52497aa@manjaro.org>
Date: Fri, 21 Mar 2025 04:37:16 +0100
From: Dragan Simic <dsimic@...jaro.org>
To: Heiko Stuebner <heiko@...ech.de>
Cc: Quentin Schulz <quentin.schulz@...rry.de>, Alexey Charkov
<alchark@...il.com>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski
<krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>, Viresh Kumar
<viresh.kumar@...aro.org>, Chen-Yu Tsai <wens@...nel.org>, Diederik de Haas
<didi.debian@...ow.org>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org, Kever Yang <kever.yang@...k-chips.com>
Subject: Re: [PATCH v5 7/8] arm64: dts: rockchip: Add OPP data for CPU cores
on RK3588j
Hello all,
On 2025-03-13 20:43, Dragan Simic wrote:
> On 2025-03-13 20:00, Heiko Stuebner wrote:
>> Am Donnerstag, 13. März 2025, 11:42:17 MEZ schrieb Dragan Simic:
>>> On 2025-03-12 11:34, Dragan Simic wrote:
>>> Just as a note, everything above (and even a bit more) is confirmed
>>> and clearly described in the publicly available RK3588J datasheet,
>>> which I'll provide as a reference in my upcoming patch.
>>
>> so just to reiterate my stance, in mainline I really only want
>> frequencies
>> that are not possibly influencing the lifetime of the chip.
>>
>> It doesn't even matter about the variant we're talking about being
>> industrial :-) . When someone is using mainline I want them to be
>> reasonable assured that we don't have stuff in here that may affect
>> the lifetime of their board.
>>
>> All gambling on performance for possible lifetime reduction people
>> can do on their own ... for example with a dt-overlay ;-) .
>>
>> So TL;DR, I agree to both Quentin and Dragan
>
> Thanks! Indeed, we must provide only the OPPs that are declared
> by the manufacturer to be always safe for the particular SoC
> variant. The RK3588J is actually a good example, because it, in
> theory, can run safely at higher OPPs as well, but only when not
> enjoying the extended temperature range that the RK3588J, as an
> SoC variant targeted at industrial applications, is specifically
> made (or binned) for.
>
> Thus, we must support only the RK3588J OPPs that are declared to
> be safe throughout the entire extended temperature range, while
> anyone who actually can assure that their RK3588J-based board is
> never going to run within the extended temperature range, probably
> may safely apply an overlay that adds the higher OPPs. As we
> obviously can't know what will be the temperature conditions, we
> may provide only the lower OPPs that are always safe.
>
> I'll finish the patch and send it over tomorrow or so... I still
> need to go through the changes once again, to make 100% sure I've
> missed nothing, and that I haven't included anything extraneous. :)
For future reference and for anyone interested, below is the link
to the above-mentioned patch.
https://lore.kernel.org/linux-rockchip/f929da061de35925ea591c969f985430e23c4a7e.1742526811.git.dsimic@manjaro.org/T/#u
Powered by blists - more mailing lists