Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp4447270pxb; Mon, 21 Feb 2022 21:55:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJzLE1F57P7K8MWbBA8tLCXMc44LEmNaN8lJRzB/jwv9rfFRtXs4Klrr3Ty6Omn0sgJbVQRT X-Received: by 2002:a05:6a00:26e0:b0:4e1:7131:de2b with SMTP id p32-20020a056a0026e000b004e17131de2bmr23241774pfw.20.1645509329263; Mon, 21 Feb 2022 21:55:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645509329; cv=none; d=google.com; s=arc-20160816; b=GzNF6x9dxJIlpnIm+KzYRDxjXKZM189ZunJfgWAYaBlOHheYDfQH8PJDwZjQD41MBn 0gZumaEksQD1fcWd94NQ/o7FHwXGms1PALYwvXBx7sOA+sufte49JNAlnfYYlRMIZp/O VZhvjDoxK4wGJUBfxzE36VHcI08Q6ECug1qvrgexkHbGFbaf8t7K9h//3sW6yuO7rSay BQkQck9HxhL7e9SzkkY+UUAt6g8g7ZajfSsu8BLvYhpEAfTbi+jjql+0iXb/gMmgfsIu R2NF6w8u5TKE/v0SpOpGf0Gcx3hIZZYkoODlsR1i8z9hKHWH7J2zM9F9giC1X0gPOImV XxxQ== 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:dmarc-filter:sender:dkim-signature; bh=DzZH06prTIghA5OnLx3lGCwq5J4ljZ83zScuiDwYEFA=; b=K2SiMIjLIS3/VPHrbb/THF+IHM88IE7Qj6DKhaI6iGVNQGmi3i1otfbcLUACYSlNvu vIPpgi3wwwkcF2PR5Kmne8jtqcMp5V4sOLmbaeQ2cJjWDd/Dn8xD43kwoeACD7fMNFqj GjeEOvNrWwRKcLhld6DK+K70EyAZpJSFKgfo7+Y8msOKD8Ga4+NyAv0lttgfytrlhcTQ ZrHYPDY8L4Bw7Rbij2Ca0IaB4b40yeBvpvs3rp57HpZv5oNCZ+HO9q/eyur9xtpgCqXW mJDRBjdJfZ5+qtip+8i6HHYshiTyC9zl2XWyb9enWlCEsK8zT2eUDVCSmFuSbzBGZOhD kOJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=heqxE70v; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id g17si19250944pgl.758.2022.02.21.21.55.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Feb 2022 21:55:29 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=heqxE70v; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 538D5EBAF2; Mon, 21 Feb 2022 21:18:03 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1381430AbiBUQ4h (ORCPT + 99 others); Mon, 21 Feb 2022 11:56:37 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:43574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236717AbiBUQ4c (ORCPT ); Mon, 21 Feb 2022 11:56:32 -0500 Received: from so254-9.mailgun.net (so254-9.mailgun.net [198.61.254.9]) by lindbergh.monkeyblade.net (Postfix) with UTF8SMTPS id 7F25D22536 for ; Mon, 21 Feb 2022 08:56:08 -0800 (PST) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1645462568; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: From: References: Cc: To: Subject: MIME-Version: Date: Message-ID: Sender; bh=DzZH06prTIghA5OnLx3lGCwq5J4ljZ83zScuiDwYEFA=; b=heqxE70vkLmcGXR19iDdjz5Cjx2KHZsz1xQVY20etOVnKj9bg3sQB94RFGSS78AF/HveP8EG ijHF+Dq1ANwJu0Fpr+iU7optawgxR+rAWf4tmpVFbnVOxWmczGFiHyqMmWLuPno5h6mQpAoW /O/qfTuOMclawUPfRyt5GV6vAP0= X-Mailgun-Sending-Ip: 198.61.254.9 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n07.prod.us-east-1.postgun.com with SMTP id 6213c4273047cf1c0ae46711 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 21 Feb 2022 16:56:07 GMT Sender: tdas=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 1F121C43618; Mon, 21 Feb 2022 16:56:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 Received: from [192.168.0.101] (unknown [49.204.183.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: tdas) by smtp.codeaurora.org (Postfix) with ESMTPSA id 6DC46C4338F; Mon, 21 Feb 2022 16:56:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.codeaurora.org 6DC46C4338F Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=codeaurora.org Message-ID: <9f343332-9a0e-cbf9-9fb1-17127036b0b6@codeaurora.org> Date: Mon, 21 Feb 2022 22:25:58 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [v1 1/2] clk: qcom: gdsc: Use the default transition delay for GDSCs Content-Language: en-US To: Stephen Boyd , Bjorn Andersson Cc: Michael Turquette , Rajendra Nayak , linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220209172513.17873-1-tdas@codeaurora.org> <20220210072842.3E796C004E1@smtp.kernel.org> From: Taniya Das In-Reply-To: <20220210072842.3E796C004E1@smtp.kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Stephen, Bjorn, Thanks for your comments. On 2/10/2022 12:58 PM, Stephen Boyd wrote: > Quoting Bjorn Andersson (2022-02-09 14:35:08) >> On Wed 09 Feb 11:25 CST 2022, Taniya Das wrote: >> >>> Do not update the transition delay and use the default reset values. >>> >>> Fixes: 45dd0e55317cc ("clk: qcom: Add support for GDSCs) >>> Signed-off-by: Taniya Das >>> --- >>> drivers/clk/qcom/gdsc.c | 6 +++++- >>> drivers/clk/qcom/gdsc.h | 1 + >>> 2 files changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c >>> index 7e1dd8ccfa38..e7b213450640 100644 >>> --- a/drivers/clk/qcom/gdsc.c >>> +++ b/drivers/clk/qcom/gdsc.c >>> @@ -380,7 +380,11 @@ static int gdsc_init(struct gdsc *sc) >>> */ >>> mask = HW_CONTROL_MASK | SW_OVERRIDE_MASK | >>> EN_REST_WAIT_MASK | EN_FEW_WAIT_MASK | CLK_DIS_WAIT_MASK; >>> - val = EN_REST_WAIT_VAL | EN_FEW_WAIT_VAL | CLK_DIS_WAIT_VAL; >>> + >>> + regmap_read(sc->regmap, sc->gdscr, &val); >>> + >>> + if (!(sc->flags & DEFAULT_TRANSITION_DELAY)) >> >> I dug a little bit more into this and noticed that on various platforms >> CLK_DIS_WAIT_VAL for the GPU_CX GDSC is supposed to be 8 (whereas both >> hw default and CLK_DIS_WAIT_VAL is 2). >> Yes, only for certain GPU_CC these would be updated and that too in case the design team suggests. Downstream we would set the value from probe itself, or we can pick these from device tree as required and suggested. >> I'm not able to find anything helpful in the git log describing what the >> value does, but it seems that a "just use hw default" flag won't cut it >> for this scenario. >> This value is used for the number of clock cycles it would wait before the GDSCR ACK signals/halting the clock. > > I'd prefer we invert the logic so that we don't need to litter this flag > all over the place. I recall that the wait values were incorrect a long > time ago on early gdsc using designs but hopefully they've been fixed > now and we can simply use the default power on reset (POR) values. I am okay to invert the logic, but I am not sure if they could cause any issues to the older targets. They were broken in HW design long back, but got fixed in most families of target and most GDSCs. As mentioned if explicitly they need to be updated, it is best to do from the probe. This was done in SC7180 GPUCC driver. /* Configure clk_dis_wait for gpu_cx_gdsc */ regmap_update_bits(regmap, 0x106c, CLK_DIS_WAIT_MASK, 8 << CLK_DIS_WAIT_SHIFT); Please let me know if we are okay to add the invert logic. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. --