Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1513581 > unrolled thread

Re: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW  control Stephen Boyd <sboyd@codeaurora.org> - 2016-11-02 01:30 +0100
    RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control "Sricharan" <sricharan@codeaurora.org> - 2016-11-02 08:00 +0100
      RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control "Sricharan" <sricharan@codeaurora.org> - 2016-11-02 08:00 +0100
      Re: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW  control 'Stephen Boyd' <sboyd@codeaurora.org> - 2016-11-02 19:00 +0100
        RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control "Sricharan" <sricharan@codeaurora.org> - 2016-11-03 14:40 +0100
          Re: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW  control 'Stephen Boyd' <sboyd@codeaurora.org> - 2016-11-03 21:10 +0100

#1513581 — Re: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control

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

[toc] | [next] | [standalone]

#1513679 — 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 ?

Regards,
 Sricharan

[toc] | [prev] | [next] | [standalone]

#1513680 — RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control

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

[toc] | [prev] | [next] | [standalone]

#1514051

On 11/02, Sricharan wrote:
> 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 ?

I mean the reset value of the hw control signal inside the device
that is inside the GDSC power domain. For example, the hw control
bit inside the video core.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1514530 — 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 ?
>
>I mean the reset value of the hw control signal inside the device
>that is inside the GDSC power domain. For example, the hw control
>bit inside the video core.
>
 Ok, so the video ip core, has a hw control signal/bit.
 I checked this by dumping this out that,  the moment the
gdsc is put to hw control, the video ip's hw control bit also
gets asserted/set. so this means that video ip's bit get
aligned with the gdsc setting.  so this should avoid the
glitches, right ?

Regards,
 Sricharan

[toc] | [prev] | [next] | [standalone]

#1514809

On 11/03, Sricharan wrote:
>  Ok, so the video ip core, has a hw control signal/bit.
>  I checked this by dumping this out that,  the moment the
> gdsc is put to hw control, the video ip's hw control bit also
> gets asserted/set. so this means that video ip's bit get
> aligned with the gdsc setting.  so this should avoid the
> glitches, right ?
> 

Yes that matches my understanding. Thanks for confirming.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web