From: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
Andy Gross <agross@kernel.org>,
David Brown <david.brown@linaro.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Marc Gonzalez <marc.w.gonzalez@free.fr>,
Jordan Crouse <jcrouse@codeaurora.org>,
MSM <linux-arm-msm@vger.kernel.org>,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] clk: qcom: Add MSM8998 GPU Clock Controller (GPUCC) driver
Date: Fri, 7 Jun 2019 08:08:46 -0600 [thread overview]
Message-ID: <CAOCk7NqYptsLkYyfUCSvh0J0FZd_9gPDZJoyjB5Ng4v8aLFUNw@mail.gmail.com> (raw)
In-Reply-To: <20190606230050.2F33720645@mail.kernel.org>
On Thu, Jun 6, 2019 at 5:00 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Jeffrey Hugo (2019-05-28 09:48:03)
> > diff --git a/drivers/clk/qcom/gpucc-msm8998.c b/drivers/clk/qcom/gpucc-msm8998.c
> > new file mode 100644
> > index 000000000000..e45062e40718
> > --- /dev/null
> > +++ b/drivers/clk/qcom/gpucc-msm8998.c
> > +
> > +static int gpucc_msm8998_probe(struct platform_device *pdev)
> > +{
> > + struct regmap *regmap;
> > + struct clk *xo;
> > +
> > + /*
> > + * We must have a valid XO to continue until orphan probe defer is
> > + * implemented.
> > + */
> > + xo = clk_get(&pdev->dev, "xo");
>
> Why is this necessary?
As you well know, XO is the root clock for pretty much everything on
Qualcomm platforms. We are trying to do things "properly" on 8998.
We are planning on having rpmcc manage it (see my other series), and
all the other components consume xo from there. Unfortunately we
cannot control the probe order, particularly when things are built as
modules, so its possible gpucc might be the first thing to probe.
Currently, the clock framework will allow that since everything in
gpucc will just be an orphan. However that doesn't prevent gpucc
consumers from grabbing their clocks, and we've seen that cause
issues.
As you've previously explained, you have a ton of work to do to
refactor things so that a clock will probe defer if its dependencies
are not present. We'd prefer that functionality, but are not really
willing to wait for it. Thus, we are implementing the same
functionality in the driver until the framework handles it for us, at
which point we'll gladly rip this out.
>
> > + if (IS_ERR(xo))
> > + return PTR_ERR(xo);
> > + clk_put(xo);
> > +
> > + regmap = qcom_cc_map(pdev, &gpucc_msm8998_desc);
> > + if (IS_ERR(regmap))
> > + return PTR_ERR(regmap);
> > +
> > + /* force periph logic on to acoid perf counter corruption */
>
> avoid?
Yes. Do you want a v3 with this fixed?
>
> > + regmap_write_bits(regmap, gfx3d_clk.clkr.enable_reg, BIT(13), BIT(13));
> > + /* tweak droop detector (GPUCC_GPU_DD_WRAP_CTRL) to reduce leakage */
> > + regmap_write_bits(regmap, gfx3d_clk.clkr.enable_reg, BIT(0), BIT(0));
> > +
> > + return qcom_cc_really_probe(pdev, &gpucc_msm8998_desc, regmap);
> > +}
> > +
next prev parent reply other threads:[~2019-06-07 14:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-28 16:46 [PATCH 0/3] MSM8998 GPUCC Support Jeffrey Hugo
2019-05-28 16:47 ` [PATCH 1/3] dt-bindings: clock: Document gpucc for msm8998 Jeffrey Hugo
2019-06-06 23:27 ` Stephen Boyd
2019-05-28 16:48 ` [PATCH 2/3] clk: qcom: Add MSM8998 GPU Clock Controller (GPUCC) driver Jeffrey Hugo
2019-05-29 9:46 ` Marc Gonzalez
2019-05-29 14:00 ` Jeffrey Hugo
2019-06-06 23:00 ` Stephen Boyd
2019-06-07 14:08 ` Jeffrey Hugo [this message]
2019-06-07 20:32 ` Stephen Boyd
2019-06-07 21:34 ` Jeffrey Hugo
2019-05-28 16:48 ` [PATCH 3/3] arm64: dts: qcom: msm8998: Add gpucc node Jeffrey Hugo
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=CAOCk7NqYptsLkYyfUCSvh0J0FZd_9gPDZJoyjB5Ng4v8aLFUNw@mail.gmail.com \
--to=jeffrey.l.hugo@gmail.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jcrouse@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.w.gonzalez@free.fr \
--cc=mark.rutland@arm.com \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.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).