Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp470424imm; Tue, 24 Jul 2018 23:59:49 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdJaYD7WPbmdObmiABDSdU14BmJWvFgxYf5VmEXseZJDqpLxrrGHtC6hLfwwh+9Tan1Gnl3 X-Received: by 2002:a17:902:8d96:: with SMTP id v22-v6mr19667499plo.176.1532501989891; Tue, 24 Jul 2018 23:59:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532501989; cv=none; d=google.com; s=arc-20160816; b=saS2ppSPJuT35xxpT70AJwYyX9b7lXTN4bX0g7Et8gEO9DmDbDlzTaIi1PbuuNIXxi THESnZflE2IBiLOaE22talS6s2db6Oin0JqqOeMe0dPCP0qcpqhEAokoEmks3uZI/kU8 XvY2ScTxaT4qYX0WunjfNSV2CE5v3m+fKFrD8cb8wby37tugTAXWw2x+yQBX72O8hwu0 YjfoOPOjKnxd8QhbEbLT64RGNEUoUq1l+PRAG4VYYQa68AnY0I6C4o/zU/eayWv4lrWB r5rZYp7WVSH0bRDjYg3qTEtqTsH90YAh+RqrYAOjMFhiSlRX5tAUxl3cDSBc0hmIvI7f d6Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature:arc-authentication-results; bh=kshgAIlZ+9sxKNG54cPoGGzyvE758fC2amOvnvncC2o=; b=w56j/ugsDCi5oviPAvSPafRe6b5BAKKoAaypK5aWNDM9TjOqzDSbEUALDHfL9wUn1c MbjT9Jjz0kjpNSAHM9I0kquodsVk3e9JyJgY+kozgsQ5hMlNJVZP2kxhVxmW1OSrkL/P kKpB3Y6iXSFYNA+aCHLgk/XnCsgGBbFMt4EM2NeBPpMuEvtj9hvOaid8ZWryg7OSlsKm 9Rx8jvffCzVPqRSj/rljj4L2fFurPuoaTDBJkM67p4YPBXsFliqhwqHEnJc2uJtS0LQq kajF2zA5amOWWkZpxHHhWiQeI/06Mn4XNdVKxmlKnfWs5nHp3cD8e1lDuGwiw3617j+1 JqAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=y1jN7+ja; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h7-v6si13317566plt.258.2018.07.24.23.59.33; Tue, 24 Jul 2018 23:59:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=y1jN7+ja; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728553AbeGYIJA (ORCPT + 99 others); Wed, 25 Jul 2018 04:09:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:42094 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728222AbeGYII7 (ORCPT ); Wed, 25 Jul 2018 04:08:59 -0400 Received: from localhost (unknown [104.132.1.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3242920852; Wed, 25 Jul 2018 06:58:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1532501923; bh=kshgAIlZ+9sxKNG54cPoGGzyvE758fC2amOvnvncC2o=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=y1jN7+jaI56cDWQMSvD5aVYUeYBkJ+dV9vzrg9HlDpWCiAakY5IXpHwYohFARhsGG jn30aBaqySWlD9GJNLcgWqrab4pnLk6WWicM1ER6PacY7cdMrB1PBs/QT0DIJnCbH3 rixX0GYqW0vVo1uiMXeAuZ8Jx63PVsIPcqwYfPBY= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Amit Nischal From: Stephen Boyd In-Reply-To: <1e6d9fc284c3c118203728867f504ec6@codeaurora.org> 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 References: <1528285308-25477-1-git-send-email-anischal@codeaurora.org> <1528285308-25477-3-git-send-email-anischal@codeaurora.org> <153111693472.143105.11303543263643845656@swboyd.mtv.corp.google.com> <1e6d9fc284c3c118203728867f504ec6@codeaurora.org> Message-ID: <153250192252.48062.9210075387954345932@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: [PATCH 2/4] clk: qcom: Add clk_rcg2_gfx3d_ops for SDM845 Date: Tue, 24 Jul 2018 23:58:42 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Amit Nischal (2018-07-12 05:30:21) > On 2018-07-09 11:45, Stephen Boyd wrote: > > Quoting Amit Nischal (2018-06-06 04:41:46) > >> To turn on the gpu_gx_gdsc, there is a hardware requirement to > >> turn on the root clock (GFX3D RCG) first which would be the turn > >> on signal for the gdsc along with the SW_COLLAPSE. As per the > >> current implementation of clk_rcg2_shared_ops, it clears the > >> root_enable bit in the enable() and set_rate() clock ops. But due > >> to the above said requirement for GFX3D shared RCG, root_enable bit > >> would be already set by gdsc driver and rcg2_shared_ops should not = > >> clear > >> the root unless the disable is called. > >> = > > = > > It sounds like the GDSC enable is ANDed with the RCG's root enable > > bit? > = > Here, the root clock (GFX3D RCG) needs to be enabled first before > writing to SW_COLLAPSE bit of the GDSC. RCG's CLK_ON signal would > power up the GDSC. > = > > Does the RCG need to be clocking for the GDSC to actually turn on? > > Or is it purely that the enable bit is logically combined that way so > > that if the RCG is parented to a PLL that's off the GDSC will still = > > turn > > on? > > = > = > Yes, the RCG needs to be clocking for the GPU_GX GDSC to actually turn = > on. Cool, please add these details to the commit text. > = > >> Add support for the same by reusing the existing clk_rcg2_shared_ops > >> and deriving "clk_rcg2_gfx3d_ops" clk_ops for GFX3D clock to > >> take care of the root set/clear requirement. > > = > > Anyway, this patch will probably significantly change given that the = > > RCG > > is a glorified div-2 that muxes between a safe CXO speed and a > > configurable PLL frequency. A lot of the logic can probably just be > > hardcoded then. > > = > = > Thanks for the suggestion. > We are planning to introduce the "clk_rcg2_gfx3d_determine_rate" op = > which will > always return the best parent as =E2=80=98GPU_CC_PLL0_OUT_EVEN=E2=80=99 a= nd best_parent > rate equal to twice of the requested rate. With this approach frequency = > table > for rcg2 structure would not be required as all the supported = > frequencies would > be derived from the GPU_CC_PLL0_OUT_EVEN src with a divider of 2. > = > Also, we will add support to check the requested rate if falls within = > allowed > set_rate range. This will make sure that the source PLL would not go out = > of > the supported range. set_rate_range would be set by the GPUCC driver = > with min/max > value by calling below API. > = > clk_hw_set_rate_range(&gpu_cc_gx_gfx3d_clk_src.clkr.hw, 180000000, = > 710000000) Ok. Sounds good! Is the rate range call really needed? It can't be determined in the PLL code with some table or avoided by making sure GPU uses OPP table with only approved frequencies?