Received: by 10.192.165.148 with SMTP id m20csp622748imm; Fri, 4 May 2018 03:46:22 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoFaAX68hF2YYoub+PZ9JBFHSuuwxkWJP5LxVoE6YUR3PWHG/Sg3n3+Y9cOhNIOizAvMEP7 X-Received: by 10.98.75.139 with SMTP id d11mr26539161pfj.244.1525430782828; Fri, 04 May 2018 03:46:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525430782; cv=none; d=google.com; s=arc-20160816; b=evkgv3gYB+H9FiPbImucLbEhBMbQByjz0LZmlQnRe/ELefMg+W00XkY/XAAO01ubqw 3dvKsBwdT52AaTD0g0nWK7Rnk+fdueVpw85zeXIwFokwQ0QzvjACzlfuTVTY94aUUHqs UDwaJA7fuztN5P+ak4BhLWiXDE2k8ku6g63BFktfNjP/lraAb5QYEi9b45jNAFzxf8JR ukNAarfv/pQXGt8H4wYq1ouZCPPip7XXN1IzpRfrBJApUtNXS8QET1TRpF3AYlQVMOhW /LdAxJxiH0PEo5dB9/FDxHiFCj0PBBHT1dZHq9IZtd6DiEwxnyujQo+ufuMQexvkKFAM gCXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=SFJlJf3Z3VB7bJMNR9mf9G+vQeDX9enl+jFqLsUQKdw=; b=sXdruoG3gO9jbVNofEIs6rQtKZYC4uzpssXWyIQN910+qYHvorPDOUfiMRM12kAw6m LzG0ARGjbLbqgKKfKSH+gEExlRm1r71J6bOIadLom/LYD5Pvm+vUorVICaTuWdBy5uOG i/eEHAlRk+sQ16irttBRYbk/YhlflDp65yFdbXYzkI3siSSJXDTph/Uq9WiWYmwBqnIk T+/5vzmuL3m/2Ks9xsc72ZTFK8FZKcINQbwjiPZHTQEVwtmXa7qzCYB4kGHSSG8lhPj7 QFhanHKgI4GriOGAqmI0GIZlAI0DH9ZEh63sWb3J9dn0gP+WPmk8jv07Dld6RbJDLZMs nAcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=QYpQ40a4; dkim=pass header.i=@codeaurora.org header.s=default header.b=QYpQ40a4; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j1-v6si13447300pgs.24.2018.05.04.03.46.08; Fri, 04 May 2018 03:46:22 -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=@codeaurora.org header.s=default header.b=QYpQ40a4; dkim=pass header.i=@codeaurora.org header.s=default header.b=QYpQ40a4; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751342AbeEDKpQ (ORCPT + 99 others); Fri, 4 May 2018 06:45:16 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:59290 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750880AbeEDKpN (ORCPT ); Fri, 4 May 2018 06:45:13 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id AFF83607E5; Fri, 4 May 2018 10:45:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525430712; bh=A7ICWM04W8Q8NUnqHmM2yeh98SwfCxfqd8s7NCRED2Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QYpQ40a4HAOtQOwzJPa2J0K5RSn6G9cUfUH52tXN6qL9uugxwIBEtX4f2hRa+Dq1Z zzswDCTr/CiJRmU9i4uE3XD0BrdhiJaQctwwZGYyKlnjsxxNX++iGUmpCL/C3cDXlk C0cQYhUT+qG477jpT8vfDYUreHvZmUbBzICej+TY= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 40DD660591; Fri, 4 May 2018 10:45:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525430712; bh=A7ICWM04W8Q8NUnqHmM2yeh98SwfCxfqd8s7NCRED2Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QYpQ40a4HAOtQOwzJPa2J0K5RSn6G9cUfUH52tXN6qL9uugxwIBEtX4f2hRa+Dq1Z zzswDCTr/CiJRmU9i4uE3XD0BrdhiJaQctwwZGYyKlnjsxxNX++iGUmpCL/C3cDXlk C0cQYhUT+qG477jpT8vfDYUreHvZmUbBzICej+TY= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 04 May 2018 16:15:12 +0530 From: Amit Nischal To: Stephen Boyd Cc: Michael Turquette , Stephen Boyd , 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, devicetree@vger.kernel.org Subject: Re: [PATCH v6 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SDM845 In-Reply-To: <152524580953.138124.2159165461856101134@swboyd.mtv.corp.google.com> References: <1525105210-8689-1-git-send-email-anischal@codeaurora.org> <1525105210-8689-4-git-send-email-anischal@codeaurora.org> <152524580953.138124.2159165461856101134@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-05-02 12:53, Stephen Boyd wrote: > Quoting Amit Nischal (2018-04-30 09:20:10) >> --- >> .../devicetree/bindings/clock/qcom,gcc.txt | 1 + >> drivers/clk/qcom/Kconfig | 10 +- >> drivers/clk/qcom/Makefile | 1 + >> drivers/clk/qcom/gcc-sdm845.c | 3480 >> ++++++++++++++++++++ >> include/dt-bindings/clock/qcom,gcc-sdm845.h | 239 ++ > > Do the split that Rob suggests please, given that you're resending. And > also include his reviewed-by tag. Thanks for the review. Sure I will split the dt-binding into separate patch in next series. > >> 5 files changed, 3727 insertions(+), 4 deletions(-) >> create mode 100644 drivers/clk/qcom/gcc-sdm845.c >> create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h >> >> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig >> index e42e1af..3298beb 100644 >> --- a/drivers/clk/qcom/Kconfig >> +++ b/drivers/clk/qcom/Kconfig >> @@ -218,13 +218,15 @@ config MSM_MMCC_8996 >> Say Y if you want to support multimedia devices such as >> display, >> graphics, video encode/decode, camera, etc. >> >> -config MSM_GCC_8998 >> - tristate "MSM8998 Global Clock Controller" >> +config SDM_GCC_845 >> + tristate "SDM845 Global Clock Controller" >> + select QCOM_GDSC >> depends on COMMON_CLK_QCOM >> help >> - Support for the global clock controller on msm8998 devices. >> + Support for the global clock controller on Qualcomm >> Technologies, Inc >> + sdm845 devices. >> Say Y if you want to use peripheral devices such as UART, >> SPI, >> - i2c, USB, UFS, SD/eMMC, PCIe, etc. >> + I2C, USB, UFS, SDDC, PCIe, etc. > > This is all wrong. > My bad. I did by mistake. Will fix this in next series. >> >> config SPMI_PMIC_CLKDIV >> tristate "SPMI PMIC clkdiv Support" >> diff --git a/drivers/clk/qcom/gcc-sdm845.c >> b/drivers/clk/qcom/gcc-sdm845.c >> new file mode 100644 >> index 0000000..6484cba >> --- /dev/null >> +++ b/drivers/clk/qcom/gcc-sdm845.c >> @@ -0,0 +1,3480 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (c) 2018, The Linux Foundation. All rights reserved. >> + */ >> + > [...] >> + .name = "gcc_disp_axi_clk", >> + .ops = &clk_branch2_ops, >> + }, >> + }, >> +}; >> + >> +static struct clk_branch gcc_disp_gpll0_clk_src = { >> + .halt_reg = 0x52004, >> + .halt_check = BRANCH_HALT_DELAY, > > What about this one? It's not a phy so I'm confused again why we're > unable to check the halt bit. To be clear(er), I don't see why we ever > want to have HALT_DELAY used. Hopefully we can remove that flag. > > From what I recall, the flag is there for clks that don't toggle their > status bit at all, but that we know take a few cycles to ungate the > upstream clk. So we threw a delay into the code to make sure that when > clk_enable() returned, a driver wouldn't try to use hardware before the > clk was actually on. But these cases should pretty much never happen, > hence all the pushback against this flag. > For these "*gpll0_clk_src" and "*gpll0_div_clk" clocks, there is no halt bit to check the status and it is required to have delay for few cycles so that clock gets turned on before a client driver to use the hardware. >> + .clkr = { >> + .enable_reg = 0x52004, >> + .enable_mask = BIT(18), >> + .hw.init = &(struct clk_init_data){ >> + .name = "gcc_disp_gpll0_clk_src", >> + .parent_names = (const char *[]){ >> + "gpll0", >> + }, >> + .num_parents = 1, > [...] >> + .enable_reg = 0x7508c, >> + .enable_mask = BIT(0), >> + .hw.init = &(struct clk_init_data){ >> + .name = "gcc_ufs_card_phy_aux_clk", >> + .parent_names = (const char *[]){ >> + "gcc_ufs_card_phy_aux_clk_src", >> + }, >> + .num_parents = 1, >> + .flags = CLK_SET_RATE_PARENT, >> + .ops = &clk_branch2_ops, >> + }, >> + }, >> +}; >> + >> +static struct clk_branch gcc_ufs_card_rx_symbol_0_clk = { >> + .halt_reg = 0x75018, >> + .halt_check = BRANCH_HALT_DELAY, > > There are still HALT_DELAY flags for UFS though? Why? For ufs_card tx/rx symbol clocks, we don't poll the status bit as per the recommendation from the HW team. We can change the halt_check type to newly implemented flag "BRANCH_HALT_SKIP". Please update us with your thoughts to change the flag to "BRANCH_HALT_SKIP". > > Also, are you going to send DFS support for the QUP clks? I would like > to see that code merged soon. Taniya has sent the patches for DFS support for QUP clocks. https://patchwork.kernel.org/patch/10376951/