[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <003c01d234d5$731b19c0$59514d40$@codeaurora.org>
Date: Wed, 2 Nov 2016 12:20:44 +0530
From: "Sricharan" <sricharan@...eaurora.org>
To: "'Stephen Boyd'" <sboyd@...eaurora.org>
Cc: <mturquette@...libre.com>, <linux-clk@...r.kernel.org>,
<linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<rnayak@...eaurora.org>, <stanimir.varbanov@...aro.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 ?
Regards,
Sricharan
Powered by blists - more mailing lists