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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E94F213F6DFF for ; Mon, 30 Jul 2018 11:14:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B10320893 for ; Mon, 30 Jul 2018 11:14:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="jhD09biD"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="hL/LMdgk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B10320893 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727597AbeG3Msn (ORCPT ); Mon, 30 Jul 2018 08:48:43 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:53768 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726549AbeG3Msm (ORCPT ); Mon, 30 Jul 2018 08:48:42 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 4250B61AC8; Mon, 30 Jul 2018 11:14:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1532949253; bh=7fvkKEDmV7n/xa3fvuFW/WXRnKkcTlGNzQOLQ1uow3w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jhD09biDaLIOFmF/SB9bK1nmz2KgmILhANZIdIhVWUuNiBbpbPb78k63GEfGxIXtO SA/GCSRBT0tKwjA43S40mcOpsQqDiS1RU7aeYIq0UbqFkvBTVFM3nfSQOk1QEyMC+Q Qhh1UEomrQlPRPtKRiRIWrk61vjjZk0cNAcFKOl0= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id A7A1F60117; Mon, 30 Jul 2018 11:14:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1532949252; bh=7fvkKEDmV7n/xa3fvuFW/WXRnKkcTlGNzQOLQ1uow3w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hL/LMdgkNo2Nmg5p3MY19ap1yrtfIpKhUQArKCGWN42QHkjBVDkwSON752/nhwYmu NuaJrAd4v0cH8+YkwkQ4V8/69jsdU4l7UeYxufA3HrqKrPmYKK4gW+Ol7hWJgK7NHf ReP94rXO4fglClzT0+2F396XZpmwJi9qxtVyoTlU= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 30 Jul 2018 16:44:12 +0530 From: Amit Nischal To: Stephen Boyd Cc: Michael Turquette , Andy Gross , David Brown , Rajendra Nayak , Odelu Kukatla , Taniya Das , linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-clk-owner@vger.kernel.org Subject: Re: [PATCH 1/4] clk: qcom: gdsc: Add support to enable/disable the clocks with GDSC In-Reply-To: <153250153971.48062.18053635476867512394@swboyd.mtv.corp.google.com> References: <1528285308-25477-1-git-send-email-anischal@codeaurora.org> <1528285308-25477-2-git-send-email-anischal@codeaurora.org> <153111447519.143105.17241493270191899078@swboyd.mtv.corp.google.com> <6e53b7934af72e40e99a3d6afe54174f@codeaurora.org> <153250153971.48062.18053635476867512394@swboyd.mtv.corp.google.com> Message-ID: X-Sender: anischal@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-07-25 12:22, Stephen Boyd wrote: > Quoting Amit Nischal (2018-07-12 05:23:48) >> On 2018-07-09 11:04, Stephen Boyd wrote: >> > Quoting Amit Nischal (2018-06-06 04:41:45) >> >> For some of the GDSCs, there is a requirement to enable/disable the >> >> few clocks before turning on/off the gdsc power domain. Add support >> > >> > Why is there a requirement? Do the clks need to be in hw control mode >> > or >> > they can't be turned off when the GDSC is off? It's hard for me to >> > understand with these vague statements. >> > >> >> This requirement is primarily to turn on the GPU GX GDSC and these >> clocks >> do not need to be in HW control mode and clock disable is not related >> with the GDSC. > > Ok that's good to know. > >> >> To turn on the GX GDSC, root clock (GFX3D RCG) needs to be enabled >> first >> before writing to SW_COLLAPSE bit of the GDSC. The CLK_ON signal from >> RCG >> would power up the GPU GX GDSC. > > Can you please put this specific information in the commit text instead > of making a vague statement about GDSC hardware configurations? > > Does anything go wrong if the GDSC is enabled from genpd but doesn't > actually turn on until the GFX3D RCG root bit is enabled or disabled by > the clk enable call? I suppose we won't know if the GDSC is enabled or > not until the clk is enabled? Maybe we should make the clk enable of > the > RCG for GPU go check the GDSC status bit as well to make sure it's > toggling on or off? As per the current design, before turning on the GDSC(writing to the GDSCR register) we are setting the ROOT_EN bit of RCG and GDSC's status will be still off without clk_enable call to RCG even though we enable the GDSC. clk_enable for RCG is CLK_ON signal for the GPU_GX_GDSC. > > Also, does the RCG turn on when the GX GDSC is off? I think we may be > able to rely on the GPU driver to "do the right thing" and enable the > GPU CX GDSC first, then the RCG and branch for the GFX3D clk, and then > the GPU GX GDSC for the core GPU logic. Then we don't need to do > anything special in the GDSC code for this. Its a GPU_GX_GDSC requirement to enable the RCG first and then GX_GDSC. We want all of this sequence to be done by the GDSC driver so that client only call for clk_apis for the clock branch. For clients, It will be extra overhead to follow the below sequence. GPU_CX_GDSC enable -> Enable RCG -> Enable GPU_GX_GDSC -> Enable Branch.