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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
