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