From: Stephen Boyd <sboyd@kernel.org>
To: Rob Clark <robdclark@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>,
Taniya Das <tdas@codeaurora.org>,
Michael Turquette <mturquette@baylibre.com>,
David Brown <david.brown@linaro.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
linux-soc@vger.kernel.org, linux-clk@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
devicetree@vger.kernel.org, robh@kernel.org,
Rob Herring <robh+dt@kernel.org>,
Jordan Crouse <jcrouse@codeaurora.org>,
Jeykumar Sankaran <jsanka@codeaurora.org>,
Sean Paul <seanpaul@chromium.org>
Subject: Re: [PATCH v4 5/5] clk: qcom: Add Global Clock controller (GCC) driver for SC7180
Date: Fri, 08 Nov 2019 13:14:09 -0800 [thread overview]
Message-ID: <20191108211410.0411720869@mail.kernel.org> (raw)
In-Reply-To: <CAJs_Fx6KCirGMtQxE=xA-A=bd5LeuYWviee0+KqO5OtGT9GKEw@mail.gmail.com>
Quoting Rob Clark (2019-11-08 11:40:53)
> On Fri, Nov 8, 2019 at 10:42 AM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > So the scenario is DT describes the clk
> >
> > dpu_node {
> > clocks = <&cc AHB_CLK>;
> > clock-names = "iface";
> > }
> >
> > but the &cc node has a driver that doesn't probe?
> >
> > I believe in this scenario we return -EPROBE_DEFER because we assume we
> > should wait for the clk driver to probe and provide the iface clk. See
> > of_clk_get_hw_from_clkspec() and how it looks through a list of clk
> > providers and tries to match the &cc phandle to some provider.
> >
> > Once the driver probes, the match will happen and we'll be able to look
> > up the clk in the provider with __of_clk_get_hw_from_provider(). If
> > the clk provider decides that there isn't a clk object, it will return
> > NULL and then eventually clk_hw_create_clk() will turn the NULL return
> > value into a NULL pointer to return from clk_get().
> >
>
> ok, that was the scenario I was worried about (since unclk'd register
> access tends to be insta-reboot and hard to debug).. so I think it
> should be ok to make dpu just ignore NULL clks.
>
> From a quick look, I think something like the attached (untested).
> (Sorry, I'd just paste it inline but gmail somehow eats all the
> whitespace when I do that :-/)
Cool. Looks good to me.
next prev parent reply other threads:[~2019-11-08 21:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-14 10:23 [PATCH v4 0/5] Add Global Clock controller (GCC) driver for SC7180 Taniya Das
2019-10-14 10:23 ` [PATCH v4 1/5] clk: qcom: rcg: update the DFS macro for RCG Taniya Das
2019-11-07 21:11 ` Stephen Boyd
2019-10-14 10:23 ` [PATCH v4 2/5] clk: qcom: common: Return NULL from clk_hw OF provider Taniya Das
2019-11-07 21:11 ` Stephen Boyd
2019-10-14 10:23 ` [PATCH v4 3/5] dt-bindings: clock: Add YAML schemas for the QCOM GCC clock bindings Taniya Das
2019-10-14 16:49 ` Rob Herring
2019-11-07 21:11 ` Stephen Boyd
2019-10-14 10:23 ` [PATCH v4 4/5] dt-bindings: clock: Introduce " Taniya Das
2019-10-14 16:50 ` Rob Herring
2019-11-07 21:11 ` Stephen Boyd
2019-10-14 10:23 ` [PATCH v4 5/5] clk: qcom: Add Global Clock controller (GCC) driver for SC7180 Taniya Das
2019-10-29 17:59 ` Matthias Kaehlcke
2019-10-31 11:29 ` Taniya Das
2019-10-31 17:41 ` Matthias Kaehlcke
2019-11-07 21:06 ` Stephen Boyd
2019-11-08 2:06 ` Rob Clark
2019-11-08 6:35 ` Stephen Boyd
2019-11-08 16:54 ` Rob Clark
2019-11-08 18:42 ` Stephen Boyd
2019-11-08 19:40 ` Rob Clark
2019-11-08 21:14 ` Stephen Boyd [this message]
2019-11-14 1:02 ` Matthias Kaehlcke
2019-11-14 5:30 ` Rob Clark
2019-11-14 17:04 ` Matthias Kaehlcke
2019-11-07 21:12 ` Stephen Boyd
2019-11-14 17:34 ` Matthias Kaehlcke
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=20191108211410.0411720869@mail.kernel.org \
--to=sboyd@kernel.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jcrouse@codeaurora.org \
--cc=jsanka@codeaurora.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=mka@chromium.org \
--cc=mturquette@baylibre.com \
--cc=rnayak@codeaurora.org \
--cc=robdclark@chromium.org \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=seanpaul@chromium.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).