Hi, >-----Original Message----- >From: linux-arm-msm-ow...@vger.kernel.org >[mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Sricharan >Sent: Wednesday, November 02, 2016 12:21 PM >To: 'Stephen Boyd' <sb...@codeaurora.org> >Cc: mturque...@baylibre.com; linux-...@vger.kernel.org; >linux-arm-...@vger.kernel.org; linux-kernel@vger.kernel.org; >rna...@codeaurora.org; stanimir.varba...@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
