All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sricharan" <sricharan@codeaurora.org>
To: 'Stephen Boyd' <sboyd@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: Wed, 2 Nov 2016 12:23:43 +0530	[thread overview]
Message-ID: <003e01d234d5$dd3aeab0$97b0c010$@codeaurora.org> (raw)
In-Reply-To: <003c01d234d5$731b19c0$59514d40$@codeaurora.org>

Hi,

>-----Original Message-----
>From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-owner@vger.kernel.org] On Behalf Of Sricharan
>Sent: Wednesday, November 02, 2016 12:21 PM
>To: 'Stephen Boyd' <sboyd@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
>
>Hi Stephen,
>
>>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.
>>
>
>The hw control bit is set by default. Instead its turned 'off'
>with the reset value. So it has to not
>be turned 'on' at some point
>to put the gdsc in hw control if required. This bit is part of the
>gdscr register. So i did not quite understand the reason for the
>glitch here ?
>

typo above, i meant it has to be turned 'on' at some point
if required.

Regards,
 Sricharan



WARNING: multiple messages have this Message-ID (diff)
From: "Sricharan" <sricharan@codeaurora.org>
To: "'Stephen Boyd'" <sboyd@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: Wed, 2 Nov 2016 12:23:43 +0530	[thread overview]
Message-ID: <003e01d234d5$dd3aeab0$97b0c010$@codeaurora.org> (raw)
In-Reply-To: <003c01d234d5$731b19c0$59514d40$@codeaurora.org>

Hi,

>-----Original Message-----
>From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-owner@vger.kernel.org] On Behalf Of Sricharan
>Sent: Wednesday, November 02, 2016 12:21 PM
>To: 'Stephen Boyd' <sboyd@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
>
>Hi Stephen,
>
>>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.
>>
>
>The hw control bit is set by default. Instead its turned 'off'
>with the reset value. So it has to not
>be turned 'on' at some point
>to put the gdsc in hw control if required. This bit is part of the
>gdscr register. So i did not quite understand the reason for the
>glitch here ?
>

typo above, i meant it has to be turned 'on' at some point
if required.

Regards,
 Sricharan

  reply	other threads:[~2016-11-02  6:53 UTC|newest]

Thread overview: 31+ 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-10-26  4:12       ` Sricharan
2016-11-02  0:18   ` Stephen Boyd
2016-11-02  6:50     ` Sricharan
2016-11-02  6:50       ` Sricharan
2016-11-02  6:53       ` Sricharan [this message]
2016-11-02  6:53         ` Sricharan
2016-11-02 17:59       ` 'Stephen Boyd'
2016-11-03 13:30         ` Sricharan
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  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-09 16:56               ` Sricharan
2016-11-10  2:32               ` Rajendra Nayak
2016-11-10  3:28                 ` Sricharan
2016-11-10  3:28                   ` Sricharan
2016-11-10 23:30               ` 'Stephen Boyd'
2016-11-14  3:51                 ` Sricharan
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='003e01d234d5$dd3aeab0$97b0c010$@codeaurora.org' \
    --to=sricharan@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=sboyd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.