Hi Stephen, >> >> 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. > Right, i already debugged this sort of a scenario which was quite paintful sometime back :) >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. > ok, which means with this approach, this patch can be dropped and the other bits needs to be added to the video driver. I will follow that up with Stanimir in his video driver patches. 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
