linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Michael Turquette <mturquette@baylibre.com>,
	Taniya Das <tdas@codeaurora.org>,
	robh+dt@kernel.org
Cc: David Brown <david.brown@linaro.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	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 v3 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SC7180
Date: Tue, 24 Sep 2019 16:12:22 -0700	[thread overview]
Message-ID: <20190924231223.9012C207FD@mail.kernel.org> (raw)
In-Reply-To: <a3cd82c9-8bfa-f4a3-ab1f-2e397fbd9d16@codeaurora.org>

Quoting Taniya Das (2019-09-23 01:01:11)
> Hi Stephen,
> 
> Thanks for your comments.
> 
> On 9/19/2019 3:09 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2019-09-18 02:50:18)
> >> diff --git a/drivers/clk/qcom/gcc-sc7180.c b/drivers/clk/qcom/gcc-sc7180.c
> >> new file mode 100644
> >> index 000000000000..d47865d5408f
> >> --- /dev/null
> >> +++ b/drivers/clk/qcom/gcc-sc7180.c
> >> @@ -0,0 +1,2515 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> >> + */
> >> +
> >> +#include <linux/err.h>
> >> +#include <linux/kernel.h>
> >> +#include <linux/module.h>
> >> +#include <linux/of.h>
> >> +#include <linux/of_device.h>
> >> +#include <linux/regmap.h>
> > 
> > include clk-provider.h
> > 
> 
> will add this header.
> Currently the <drivers/clk/qcom/clk-regmap.h> already includes it.

Yes but it should be included in any clk-provider drivers too.

