From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 50C65C28B28 for ; Wed, 12 Mar 2025 10:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RCx5YAH/sAsaL16jy2DXOMRm0Fr1aAKlpBDGrdma5Zw=; b=Q1s5mmJBF6fhd9PSOEd6XaDERh BYX1j05QsIY4vgT2l8g33y16/dEdXe2ncZEyvoruwA7i+meiJBlARbFiL7zbxpS/svdmbMXTiAHvh c9IRtVTYC8SmYQHZrl5XCyUa1hF29D468K8fBnBblQReRPW6SdpL0d7Gd7w+v94UB2f7OLu61ovOf 2dm1cwnmVdySo0agZXp1oabC7/8N33WJcrG0clkhtKeKQtum8/7ZnC0prCaYYZ+Vf8Cnd0p9L0zqe +8qMlmxDEnHFWDydHLfxfPaQ9e3katk2pRgulY3OHtBGE83Dj/iOijy3p4rqi8EaIixnQydWex2A7 HUbb/J4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tsJRd-000000087hW-34gg; Wed, 12 Mar 2025 10:36:13 +0000 Received: from mail.manjaro.org ([2a01:4f8:c0c:51f3::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tsJPx-000000087Ov-3l2x; Wed, 12 Mar 2025 10:34:31 +0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1741775664; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RCx5YAH/sAsaL16jy2DXOMRm0Fr1aAKlpBDGrdma5Zw=; b=WNMOmc6vboNRAgv8JLDAr228Cs7eNkjbwkz0CNj6JfukEymA5BgjrT1MlN9++KpY3Lyo4F PpA1H5ibX3N6R1qU0aU+JVGJesw70AXKUC2rurEwEsMedGq4zpaTxPmTsgT26JhSpP+rj2 c8VRPMruMYnyJdPceQhktYHaYO98OP2UxTtbsnsTbAhzzFUVJgrQPW4UVxqzWwrpf/GuHU KQiriIKlpSJcjTFbkM5yblTCRpxPTKod5q4zUV4bHk0ujc5I4Ryrv25y9MBe4KFar+LxXH VW9hn4uNwUf3GHlzdLON+fT9DIwEL4DsI1GSkn/T28XeywhBQlvsokD/GDUWeQ== Date: Wed, 12 Mar 2025 11:34:21 +0100 From: Dragan Simic To: Quentin Schulz Cc: Alexey Charkov , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Daniel Lezcano , Viresh Kumar , Chen-Yu Tsai , Diederik de Haas , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Kever Yang Subject: Re: [PATCH v5 7/8] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j In-Reply-To: References: <20240617-rk-dts-additions-v5-0-c1f5f3267f1e@gmail.com> <2914631.KiezcSG77Q@diego> Message-ID: X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=dsimic@manjaro.org smtp.mailfrom=dsimic@manjaro.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250312_033430_246446_8174689D X-CRM114-Status: GOOD ( 36.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Quentin, On 2025-03-12 11:15, Quentin Schulz wrote: > On 2/16/25 1:32 PM, Alexey Charkov wrote: >> On Sat, Feb 15, 2025 at 11:30 PM Heiko Stübner >> wrote: >>> Am Samstag, 15. Februar 2025, 19:59:44 MEZ schrieb Alexey Charkov: >>>> On Tue, Feb 11, 2025 at 7:32 PM Quentin Schulz >>>> wrote: >>>>> On 6/17/24 8:28 PM, Alexey Charkov wrote: > [...] >>>>>> + }; >>>>>> + >>>>>> + cluster2_opp_table: opp-table-cluster2 { >>>>>> + compatible = "operating-points-v2"; >>>>>> + opp-shared; >>>>>> + >>>>>> + opp-1416000000 { >>>>>> + opp-hz = /bits/ 64 <1416000000>; >>>>>> + opp-microvolt = <750000 750000 950000>; >>>>>> + clock-latency-ns = <40000>; >>>>>> + }; >>>>>> + opp-1608000000 { >>>>>> + opp-hz = /bits/ 64 <1608000000>; >>>>>> + opp-microvolt = <787500 787500 950000>; >>>>>> + clock-latency-ns = <40000>; >>>>>> + }; >>>>>> + opp-1800000000 { >>>>>> + opp-hz = /bits/ 64 <1800000000>; >>>>>> + opp-microvolt = <875000 875000 950000>; >>>>>> + clock-latency-ns = <40000>; >>>>>> + }; >>>>>> + opp-2016000000 { >>>>>> + opp-hz = /bits/ 64 <2016000000>; >>>>>> + opp-microvolt = <950000 950000 950000>; >>>>>> + clock-latency-ns = <40000>; >>>>>> + }; >>>>> >>>>> opp-1800000000 and opp-2016000000 should be removed as well. >>>>> >>>>> Did I misunderstand what Rockchip did here? Adding Kever in Cc at >>>>> least >>>>> for awareness on Rockchip side :) >>>>> >>>>> I guess another option could be to mark those above as >>>>> >>>>> turbo-mode; >>>>> >>>>> though no clue what this would entail. From a glance at cpufreq, it >>>>> seems that for Rockchip since we use the default cpufreq-dt, it >>>>> would >>>>> mark those as unusable, so essentially a no-op, so better remove >>>>> them >>>>> entirely? >>>> >>>> I believe the opp core just marks 'turbo-mode' opps as >>>> CPUFREQ_BOOST_FREQ, and cpufreq-dt only passes that flag along to >>>> the >>>> cpufreq core. But then to actually use those boost frequencies I >>>> would >>>> guess the governor needs to somehow know the power/thermal >>>> constraints >>>> of the chip?.. Don't know where that is defined. >>> >>> personally I don't believe in "boost" frequencies - except when they >>> are >>> declared officially. >>> >>> Rockchip for the longest time maintains that running the chip outside >>> the declared power/rate envelope can reduce its overall lifetime. >>> >>> So for Rockchip in mainline a "it runs stable for me" has never been >>> a >>> suitable reasoning ;-) . >> >> My key concern here was perhaps that we are looking at a file inside >> the Rockchip source tree which looks relevant by the name of it, but >> doesn't actually get included anywhere for any of the boards. This may >> or may not constitute an endorsement by Rockchip of any OPPs listed >> there :-D > > Rockchip support stated: > > """ > If you run overdrive mode, you do not need to include rk3588j.dtsi, > and you can change it to #incldue rk3588.dtsi to ensure that the > maximum frequency can reach 2GHz > > below picture from datasheet. > """ > > The picture is the table 3-2 Recommended operating conditions, page 30 > from the RK3588J datasheet, e.g. > https://www.lcsc.com/datasheet/lcsc_datasheet_2403201054_Rockchip-RK3588J_C22364189.pdf > > What is overdrive? > > """ > 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 > """ > > according to the same datasheet, end of the same table, page 31. > > so this seems like a turbo-mode frequency to me. > > Additionally, the note for the "normal mode" (the one with the lower > freqs) states: > > """ > 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. > """ > > I believe "industrial environment" means RK3588J used in the > temperatures that aren't OK for the standard RK3588 variant? Thanks a lot for obtaining these clarifications! Yes, I'd say that in this case "industrial environment" boils down to the extended temperature range for the RK3588J variant. >> I haven't seen a TRM for the J variant, nor do I have a board with >> RK3588J to run tests, so it would be great if Kever could chime in >> with how these OPPs are different from the others (or not). >> >>> So while the situation might be strange for the rk3588j, I really >>> only want >>> correct frequencies here please - not any pseudo "turbo freqs". >>> >>> I don't care that much what people do on their own device{s/trees}, >>> but >>> the devicetrees we supply centrally (and to u-boot, etc) should only >>> contain frequencies vetted by the manufacturer. >> >> Fair enough. Let's just try and get another data point on whether >> these frequencies are vetted or not. > > So the higher freqs seems to be vetted (and used by default on > Rockchip's BSP kernel), it just feels like you aren't really supposed > to run those higher frequencies all the time? And especially not in > "industrial environment"? > > I would assume we want to stay on the safer side and remove those > higher frequencies? Heiko? I agree, we should remove the higher-frequency OPPs. I'd like to go through everything once again in detail and prepare a patch that removes the unsafe OPPs, and you could review it once it's on the ML, to make sure it's fine.