From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C62A33CAA49 for ; Thu, 11 Jun 2026 10:13:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781172809; cv=none; b=RGz07KnUXfWESdacxQwZmayKzzoOaeomem9mm5h8k3otLloRL7bnI6t6ohIXyn+iF4Es0UqrI1Voe3Ux3p4z46y8eJDfJKbZqpHt2JBpeuGeBCTRd7eXj05nxZoD6lo/seF03roueZcsCSjmuLmcm8AG59eHWmnHDbjHPqavZgw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781172809; c=relaxed/simple; bh=YDo8f7tzdscheRFFMTexaBZIDM1fKlLwL+kHTprN/vY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZMh53gO1naiMmAAszgV3q8cjJgLTi/Jv0x8PnxKcYuRKwz/S9ZIVmCbU6GrO8niifNJgGPCVNjtLkhPD71wwWu9PxeAVfqTTbnV9gDsKOoIQBpTf3q4+L367V11MFlsuQUVWNORZ5WNKt71eSa/WHnyHf5iSuphZLPA5gw6QJn0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=j2mQREcJ; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=StFFehpg; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="j2mQREcJ"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="StFFehpg" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65BA03un318920 for ; Thu, 11 Jun 2026 10:13:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= Bh0jJTozn65zI8Feh54vu2pvrCDOQPSqIdgZRKqSjj8=; b=j2mQREcJVGn9U4G6 cLCM2mYvAT/tC8YYRfzdt76hyaQaOqS4vG60pd5mjHFIKBSCKWkCTE7CpHmKNa5/ TkqDmyE2QAkqH9IfdMPqAjeG1pjxbojsEm9PsEB0tBu6rwo7gODMbZttthQnqgOV MKYkrO7AmZCmM43aSSJq/jZ2o2MOjHNPVC3+ZvVhfCWUlHGrtDPG9yfdihu5lQ/Q LGBI7xZbF8+0769YLIh0zDdkImUDf8NzEWujpa+PeW8zNlfKSXSVbwUR+6+xe9fn TV4Ugfn4Hxr1fVFSj+Y5KRIuk1+iUge31Ik8oHikuBOwF7Ku9o5EbADHkHNyv/rh ssNEHA== Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4eqe6sjx7e-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 11 Jun 2026 10:13:26 +0000 (GMT) Received: by mail-pg1-f199.google.com with SMTP id 41be03b00d2f7-c8581f7723aso4358512a12.0 for ; Thu, 11 Jun 2026 03:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781172806; x=1781777606; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Bh0jJTozn65zI8Feh54vu2pvrCDOQPSqIdgZRKqSjj8=; b=StFFehpgBRBdMoK3HazK2jNH2SSu0KegNXYEs/Fc0BHfok6O65oXcCiMEvf5OwG0QM 9aNen2T/TmxYE8uJc4kXih+vzss9ySuUI81R/4q8T909QoRnLHRjCoiHi8WwoC6/iUJW DAnMLqSUHoFymVr3WDsg6PXQllihY9khnfYL4UvjUlxrIvi2vr29zbwqZVYr2oOAk+UQ q1VA2/ed2EYp4NIuU2GI8i3jJWWOyfMZm+3HxV5Yj7aUMDVy3fLTuq223rcLHmgK/Xxm 213/O7tn/ogpSsiJfipFSEDrYt17HfelEFfEyle2ntZnOFC+k3vnvvumkcY3RyNxBsj2 k/TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781172806; x=1781777606; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Bh0jJTozn65zI8Feh54vu2pvrCDOQPSqIdgZRKqSjj8=; b=Io140K8gxqgdaVWHDEEWiY33inSo8iLgF2tadj8c+EWDws85GVthZdO6fybE1Ii8KA i/sftLkHd8XLhO4tjyw3GJL/dH2kVy9jb5fRvLs3zclZp10TCV3njbuPZxWyT6QHGyUj aRzzuGUSDyDlarnQmWF11ng5ZJw5WYJjBjpCFqesS/tJ80CJAjXeZIrLAf9jinGB7B6Y ru60ZDBU+P/zwR966AwV0mqg/fwTTCwUqxsm+yoxq9ANW8setWdSKYc7ZkRcXmwLWGI9 hRskZ2vmfVeCN1Ie3C0ESFJOKTHFF4s5jnZV0jiAwqjaGgbqjrB92Rhq1vyDrRhOJ1ok hkHA== X-Forwarded-Encrypted: i=1; AFNElJ9TsF50BhuniqqNnu73na5T03hQngBKKcOZKMLq/QG/URylkRXSQWCq2XxDjeotCtGqozvbfBOK3u3T87Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yxg4POODSmrlgi+Z0MYAvXFgbMdtzLfZc4ddKJMR0X8+1UnMSY1 bNLM7KKbATuQYr8kbdl1TcX46bTtTotWF/iaJbjpRZIKo/CGnijNdt3FwjgRReMELOSauwS4CPq NzobEezsdr8TpeiYGU84eLuwBga/BVU7ye5JKYw1zUPOklLQKQCubL5oo7yrynqSZ8gc= X-Gm-Gg: Acq92OHDv7djjbq6AfuI7VBic2SHOkvPDW6Vsh45djoZ/mwrgwqWEBYuPlPgFJAGKXL HivQG5tBvibEVOraj3VVb0juxnRgk2zEwMWjVfLYcDGtha6m7CrH1L6F6aTd3bq/+JdasMtCHuY X09I3xDSp/BlBJDWH4bIX94ohYPKAZp2qk2/rOOVhrOWsc3LfUsebFtrL7Vli6gL/cdfaTqqOFV sGnfUUwh4ou6/zI0nw1FtOU9UlLx9HHvIw+VGuEJ155xYrBCBi/9JpMExIRZx2llVj25o3Pm1bF n4cuZclCFRcVo3/bugahpWxT4T0iVFOSLOcP8HgHZlANEw0mjYjVzb9SlOJu1iaVRD8Eq6WKZfU ffft+X9EW1cLFtCTs1VEaRirwK4yyCLLFixx1UtftoY1QrxFihxZ1cyz0BXbz2O1gXqqWOw== X-Received: by 2002:a17:90b:390a:b0:36d:b818:f848 with SMTP id 98e67ed59e1d1-3779bade6f1mr2514697a91.5.1781172805708; Thu, 11 Jun 2026 03:13:25 -0700 (PDT) X-Received: by 2002:a17:90b:390a:b0:36d:b818:f848 with SMTP id 98e67ed59e1d1-3779bade6f1mr2514650a91.5.1781172805218; Thu, 11 Jun 2026 03:13:25 -0700 (PDT) Received: from hu-arakshit-hyd.qualcomm.com ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-377a5ddd3cdsm797886a91.1.2026.06.11.03.13.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 03:13:24 -0700 (PDT) Date: Thu, 11 Jun 2026 15:43:17 +0530 From: Abhinaba Rakshit To: Manivannan Sadhasivam Cc: Bjorn Andersson , Konrad Dybcio , "James E.J. Bottomley" , "Martin K. Petersen" , Adrian Hunter , Ulf Hansson , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Neeraj Soni , Harshal Dev , Kuldeep Singh , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-mmc@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v11 1/6] soc: qcom: ice: Add OPP-based clock scaling support for ICE Message-ID: References: <20260609-enable-ice-clock-scaling-v11-0-1cebc8b3275b@oss.qualcomm.com> <20260609-enable-ice-clock-scaling-v11-1-1cebc8b3275b@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Proofpoint-GUID: 60d71shlKEr5Et0EEF2U0DN9vxJ-nMB4 X-Proofpoint-Spam-Info: AW1haW4tMjYwNjExMDEwMiBTYWx0ZWRfX0H1mok4NRWkB 7e1pZuFZkqgK7OSjtaTrnp18E4SbH6d25hqklZ7IT3xH0CQfxaDNHU422BplVGxfCBpYs383wgk OrcMSO9E0fuvfOALO4zmAY5L01YdG9c= X-Proofpoint-ORIG-GUID: 60d71shlKEr5Et0EEF2U0DN9vxJ-nMB4 X-Authority-Analysis: v=2.4 cv=Kux9H2WN c=1 sm=1 tr=0 ts=6a2a8a46 cx=c_pps a=Oh5Dbbf/trHjhBongsHeRQ==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=i-GQASlAym38gW1YhUoA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=_Vgx9l1VpLgwpw_dHYaR:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjExMDEwMiBTYWx0ZWRfXxdFrrHCbnJKY CjiUBahldOGKjra9OQ0UPDzVk9VTwlMdgbwmsVJlQtMF3lS+0Y2GL0W+My0ceEL5UPn40mvKica d+t+FlRZDeFEWX+xA+3cDR6hkmjnc0d4kf/8Td4tyEsazEBYwT2TeBWBgQPpa3AGuhWZfyWt9uY JRWNBQAVmN+FOpFvPEuvfYjeBDQ77Ro9Ly3YJr3ldNEFOwRDftZ4T30HKrrkRDqbzTxxbl6nDMd sAO4P9niJHgpXIIqvHl3fTPGWbgC0nMJIYM9WRgiZrKLROqaslI1CqsJgWFWUXMhAL+gaaNITMV ypS/ZY22qG5iaFdoLGBXAlG803XWpYb7C795BeQ7L8oscuoLpb3kCGGtwsEikvXMJvJIebwQ9Ox sfzw47SCRoGUKASFumqwE+Kmf3AymAzY05f1PtQqGu/PQTFJvWNGqVELGdyK+1F6x6nNRfwMk4Z ra6u5qY3JoYLSkAcaPg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-11_02,2026-06-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 malwarescore=0 phishscore=0 spamscore=0 bulkscore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606040000 definitions=main-2606110102 > > diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c > > index 5f20108aa03ebe9a47a10fba9afde420add0f34a..519d08c4727a6cb2dc5991216a2c042ed6218857 100644 > > --- a/drivers/soc/qcom/ice.c > > +++ b/drivers/soc/qcom/ice.c > > @@ -17,6 +17,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > @@ -113,6 +114,8 @@ struct qcom_ice { > > bool use_hwkm; > > bool hwkm_init_complete; > > u8 hwkm_version; > > + unsigned long core_clk_freq; > > + bool has_opp; > > }; > > > > static DEFINE_XARRAY(ice_handles); > > @@ -315,6 +318,10 @@ int qcom_ice_resume(struct qcom_ice *ice) > > struct device *dev = ice->dev; > > int err; > > > > + /* Restore the ICE core clk freq */ > > Redundant comment. Ack. Will drop. > > + if (ice->has_opp && ice->core_clk_freq) > > Can core clk be 0 if OPP is used? In the current logic, core_clk_freq will always be non-zero if has_opp is true. I included the check to decouple the two variables defensively, but I agree it's redundant if we assume the OPP table is the sole source of frequency scaling here. I will simplify this to *if (ice->has_opp)* and ensure core_clk_freq is initialized within the OPP registration block. > > + dev_pm_opp_set_rate(ice->dev, ice->core_clk_freq); > > + > > err = clk_prepare_enable(ice->core_clk); > > if (err) { > > dev_err(dev, "Failed to enable core clock: %d\n", err); > > @@ -335,6 +342,11 @@ int qcom_ice_suspend(struct qcom_ice *ice) > > { > > clk_disable_unprepare(ice->iface_clk); > > clk_disable_unprepare(ice->core_clk); > > + > > + /* Drop the clock votes while suspend */ > > Redundant comment. Ack. Will drop. > > + if (ice->has_opp) > > + dev_pm_opp_set_rate(ice->dev, 0); > > + > > ice->hwkm_init_complete = false; > > > > return 0; > > @@ -560,6 +572,51 @@ int qcom_ice_import_key(struct qcom_ice *ice, > > } > > EXPORT_SYMBOL_GPL(qcom_ice_import_key); > > > > +/** > > + * qcom_ice_scale_clk() - Scale ICE clock for DVFS-aware operations > > + * @ice: ICE driver data > > + * @target_freq: requested frequency in Hz > > + * @round_ceil: when true, selects nearest freq >= @target_freq; > > + * otherwise, selects nearest freq <= @target_freq > > + * > > + * Selects an OPP frequency based on @target_freq and the rounding direction > > + * specified by @round_ceil, then programs it using dev_pm_opp_set_rate(), > > + * including any voltage or power-domain transitions handled by the OPP > > + * framework. Updates ice->core_clk_freq on success. > > + * > > + * Return: 0 on success; -EOPNOTSUPP if no OPP table; or error from > > s/error/errno Ack. Will update. > > + * dev_pm_opp_set_rate()/OPP lookup. > > + */ > > +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq, > > + bool round_ceil) > > +{ > > + unsigned long ice_freq = target_freq; > > + struct dev_pm_opp *opp; > > + int ret; > > + > > + if (!ice->has_opp) > > + return -EOPNOTSUPP; > > + > > + if (round_ceil) > > + opp = dev_pm_opp_find_freq_ceil(ice->dev, &ice_freq); > > + else > > + opp = dev_pm_opp_find_freq_floor(ice->dev, &ice_freq); > > + > > + if (IS_ERR(opp)) > > + return PTR_ERR(opp); > > + dev_pm_opp_put(opp); > > + > > + ret = dev_pm_opp_set_rate(ice->dev, ice_freq); > > + if (ret) { > > + dev_err(ice->dev, "Unable to scale ICE clock rate\n"); > > + return ret; > > + } > > + ice->core_clk_freq = ice_freq; > > + > > + return ret; > > return 0; Ack. Will update. > > +} > > +EXPORT_SYMBOL_GPL(qcom_ice_scale_clk); > > + > > static struct qcom_ice *qcom_ice_create(struct device *dev, > > void __iomem *base) > > { > > @@ -738,6 +795,7 @@ static int qcom_ice_probe(struct platform_device *pdev) > > unsigned long phandle = pdev->dev.of_node->phandle; > > struct qcom_ice *engine; > > void __iomem *base; > > + int err; > > > > guard(mutex)(&ice_mutex); > > > > @@ -756,6 +814,41 @@ static int qcom_ice_probe(struct platform_device *pdev) > > return PTR_ERR(engine); > > } > > > > + err = devm_pm_opp_set_clkname(&pdev->dev, "core"); > > + if (err && err != -ENOENT) { > > + dev_err(&pdev->dev, "Unable to set core clkname to OPP-table\n"); > > + /* Store the error pointer for devm_of_qcom_ice_get() */ > > + xa_store(&ice_handles, phandle, ERR_PTR(err), GFP_KERNEL); > > + return err; > > + } > > + > > + /* OPP table is optional */ > > + err = devm_pm_opp_of_add_table(&pdev->dev); > > + if (err && err != -ENODEV) { > > + dev_err(&pdev->dev, "Invalid OPP table in Device tree\n"); > > + /* Store the error pointer for devm_of_qcom_ice_get() */ > > + xa_store(&ice_handles, phandle, ERR_PTR(err), GFP_KERNEL); > > + return err; > > + } > > + > > + /* > > + * The OPP table is optional. devm_pm_opp_of_add_table() returns > > + * -ENODEV when no OPP table is present in DT, which is not treated > > + * as an error. Therefore, track successful OPP registration only > > + * when err is not -ENODEV. > > + */ > > + if (err == -ENODEV) > > + dev_info(&pdev->dev, "ICE OPP table is not registered, please update your DT\n"); > > dev_dbg() please. No need to spam old DTs. I intentionally used dev_info() here as it would provide a quick diagnostic hint for KPI/performance regressions as mentioned in the cover-letter, which can be difficult to trace. But I’m fine switching to dev_dbg() to avoid log noise if that’s preferred. > > + else > > + engine->has_opp = true; > > + > > + /* > > + * Store the core clock rate for suspend resume cycles, > > + * against OPP aware DVFS operations. core_clk_freq will > > + * have a valid value only for non-legacy bindings. > > use full 80 column width for comments. Ack. Will reformat the comment to include it within 80 columns. > > + */ > > + engine->core_clk_freq = clk_get_rate(engine->core_clk); > > Why can't you conditionally cache the freq by moving it to the above else > condition? For core_clk_freq, I agree moving it under the else improves clarity and clearly defines the purpose of the variable. I kept it outside earlier to avoid tying it strictly to OPP presence, but I can move it for better readability. Abhinaba Rakshit