> >> +
> >> +/* Leave the clock ON for parent config_noc_clk to be kept enabled */
> >> +static struct clk_branch gcc_disp_ahb_clk = {
> >> +       .halt_reg = 0xb00c,
> >> +       .halt_check = BRANCH_HALT,
> >> +       .hwcg_reg = 0xb00c,
> >> +       .hwcg_bit = 1,
> >> +       .clkr = {
> >> +               .enable_reg = 0xb00c,
> >> +               .enable_mask = BIT(0),
> >> +               .hw.init = &(struct clk_init_data){
> >> +                       .name = "gcc_disp_ahb_clk",
> >> +                       .flags = CLK_IS_CRITICAL,
> > 
> > Does this assume the display is left enabled out of the bootloader? Why
> > is this critical to system operation? Maybe it is really
> > CLK_IGNORE_UNUSED?
> > 
> 
> This clock is not kept enabled by bootloader. But leaving this ON for 
> clients on config noc.

Please see below comment for the other critical clk with no parent.

> 
> >> +                       .ops = &clk_branch2_ops,
> >> +               },
> >> +       },
> >> +};
> >> +
[...]
> >> +static struct clk_branch gcc_ufs_phy_phy_aux_clk = {
> >> +       .halt_reg = 0x77094,
> >> +       .halt_check = BRANCH_HALT,
> >> +       .hwcg_reg = 0x77094,
> >> +       .hwcg_bit = 1,
> >> +       .clkr = {
> >> +               .enable_reg = 0x77094,
> >> +               .enable_mask = BIT(0),
> >> +               .hw.init = &(struct clk_init_data){
> >> +                       .name = "gcc_ufs_phy_phy_aux_clk",
> >> +                       .parent_data = &(const struct clk_parent_data){
> >> +                               .hw = &gcc_ufs_phy_phy_aux_clk_src.clkr.hw,
> >> +                       },
> >> +                       .num_parents = 1,
> >> +                       .flags = CLK_SET_RATE_PARENT,
> >> +                       .ops = &clk_branch2_ops,
> >> +               },
> >> +       },
> >> +};
> >> +
> >> +static struct clk_branch gcc_ufs_phy_rx_symbol_0_clk = {
> >> +       .halt_reg = 0x7701c,
> >> +       .halt_check = BRANCH_HALT_SKIP,
> > 
> > Again, nobody has fixed the UFS driver to not need to do this halt skip
> > check for these clks? It's been over a year.
> > 
> 
> The UFS_PHY_RX/TX clocks could be left enabled due to certain HW boot 
> configuration and thus during the late initcall of clk_disable there 
> could be warnings of "clock stuck ON" in the dmesg. That is the reason 
> also to use the BRANCH_HALT_SKIP flag.

Oh that's bad. Why do the clks stay on when we try to turn them off?

> 
> I would also check internally for the UFS driver fix you are referring here.

Sure. I keep asking but nothing is done :(

> 
> >> +       .clkr = {
> >> +               .enable_reg = 0x7701c,
> >> +               .enable_mask = BIT(0),
> >> +               .hw.init = &(struct clk_init_data){
> >> +                       .name = "gcc_ufs_phy_rx_symbol_0_clk",
> >> +                       .ops = &clk_branch2_ops,
> >> +               },
> >> +       },
> >> +};
> >> +
[...]
> >> +
> >> +static struct clk_branch gcc_usb3_prim_phy_pipe_clk = {
> >> +       .halt_reg = 0xf058,
> >> +       .halt_check = BRANCH_HALT_SKIP,
> > 
> > Why does this need halt_skip?
> 
> This is required as the source is external PHY, so we want to not check 
> for HALT.

This doesn't really answer my question. If the source is an external phy
then it should be listed as a clock in the DT binding and the parent
should be specified here. Unless something doesn't work because of that?

> 
> > 
> >> +       .clkr = {
> >> +               .enable_reg = 0xf058,
> >> +               .enable_mask = BIT(0),
> >> +               .hw.init = &(struct clk_init_data){
> >> +                       .name = "gcc_usb3_prim_phy_pipe_clk",
> >> +                       .ops = &clk_branch2_ops,
> >> +               },
> >> +       },
> >> +};
> >> +
> >> +static struct clk_branch gcc_usb_phy_cfg_ahb2phy_clk = {
> >> +       .halt_reg = 0x6a004,
> >> +       .halt_check = BRANCH_HALT,
> >> +       .hwcg_reg = 0x6a004,
> >> +       .hwcg_bit = 1,
> >> +       .clkr = {
> >> +               .enable_reg = 0x6a004,
> >> +               .enable_mask = BIT(0),
> >> +               .hw.init = &(struct clk_init_data){
> >> +                       .name = "gcc_usb_phy_cfg_ahb2phy_clk",
> >> +                       .ops = &clk_branch2_ops,
> >> +               },
> >> +       },
> >> +};
> >> +
> >> +/* Leave the clock ON for parent config_noc_clk to be kept enabled */
> > 
> > There's no parent though... So I guess this means it keeps it enabled
> > implicitly in hardware?
> > 
> 
> These are not left enabled, but want to leave them enabled for clients 
> on config NOC.

Sure. It just doesn't make sense to create clk structures and expose
them in the kernel when we just want to turn the bits on and leave them
on forever. Why not just do some register writes in probe for this
driver? Doesn't that work just as well and use less memory?


  reply	other threads:[~2019-09-24 23:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-18  9:50 [PATCH v3 0/3] Add Global Clock controller (GCC) driver for SC7180 Taniya Das
2019-09-18  9:50 ` [PATCH v3 1/3] clk: qcom: rcg: update the DFS macro for RCG Taniya Das
2019-09-18  9:50 ` [PATCH v3 2/3] dt-bindings: clk: qcom: Add YAML schemas for the GCC clock bindings Taniya Das
2019-09-18 17:52   ` Matthias Kaehlcke
2019-09-23  6:33     ` Taniya Das
2019-09-27 17:27   ` Rob Herring
2019-10-14 10:16     ` Taniya Das
     [not found]   ` <20190918212614.448FC20882@mail.kernel.org>
2019-10-14 10:17     ` Taniya Das
2019-09-18  9:50 ` [PATCH v3 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SC7180 Taniya Das
2019-09-19 11:08   ` Rajendra Nayak
2019-09-20  4:00     ` Taniya Das
2019-09-20  4:44       ` Rajendra Nayak
     [not found]   ` <20190918213946.DC03521924@mail.kernel.org>
2019-09-23  8:01     ` Taniya Das
2019-09-24 23:12       ` Stephen Boyd [this message]
2019-09-25 11:20         ` Taniya Das
2019-09-25 13:03           ` Stephen Boyd
2019-09-27  7:37             ` Taniya Das
2019-10-01 14:38               ` Stephen Boyd
2019-10-03 10:31                 ` Taniya Das
2019-10-03 16:01                   ` Stephen Boyd
2019-10-04 17:39                     ` Taniya Das
2019-10-04 23:20                       ` Stephen Boyd
2019-10-09  9:19                         ` Taniya Das
2019-10-10  4:16                           ` Stephen Boyd
2019-10-11 10:28                             ` Taniya Das

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190924231223.9012C207FD@mail.kernel.org \
    --to=sboyd@kernel.org \
    --cc=david.brown@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rnayak@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=tdas@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).