Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp7434722rwn; Tue, 13 Sep 2022 21:16:31 -0700 (PDT) X-Google-Smtp-Source: AA6agR7oFKzm8ySrbSt8ldANed1mAkqPCNtJZDBSBqoej6hW4JV5F7KNOZWqRlLDPxCe/ZRUi98S X-Received: by 2002:aa7:d054:0:b0:450:f6b9:bc2e with SMTP id n20-20020aa7d054000000b00450f6b9bc2emr20785662edo.413.1663128990877; Tue, 13 Sep 2022 21:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663128990; cv=none; d=google.com; s=arc-20160816; b=LpxeHG7hscTViPe82y9E4ZxeSpobMCA91AJLWjXaOUdpzCN1rvzZQAjsffFfWcSRAa Q+sSLTC755NsaPUsdCfBtxuLVnNDMMK/iJNbrdi6XhM7glUCvXYeuRwZ855isi2aJqrC snIVFHdgVdJav+vM55eTk6lB/BZo/Bc1EtQ068AWFRoQ4rnvvigf0CCnAgzKOo37Y59S O5oREePSSBxfivD8TypjWZQ/O6HPrPogZp/dBkQnxUcbzmqFG5962CzSAz1SXvsToOxr bLz8+LlrBoTo1YIrP7+t+sstXr8SYykSsb1pT51V+DA7a/yYJywFMSx4G1XEAgU8bsAW T92A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=cg5hk0sMZbzTKba6Tn/22wSERoQIy9AMI7eBhSapFRw=; b=d/cFp395/gXTngrbFYVXTroKRuuc56O1pey+iAbwMDeV87dpH8fhI0ZIY+i1/VBpsu d2H+qFBOKdG8TlWKdpmh3z7S/QA1JzxuokeZW9EKCgY2AM0DUKPQ9GcMsrr0Eczk5mTb wmKNDDTAsyszZykC7BEfyG6xwWNYLM9XDZ0y3foG4TmtxFTbHOamv1a1k76b3jQU1gsY ByynDaLVDUwi8pKcuRI50tKt7/D64PoRc/TnBNAglBko/11vU5jvtkBT9IjVHgORle1G 2Gf+og/XE3xrIG/kKVzXjd3ADS4jI5hxvgRVMpHpTJEwb2Iqw+5qmN+vzuC+T1AnnbkI JScg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=h+rrwWEw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r15-20020a05640251cf00b0044e987f3a34si10757869edd.489.2022.09.13.21.16.03; Tue, 13 Sep 2022 21:16:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=h+rrwWEw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229773AbiINEHx (ORCPT + 99 others); Wed, 14 Sep 2022 00:07:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbiINEHt (ORCPT ); Wed, 14 Sep 2022 00:07:49 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC7B551A0C; Tue, 13 Sep 2022 21:07:47 -0700 (PDT) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28E472eT028147; Wed, 14 Sep 2022 04:07:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=cg5hk0sMZbzTKba6Tn/22wSERoQIy9AMI7eBhSapFRw=; b=h+rrwWEw3pFVPrmouDQliC8tjQ1WplNytVMappcNEY8x9i75Yt6OKsj5ZZXkVLdVWlD8 sFCppdssRNltDkQtwvo0w9BrgjBiqARUpfUOucL/pnfJdfmx11oTKCFh6iaoQnyim7XW LVx74IqEn/wwtOLP13OvlprUS/aE1BRQ5L63WZl30TSMqfPZcRR/FImRFTQBk9RabW81 4qPd/70OpzxbTHF6F/8wp1b/VvWGDSeDWFjNscdIy6n3iAKWxxi6bfP9s3Cg9m97L0Ep pSL4BN1H5EH5ow2GhriXlwnDhWHbXZZkDCJQr4cYl3WsJex4kfvqObKYLGSFobKSgFQW 2w== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3jjxymh5ag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Sep 2022 04:07:38 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 28E47b56008932 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Sep 2022 04:07:37 GMT Received: from [10.216.15.227] (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.986.29; Tue, 13 Sep 2022 21:07:32 -0700 Message-ID: <273d4d8d-8ffd-8d7f-ef82-4287d6256fcc@quicinc.com> Date: Wed, 14 Sep 2022 09:37:29 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH 1/3] clk: qcom: gdsc: Fix the handling of PWRSTS_RET support Content-Language: en-US To: , , , , , CC: , , , , , , AngeloGioacchino Del Regno , Manivannan Sadhasivam , "Krishna chaitanya chundru" References: <20220901101756.28164-1-quic_rjendra@quicinc.com> From: Rajendra Nayak In-Reply-To: <20220901101756.28164-1-quic_rjendra@quicinc.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] 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: qjEILI_Ma_qUFtxfHSk9ir22duknpOkv X-Proofpoint-GUID: qjEILI_Ma_qUFtxfHSk9ir22duknpOkv X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-13_12,2022-09-13_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 priorityscore=1501 malwarescore=0 bulkscore=0 adultscore=0 impostorscore=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 phishscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2208220000 definitions=main-2209140018 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/1/2022 3:47 PM, Rajendra Nayak wrote: > GDSCs cannot be transitioned into a Retention state in SW. > When either the RETAIN_MEM bit, or both the RETAIN_MEM and > RETAIN_PERIPH bits are set, and the GDSC is left ON, the HW > takes care of retaining the memory/logic for the domain when > the parent domain transitions to low power state. > The existing logic handling the PWRSTS_RET seems to set the > RETAIN_MEM/RETAIN_PERIPH bits but then explicitly turns the > GDSC OFF as part of _gdsc_disable(). Fix that by leaving the > GDSC in ON state. Any thoughts on this patch? We now have at-least one more user, PCIe [1] that wants to follow in the footsteps of USB and use RET state to support wake-ups from low power state. [1] https://lore.kernel.org/lkml/20220913164233.GF25849@workstation/ > > Signed-off-by: Rajendra Nayak > Cc: AngeloGioacchino Del Regno > --- > There are a few existing users of PWRSTS_RET and I am not > sure if they would be impacted with this change > > 1. mdss_gdsc in mmcc-msm8974.c, I am expecting that the > gdsc is actually transitioning to OFF and might be left > ON as part of this change, atleast till we hit system wide > low power state. > If we really leak more power because of this > change, the right thing to do would be to update .pwrsts for > mdss_gdsc to PWRSTS_OFF_ON instead of PWRSTS_RET_ON > I dont have a msm8974 hardware, so if anyone who has can report > any issues I can take a look further on how to fix it. > > 2. gpu_gx_gdsc in gpucc-msm8998.c and > gpu_gx_gdsc in gpucc-sdm660.c > Both of these seem to add support for 3 power state > OFF, RET and ON, however I dont see any logic in gdsc > driver to handle 3 different power states. > So I am expecting that these are infact just transitioning > between ON and OFF and RET state is never really used. > The ideal fix for them would be to just update their resp. > .pwrsts to PWRSTS_OFF_ON only. > > drivers/clk/qcom/gdsc.c | 10 ++++++++++ > drivers/clk/qcom/gdsc.h | 5 +++++ > 2 files changed, 15 insertions(+) > > diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c > index d3244006c661..ccf63771e852 100644 > --- a/drivers/clk/qcom/gdsc.c > +++ b/drivers/clk/qcom/gdsc.c > @@ -368,6 +368,16 @@ static int _gdsc_disable(struct gdsc *sc) > if (sc->pwrsts & PWRSTS_OFF) > gdsc_clear_mem_on(sc); > > + /* > + * If the GDSC supports only a Retention state, apart from ON, > + * leave it in ON state. > + * There is no SW control to transition the GDSC into > + * Retention state. This happens in HW when the parent > + * domain goes down to a Low power state > + */ > + if (sc->pwrsts == PWRSTS_RET_ON) > + return 0; > + > ret = gdsc_toggle_logic(sc, GDSC_OFF); > if (ret) > return ret; > diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h > index 5de48c9439b2..981a12c8502d 100644 > --- a/drivers/clk/qcom/gdsc.h > +++ b/drivers/clk/qcom/gdsc.h > @@ -49,6 +49,11 @@ struct gdsc { > const u8 pwrsts; > /* Powerdomain allowable state bitfields */ > #define PWRSTS_OFF BIT(0) > +/* > + * There is no SW control to transition a GDSC into > + * PWRSTS_RET. This happens in HW when the parent > + * domain goes down to a low power state > + */ > #define PWRSTS_RET BIT(1) > #define PWRSTS_ON BIT(2) > #define PWRSTS_OFF_ON (PWRSTS_OFF | PWRSTS_ON)