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 AB0D5E77180 for ; Wed, 11 Dec 2024 11:36:04 +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:In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/9x17IdFZ2AxnrDuMJbuKHWlp7jBR+NWwqhOCwip1TQ=; b=gf4zczLZ4qlErGhVSvWsQ9BzsO jinrPAw2fVF5/MERgOWtK1p4774ggE1YzlCfSHU/jEqe/wG0IdXXIqy4kbMPl/wiBCUNyF+ZUpy3W +0HDTIl0lv51zt0IyT/c3IlkD26goujJA15giMbV06QiiIE2/oJpTKf1nRWoK1b9nIVj68QL5oTBd THinzlCa4TeVCiXPwgjpg26J09s7DATeBUg23uD6ndyZ72+6rUHRWoll0xr0pSuFm1GgscDD0vrcz ijh38wXpFYgR9dz53BiU7po3hdzpHMLFzf25SfMX1X/7fEiojovfDi1YUT+z3SuHGrOp4FokczlWp yaredgiA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tLL0V-0000000Ej3D-0CaG; Wed, 11 Dec 2024 11:35:55 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tLKxT-0000000EiEK-1v8w for linux-arm-kernel@lists.infradead.org; Wed, 11 Dec 2024 11:32:49 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A41651063; Wed, 11 Dec 2024 03:33:14 -0800 (PST) Received: from [10.1.37.59] (e127648.arm.com [10.1.37.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C70C03F5A1; Wed, 11 Dec 2024 03:32:43 -0800 (PST) Message-ID: <3fab85df-371a-410b-a8de-40b6a62e9efe@arm.com> Date: Wed, 11 Dec 2024 11:32:41 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 6/7] cpufreq: apple-soc: Set fallback transition latency to APPLE_DVFS_TRANSITION_TIMEOUT To: Nick Chan , Hector Martin , Sven Peter , Alyssa Rosenzweig , "Rafael J . Wysocki" , Viresh Kumar , Rob Herring , Krzysztof Kozlowski , Conor Dooley , asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20241211112244.18393-1-towinchenmi@gmail.com> <20241211112244.18393-7-towinchenmi@gmail.com> Content-Language: en-US From: Christian Loehle In-Reply-To: <20241211112244.18393-7-towinchenmi@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241211_033247_550536_87AFADB1 X-CRM114-Status: GOOD ( 13.36 ) 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 On 12/11/24 11:19, Nick Chan wrote: > The driver already assumes transitions will not take longer than > APPLE_DVFS_TRANSITION_TIMEOUT in apple_soc_cpufreq_set_target(), so it > makes little sense to set CPUFREQ_ETERNAL as the transition latency > when the transistion latency is not given by the opp-table. > > Signed-off-by: Nick Chan > --- > drivers/cpufreq/apple-soc-cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c > index 94e57f055a5f..0af36f911bea 100644 > --- a/drivers/cpufreq/apple-soc-cpufreq.c > +++ b/drivers/cpufreq/apple-soc-cpufreq.c > @@ -291,7 +291,7 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy) > > transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev); > if (!transition_latency) > - transition_latency = CPUFREQ_ETERNAL; > + transition_latency = APPLE_DVFS_TRANSITION_TIMEOUT; transition_latency is in ns, APPLE_DVFS_TRANSITION_TIMEOUT in us. LGTM otherwise. > > policy->cpuinfo.transition_latency = transition_latency; > policy->dvfs_possible_from_any_cpu = true;