From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DE63C21FF2B; Wed, 30 Jul 2025 07:12:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=163.172.96.212 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753859540; cv=none; b=knn+Sm9jUrUwwlHVLCd5h45Y8TUMpaORxJ/ygjstwgLX8+GpyiMhrqb6RNjgArH5ftcE9jzM8Y2dVQ4RuetR8/4AazPx2sGRd4xUs/tM8ZukvlbILmw0GcoZjkuOjmzmeqq5QYi2La/wBKa36/7TvdcO40F5DHxH0jP07CYm+Yw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753859540; c=relaxed/simple; bh=ZuSp//kVhmATYjMaP/FNEufGoy6Pa1v9492w4C9YlHs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NBW6rBQxRy+PKZAhOArdFgwSGTwpRd0vUFGUBpLuZisYo58N7EKBTd7m+ZsdQ8IAxBuSpuG9zAUde5bRQgxLO0gznJ8VIu94XK938GJ9HnZZdZQy0MZZzVxiQZdwYeGchGfQo5+II147tJcJ5qX3R4Sbh+sm0gi8eKGJkqx0q4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; arc=none smtp.client-ip=163.172.96.212 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 56U7BjvR026741; Wed, 30 Jul 2025 09:11:45 +0200 Date: Wed, 30 Jul 2025 09:11:45 +0200 From: Willy Tarreau To: Chukun Pan Cc: alchark@gmail.com, conor+dt@kernel.org, devicetree@vger.kernel.org, heiko@sntech.de, jonas@kwiboo.se, krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, ziyao@disroot.org Subject: Re: [PATCH v2 1/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support Message-ID: <20250730071145.GA26734@1wt.eu> References: <20250727170947.GA19379@1wt.eu> <20250730070026.60109-1-amadeus@jmu.edu.cn> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250730070026.60109-1-amadeus@jmu.edu.cn> User-Agent: Mutt/1.10.1 (2018-07-13) Hi! On Wed, Jul 30, 2025 at 03:00:26PM +0800, Chukun Pan wrote: > Hi, > > > It's interesting to note that 816, 1008 and 1200 MHz result in a higher > > frequency than configured, but upper ones result in slightly smaller > > frequencies (~2%, might just be a measurement error), particularly for > > the last one which is 6% lower. > > Please refer to the description of this series: > https://lore.kernel.org/lkml/20250320100002.332720-1-amadeus@jmu.edu.cn/ Yes I had read this one. I'm just getting higher differences on my device here. > During the discussion, it was considered that the minimum voltage should > be 875mV to maintain stability, so there is a deviation in the frequency > between 816MHz and 1200MHz. I tend to agree, especially on low voltages, where the gain in stability is important while the difference in consumptionis barely noticeable. > > I noticed a missing entry for 2 GHz in clk-rk3528.c so I've added it, > > expecting that it would solve the problem: > > > > + RK3036_PLL_RATE(2016000000, 1, 84, 1, 1, 1, 0), > > > > But it had no effect at all, the frequency remains limited to 1896 MHz. > > There is a comment in the bsp kernel: > https://github.com/rockchip-linux/kernel/blob/develop-5.10/drivers/clk/rockchip/clk-rk3528.c#L101 > > Only 408MHz and 600MHz are generated by normal PLL, the rest of the > CPU frequency is controlled by TF-A via SCMI. OK! > > Or maybe we could simply raise the voltage a little bit. The table above > > shows that at 1.15V we're close to the configured OPP and still below the > > stock voltage. This is not critical, but I find it a bit annoying that > > enabling cpufreq results in lower performance than without! > > I also mentioned this in the cover letter. The actual frequency of 2016MHz > requires 1.13V ~ 1.15V. Not sure if this is safe for the rk3528 SoC. My point is that if you disable cpufreq, the CPU is running at 1.2V, which is even higher. I don't know why it's running at this voltage, maybe as the result of initializing some regulators, but that's what we're getting. So the question about safety of running between 1.13-1.15 resolves to "it's at least safer than running without cpufreq" in the current state. And as I mentioned it's clearly linux and not u-boot that is setting 1.2V, because under u-boot and during kernel selection and image loading, my board is at 0.95V. It's only once the kernel starts to boot that it bumps to 1.2V. So there's something to fix somewhere, either by lowering the default setting or by increasing the voltages in OPP, but as it is right now the situation is inconsistent. Regards, Willy