[V5,RESEND,3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode
Message ID | 20240413152013.22307-4-quic_jkona@quicinc.com (mailing list archive) |
---|---|
State | Superseded |
Headers |
Received: from sy.mirrors.kernel.org ([147.75.48.161]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-9237-patchwork=linuxtv.org@vger.kernel.org>) id 1rvfDW-0006QV-03 for patchwork@linuxtv.org; Sat, 13 Apr 2024 15:22:58 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id C3FCFB216B8 for <patchwork@linuxtv.org>; Sat, 13 Apr 2024 15:22:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AC7FF45C1C; Sat, 13 Apr 2024 15:21:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="ZWXQm1Hs" X-Original-To: linux-media@vger.kernel.org Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.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 D88071AAC4; Sat, 13 Apr 2024 15:21:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713021704; cv=none; b=eetDXlgvcWbgLZxZuj0xEjdm4EL8iglvt6TcdikOUkHLgx1bGNBZSLOen7csvYBJdI/T0kWalDo76hx0AXoqiytKJ7B61E29iAKHCNrt6CDxzs5HWPsRMSrej173XOx+tfTAlCPhOChEHavBAfO/6XZ/48WaBv47z5P+N3jglCo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713021704; c=relaxed/simple; bh=l9AiGUYR06ith94hYNURsNBicJturfR2mRvwyn7HrXo=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RaaywR1eRFFvOJkb4/C73v73I/t6Fx14HNM/TPrX8x2zCG58Tf5GLNFp8/NZe7LdjfsNZMbsn10cJwORIZiIq5AwbqmUqlq6qQKstR7pAIv7R1Hxjdl6oCh3N91ETsteSnPaw0hXJYFFM/l7lQ3K1k1rBGg2x+B0v4wmQLcnK14= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=ZWXQm1Hs; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 43DEuZJp012977; Sat, 13 Apr 2024 15:21:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s= qcppdkim1; bh=vGFkT1jLAZGFxQ/dkORMXmbS2ozuVVyl+8ASKbyrJS0=; b=ZW XQm1HsFeWpB43mfZ5/0GwHP8LNAolToKFiQ6mhAKi5Lach7n0ixP0mJ1NhViaukZ SQVIdZCUIy2kLwD5/oWCe4hyw1FQB/xJkIa6mLRG+ZYaeTJ8Qt3C5C2GC1KxJBsR ry2LdoEI1j5+Av6mJ/fMP7+lsVSrRlE/bv1HtN9EiuA+POfyjkIYo8EtDEhNY655 K0SrvbSOQTKTJz63XE9zhqQ/ehBRI6jlJA2ZLaRjQxxKYmheTtQde6em6ezbmS8V fvcUiZ236wR1qvMawT+NT7mPIl8l344ayxx/tBAJjpD/b5Gr8pGGAHGk9K4C//Oj s+g6+WmqFo2+w6h32QUg== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3xfjtkgjrq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 13 Apr 2024 15:21:32 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA03.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 43DFLVH4027478 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 13 Apr 2024 15:21:31 GMT Received: from hu-jkona-hyd.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Sat, 13 Apr 2024 08:21:24 -0700 From: Jagadeesh Kona <quic_jkona@quicinc.com> To: Bjorn Andersson <andersson@kernel.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Stanimir Varbanov <stanimir.k.varbanov@gmail.com>, Vikash Garodia <quic_vgarodia@quicinc.com>, Bryan O'Donoghue <bryan.odonoghue@linaro.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Ulf Hansson <ulf.hansson@linaro.org>, "Rafael J . Wysocki" <rafael@kernel.org>, Kevin Hilman <khilman@kernel.org>, Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, "Andy Gross" <agross@kernel.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Abel Vesa <abel.vesa@linaro.org> CC: <linux-arm-msm@vger.kernel.org>, <linux-clk@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>, <linux-pm@vger.kernel.org>, Taniya Das <quic_tdas@quicinc.com>, "Satya Priya Kakitapalli" <quic_skakitap@quicinc.com>, Imran Shaik <quic_imrashai@quicinc.com>, Ajit Pandey <quic_ajipan@quicinc.com>, "Jagadeesh Kona" <quic_jkona@quicinc.com> Subject: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode Date: Sat, 13 Apr 2024 20:50:11 +0530 Message-ID: <20240413152013.22307-4-quic_jkona@quicinc.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240413152013.22307-1-quic_jkona@quicinc.com> References: <20240413152013.22307-1-quic_jkona@quicinc.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: WWYiOEBvnAea0ooKlaywi4XnKgXut6xi X-Proofpoint-GUID: WWYiOEBvnAea0ooKlaywi4XnKgXut6xi X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-13_04,2024-04-09_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2404010003 definitions=main-2404130113 X-LSpam-Score: -3.3 (---) X-LSpam-Report: No, score=-3.3 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_LOW=-0.7,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no |
Series |
PM: domains: Add control for switching back and forth to HW control
|
|
Commit Message
Jagadeesh Kona
April 13, 2024, 3:20 p.m. UTC
Some GDSC client drivers require the GDSC mode to be switched dynamically to HW mode at runtime to gain the power benefits. Typically such client drivers require the GDSC to be brought up in SW mode initially to enable the required dependent clocks and configure the hardware to proper state. Once initial hardware set up is done, they switch the GDSC to HW mode to save power. At the end of usecase, they switch the GDSC back to SW mode and disable the GDSC. Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and get_hwmode_dev callbacks for GDSC's whose respective client drivers require the GDSC mode to be switched dynamically at runtime using dev_pm_genpd_set_hwmode() API. Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> --- drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++ drivers/clk/qcom/gdsc.h | 1 + 2 files changed, 38 insertions(+)
Comments
On 13/04/2024 16:20, Jagadeesh Kona wrote: > Some GDSC client drivers require the GDSC mode to be switched dynamically > to HW mode at runtime to gain the power benefits. Typically such client > drivers require the GDSC to be brought up in SW mode initially to enable > the required dependent clocks and configure the hardware to proper state. > Once initial hardware set up is done, they switch the GDSC to HW mode to > save power. At the end of usecase, they switch the GDSC back to SW mode > and disable the GDSC. > > Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and > get_hwmode_dev callbacks for GDSC's whose respective client drivers > require the GDSC mode to be switched dynamically at runtime using > dev_pm_genpd_set_hwmode() API. > > Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > --- > drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++ > drivers/clk/qcom/gdsc.h | 1 + > 2 files changed, 38 insertions(+) > > diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c > index df9618ab7eea..c5f6be8181d8 100644 > --- a/drivers/clk/qcom/gdsc.c > +++ b/drivers/clk/qcom/gdsc.c > @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain) > return 0; > } > > +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode) > +{ > + struct gdsc *sc = domain_to_gdsc(domain); > + int ret; > + > + ret = gdsc_hwctrl(sc, mode); > + if (ret) > + return ret; > + > + /* Wait for 1usec for mode transition to properly complete */ > + udelay(1); A delay I suspect you don't need - if the HW spec says "takes 1 usec for this to take effect" that's 1 usec from io write completion from APSS to another system agent. You poll for the state transition down below anyway. I'd be pretty certain that's a redundant delay. > + > + /* > + * When GDSC is switched to HW mode, HW can disable the GDSC. > + * When GDSC is switched back to SW mode, the GDSC will be enabled > + * again, hence need to poll for GDSC to complete the power up. > + */ > + if (!mode) > + return gdsc_poll_status(sc, GDSC_ON); > + > + return 0; > +} Other than that, seems fine. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote: > On 13/04/2024 16:20, Jagadeesh Kona wrote: >> Some GDSC client drivers require the GDSC mode to be switched dynamically >> to HW mode at runtime to gain the power benefits. Typically such client >> drivers require the GDSC to be brought up in SW mode initially to enable >> the required dependent clocks and configure the hardware to proper state. >> Once initial hardware set up is done, they switch the GDSC to HW mode to >> save power. At the end of usecase, they switch the GDSC back to SW mode >> and disable the GDSC. >> >> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and >> get_hwmode_dev callbacks for GDSC's whose respective client drivers >> require the GDSC mode to be switched dynamically at runtime using >> dev_pm_genpd_set_hwmode() API. >> >> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> >> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> >> --- >> drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++ >> drivers/clk/qcom/gdsc.h | 1 + >> 2 files changed, 38 insertions(+) >> >> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c >> index df9618ab7eea..c5f6be8181d8 100644 >> --- a/drivers/clk/qcom/gdsc.c >> +++ b/drivers/clk/qcom/gdsc.c >> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain >> *domain) >> return 0; >> } >> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct >> device *dev, bool mode) >> +{ >> + struct gdsc *sc = domain_to_gdsc(domain); >> + int ret; >> + >> + ret = gdsc_hwctrl(sc, mode); >> + if (ret) >> + return ret; >> + >> + /* Wait for 1usec for mode transition to properly complete */ >> + udelay(1); > > A delay I suspect you don't need - if the HW spec says "takes 1 usec for > this to take effect" that's 1 usec from io write completion from APSS to > another system agent. > > You poll for the state transition down below anyway. > > I'd be pretty certain that's a redundant delay. > Thanks Bryan for your review! This 1usec delay is needed every time GDSC is moved in and out of HW control mode and the reason for same is explained in one of the older gdsc driver change at below link https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/ Thanks, Jagadeesh >> + >> + /* >> + * When GDSC is switched to HW mode, HW can disable the GDSC. >> + * When GDSC is switched back to SW mode, the GDSC will be enabled >> + * again, hence need to poll for GDSC to complete the power up. >> + */ >> + if (!mode) >> + return gdsc_poll_status(sc, GDSC_ON); >> + >> + return 0; >> +} > > Other than that, seems fine. > > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> >
On 24/04/2024 10:47, Jagadeesh Kona wrote: > > > On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote: >> On 13/04/2024 16:20, Jagadeesh Kona wrote: >>> Some GDSC client drivers require the GDSC mode to be switched >>> dynamically >>> to HW mode at runtime to gain the power benefits. Typically such client >>> drivers require the GDSC to be brought up in SW mode initially to enable >>> the required dependent clocks and configure the hardware to proper >>> state. >>> Once initial hardware set up is done, they switch the GDSC to HW mode to >>> save power. At the end of usecase, they switch the GDSC back to SW mode >>> and disable the GDSC. >>> >>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and >>> get_hwmode_dev callbacks for GDSC's whose respective client drivers >>> require the GDSC mode to be switched dynamically at runtime using >>> dev_pm_genpd_set_hwmode() API. >>> >>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> >>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> >>> --- >>> drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++ >>> drivers/clk/qcom/gdsc.h | 1 + >>> 2 files changed, 38 insertions(+) >>> >>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c >>> index df9618ab7eea..c5f6be8181d8 100644 >>> --- a/drivers/clk/qcom/gdsc.c >>> +++ b/drivers/clk/qcom/gdsc.c >>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain >>> *domain) >>> return 0; >>> } >>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct >>> device *dev, bool mode) >>> +{ >>> + struct gdsc *sc = domain_to_gdsc(domain); >>> + int ret; >>> + >>> + ret = gdsc_hwctrl(sc, mode); >>> + if (ret) >>> + return ret; >>> + >>> + /* Wait for 1usec for mode transition to properly complete */ >>> + udelay(1); >> >> A delay I suspect you don't need - if the HW spec says "takes 1 usec >> for this to take effect" that's 1 usec from io write completion from >> APSS to another system agent. >> >> You poll for the state transition down below anyway. >> >> I'd be pretty certain that's a redundant delay. >> > > Thanks Bryan for your review! > > This 1usec delay is needed every time GDSC is moved in and out of HW > control mode and the reason for same is explained in one of the older > gdsc driver change at below link > > https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/ > Right. If that is your precedent then you seem to be missing the mb(); between gdsc_hwctrl(); /* mb(); here */ and this udelay(1); --- bod
On 4/24/2024 3:25 PM, Bryan O'Donoghue wrote: > On 24/04/2024 10:47, Jagadeesh Kona wrote: >> >> >> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote: >>> On 13/04/2024 16:20, Jagadeesh Kona wrote: >>>> Some GDSC client drivers require the GDSC mode to be switched >>>> dynamically >>>> to HW mode at runtime to gain the power benefits. Typically such client >>>> drivers require the GDSC to be brought up in SW mode initially to >>>> enable >>>> the required dependent clocks and configure the hardware to proper >>>> state. >>>> Once initial hardware set up is done, they switch the GDSC to HW >>>> mode to >>>> save power. At the end of usecase, they switch the GDSC back to SW mode >>>> and disable the GDSC. >>>> >>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and >>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers >>>> require the GDSC mode to be switched dynamically at runtime using >>>> dev_pm_genpd_set_hwmode() API. >>>> >>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> >>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> >>>> --- >>>> drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++ >>>> drivers/clk/qcom/gdsc.h | 1 + >>>> 2 files changed, 38 insertions(+) >>>> >>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c >>>> index df9618ab7eea..c5f6be8181d8 100644 >>>> --- a/drivers/clk/qcom/gdsc.c >>>> +++ b/drivers/clk/qcom/gdsc.c >>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct >>>> generic_pm_domain *domain) >>>> return 0; >>>> } >>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct >>>> device *dev, bool mode) >>>> +{ >>>> + struct gdsc *sc = domain_to_gdsc(domain); >>>> + int ret; >>>> + >>>> + ret = gdsc_hwctrl(sc, mode); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + /* Wait for 1usec for mode transition to properly complete */ >>>> + udelay(1); >>> >>> A delay I suspect you don't need - if the HW spec says "takes 1 usec >>> for this to take effect" that's 1 usec from io write completion from >>> APSS to another system agent. >>> >>> You poll for the state transition down below anyway. >>> >>> I'd be pretty certain that's a redundant delay. >>> >> >> Thanks Bryan for your review! >> >> This 1usec delay is needed every time GDSC is moved in and out of HW >> control mode and the reason for same is explained in one of the older >> gdsc driver change at below link >> >> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/ >> > > Right. > > If that is your precedent then you seem to be missing the mb(); between > > gdsc_hwctrl(); > > /* mb(); here */ > > and this > > udelay(1); > Sorry, earlier I shared the link to base patch series which has mb() used, but in the mainlined series of the same patch mb() is removed as per the review comments. Please find the mainlined series link:- https://lore.kernel.org/all/1485145581-517-1-git-send-email-rnayak@codeaurora.org/ Thanks, Jagadeesh > --- > bod
On 4/24/24 12:27, Jagadeesh Kona wrote: > > > On 4/24/2024 3:25 PM, Bryan O'Donoghue wrote: >> On 24/04/2024 10:47, Jagadeesh Kona wrote: >>> >>> >>> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote: >>>> On 13/04/2024 16:20, Jagadeesh Kona wrote: >>>>> Some GDSC client drivers require the GDSC mode to be switched dynamically >>>>> to HW mode at runtime to gain the power benefits. Typically such client >>>>> drivers require the GDSC to be brought up in SW mode initially to enable >>>>> the required dependent clocks and configure the hardware to proper state. >>>>> Once initial hardware set up is done, they switch the GDSC to HW mode to >>>>> save power. At the end of usecase, they switch the GDSC back to SW mode >>>>> and disable the GDSC. >>>>> >>>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and >>>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers >>>>> require the GDSC mode to be switched dynamically at runtime using >>>>> dev_pm_genpd_set_hwmode() API. >>>>> >>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> >>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> >>>>> --- >>>>> drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++ >>>>> drivers/clk/qcom/gdsc.h | 1 + >>>>> 2 files changed, 38 insertions(+) >>>>> >>>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c >>>>> index df9618ab7eea..c5f6be8181d8 100644 >>>>> --- a/drivers/clk/qcom/gdsc.c >>>>> +++ b/drivers/clk/qcom/gdsc.c >>>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain) >>>>> return 0; >>>>> } >>>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode) >>>>> +{ >>>>> + struct gdsc *sc = domain_to_gdsc(domain); >>>>> + int ret; >>>>> + >>>>> + ret = gdsc_hwctrl(sc, mode); >>>>> + if (ret) >>>>> + return ret; >>>>> + >>>>> + /* Wait for 1usec for mode transition to properly complete */ >>>>> + udelay(1); >>>> >>>> A delay I suspect you don't need - if the HW spec says "takes 1 usec for this to take effect" that's 1 usec from io write completion from APSS to another system agent. >>>> >>>> You poll for the state transition down below anyway. >>>> >>>> I'd be pretty certain that's a redundant delay. >>>> >>> >>> Thanks Bryan for your review! >>> >>> This 1usec delay is needed every time GDSC is moved in and out of HW control mode and the reason for same is explained in one of the older gdsc driver change at below link >>> >>> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/ >>> >> >> Right. >> >> If that is your precedent then you seem to be missing the mb(); between >> >> gdsc_hwctrl(); >> >> /* mb(); here */ >> >> and this >> >> udelay(1); >> > > Sorry, earlier I shared the link to base patch series which has mb() used, but in the mainlined series of the same patch mb() is removed as per the review comments. > > Please find the mainlined series link:- > https://lore.kernel.org/all/1485145581-517-1-git-send-email-rnayak@codeaurora.org/ Mostly because mb is a solution to a different problem. See this talk for more details: https://youtu.be/i6DayghhA8Q Konrad
On 4/24/24 14:22, Konrad Dybcio wrote: > > > On 4/24/24 12:27, Jagadeesh Kona wrote: >> >> >> On 4/24/2024 3:25 PM, Bryan O'Donoghue wrote: >>> On 24/04/2024 10:47, Jagadeesh Kona wrote: >>>> >>>> >>>> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote: >>>>> On 13/04/2024 16:20, Jagadeesh Kona wrote: >>>>>> Some GDSC client drivers require the GDSC mode to be switched dynamically >>>>>> to HW mode at runtime to gain the power benefits. Typically such client >>>>>> drivers require the GDSC to be brought up in SW mode initially to enable >>>>>> the required dependent clocks and configure the hardware to proper state. >>>>>> Once initial hardware set up is done, they switch the GDSC to HW mode to >>>>>> save power. At the end of usecase, they switch the GDSC back to SW mode >>>>>> and disable the GDSC. >>>>>> >>>>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and >>>>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers >>>>>> require the GDSC mode to be switched dynamically at runtime using >>>>>> dev_pm_genpd_set_hwmode() API. >>>>>> >>>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> >>>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> >>>>>> --- >>>>>> drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++ >>>>>> drivers/clk/qcom/gdsc.h | 1 + >>>>>> 2 files changed, 38 insertions(+) >>>>>> >>>>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c >>>>>> index df9618ab7eea..c5f6be8181d8 100644 >>>>>> --- a/drivers/clk/qcom/gdsc.c >>>>>> +++ b/drivers/clk/qcom/gdsc.c >>>>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain) >>>>>> return 0; >>>>>> } >>>>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode) >>>>>> +{ >>>>>> + struct gdsc *sc = domain_to_gdsc(domain); >>>>>> + int ret; >>>>>> + >>>>>> + ret = gdsc_hwctrl(sc, mode); >>>>>> + if (ret) >>>>>> + return ret; >>>>>> + >>>>>> + /* Wait for 1usec for mode transition to properly complete */ >>>>>> + udelay(1); >>>>> >>>>> A delay I suspect you don't need - if the HW spec says "takes 1 usec for this to take effect" that's 1 usec from io write completion from APSS to another system agent. >>>>> >>>>> You poll for the state transition down below anyway. >>>>> >>>>> I'd be pretty certain that's a redundant delay. >>>>> >>>> >>>> Thanks Bryan for your review! >>>> >>>> This 1usec delay is needed every time GDSC is moved in and out of HW control mode and the reason for same is explained in one of the older gdsc driver change at below link >>>> >>>> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/ >>>> >>> >>> Right. >>> >>> If that is your precedent then you seem to be missing the mb(); between >>> >>> gdsc_hwctrl(); >>> >>> /* mb(); here */ >>> >>> and this >>> >>> udelay(1); >>> >> >> Sorry, earlier I shared the link to base patch series which has mb() used, but in the mainlined series of the same patch mb() is removed as per the review comments. >> >> Please find the mainlined series link:- >> https://lore.kernel.org/all/1485145581-517-1-git-send-email-rnayak@codeaurora.org/ > > Mostly because mb is a solution to a different problem. See this talk > for more details: > > https://youtu.be/i6DayghhA8Q (long story short: you want to read back the register right after writing to make sure things arrive at the hardware when you expect it to) Konrad
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c index df9618ab7eea..c5f6be8181d8 100644 --- a/drivers/clk/qcom/gdsc.c +++ b/drivers/clk/qcom/gdsc.c @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain) return 0; } +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode) +{ + struct gdsc *sc = domain_to_gdsc(domain); + int ret; + + ret = gdsc_hwctrl(sc, mode); + if (ret) + return ret; + + /* Wait for 1usec for mode transition to properly complete */ + udelay(1); + + /* + * When GDSC is switched to HW mode, HW can disable the GDSC. + * When GDSC is switched back to SW mode, the GDSC will be enabled + * again, hence need to poll for GDSC to complete the power up. + */ + if (!mode) + return gdsc_poll_status(sc, GDSC_ON); + + return 0; +} + +static bool gdsc_get_hwmode(struct generic_pm_domain *domain, struct device *dev) +{ + struct gdsc *sc = domain_to_gdsc(domain); + u32 val; + + regmap_read(sc->regmap, sc->gdscr, &val); + + return !!(val & HW_CONTROL_MASK); +} + static int gdsc_init(struct gdsc *sc) { u32 mask, val; @@ -451,6 +484,10 @@ static int gdsc_init(struct gdsc *sc) sc->pd.power_off = gdsc_disable; if (!sc->pd.power_on) sc->pd.power_on = gdsc_enable; + if (sc->flags & HW_CTRL_TRIGGER) { + sc->pd.set_hwmode_dev = gdsc_set_hwmode; + sc->pd.get_hwmode_dev = gdsc_get_hwmode; + } ret = pm_genpd_init(&sc->pd, NULL, !on); if (ret) diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h index 803512688336..1e2779b823d1 100644 --- a/drivers/clk/qcom/gdsc.h +++ b/drivers/clk/qcom/gdsc.h @@ -67,6 +67,7 @@ struct gdsc { #define ALWAYS_ON BIT(6) #define RETAIN_FF_ENABLE BIT(7) #define NO_RET_PERIPH BIT(8) +#define HW_CTRL_TRIGGER BIT(9) struct reset_controller_dev *rcdev; unsigned int *resets; unsigned int reset_count;