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 -- 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
