From: Stephen Boyd <sboyd@codeaurora.org>
To: Sricharan R <sricharan@codeaurora.org>
Cc: mturquette@baylibre.com, linux-clk@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
rnayak@codeaurora.org, stanimir.varbanov@linaro.org
Subject: Re: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control
Date: Tue, 1 Nov 2016 17:18:34 -0700 [thread overview]
Message-ID: <20161102001834.GB16026@codeaurora.org> (raw)
In-Reply-To: <1477304297-5248-2-git-send-email-sricharan@codeaurora.org>
On 10/24, Sricharan R wrote:
> @@ -164,6 +171,10 @@ static int gdsc_enable(struct generic_pm_domain *domain)
> */
> udelay(1);
>
> + /* Turn on HW trigger mode if supported */
> + if (sc->flags & HW_CTRL)
> + gdsc_hwctrl(sc, true);
> +
It sounds like this will cause glitches if the hardware isn't
asserting their hw control bit by default? This has me concerned
that we can't just throw the hw control enable part into here,
because that bit doesn't live in the clock controller, instead it
lives in the hw block that is powered by the power domain?
Or does the power on reset value of that hw control signal
asserted? If that's true then we should be ok to force it into hw
control mode by default.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2016-11-02 0:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-24 10:18 [PATCH 0/3] clk: qcom: Add support for hw controlled gdscs/clocks Sricharan R
2016-10-24 10:18 ` [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control Sricharan R
2016-10-25 13:01 ` Stanimir Varbanov
2016-10-26 4:12 ` Sricharan
2016-11-02 0:18 ` Stephen Boyd [this message]
2016-11-02 6:50 ` Sricharan
2016-11-02 6:53 ` Sricharan
2016-11-02 17:59 ` 'Stephen Boyd'
2016-11-03 13:30 ` Sricharan
2016-11-03 20:05 ` 'Stephen Boyd'
2016-10-24 10:18 ` [PATCH 2/3] clk: qcom: Put venus core0/1 gdscs to hw control mode Sricharan R
2016-10-24 10:18 ` [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks Sricharan R
2016-11-03 20:34 ` Stephen Boyd
2016-11-04 9:09 ` Sricharan
2016-11-04 20:18 ` 'Stephen Boyd'
2016-11-07 5:48 ` Rajendra Nayak
2016-11-08 22:33 ` 'Stephen Boyd'
2016-11-09 16:56 ` Sricharan
2016-11-10 2:32 ` Rajendra Nayak
2016-11-10 3:28 ` Sricharan
2016-11-10 23:30 ` 'Stephen Boyd'
2016-11-14 3:51 ` Sricharan
2016-12-12 15:40 ` Stanimir Varbanov
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=20161102001834.GB16026@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=rnayak@codeaurora.org \
--cc=sricharan@codeaurora.org \
--cc=stanimir.varbanov@linaro.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).