On 11/09, Sricharan wrote: > > So the above is the sequence which is actually carried out on the > firmware side. The same can be done in host as well. > The clocks stuck issue indeed is not there with this. Great! We've finally connected on what the actual problem is. > But with the above sequence we need to add a step to do inverse > of STEP3 above (ie write the registers to de-assert hw_signal), > to keep the subdomains in off, till firmware uses it. So the > above sequence helps to avoid masking the halt check, although > the host really does not wants to use these clocks, except > setting it up for the firmware. > Right, but knowing that the clocks failed to turn on in the first place is much safer than silently ignoring the failure. Otherwise, we could hand over control to the firmware, and the firmware would fail to operate the hardware, and we're stuck with debugging the firmware now. That sounds quite painful to figure out. If we properly toggle the video hw bits in coordination with firmware and turn on/off the clocks with the GDSC ON, then debugging is made simpler. The point is, we don't want to lose robustness by silencing halt checks. The semantics of clk_enable() means the clock is running, and that won't be true here unless we ensure the GDSC is enabled. -- 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
