Hi, > >A better design would be to check if the associated GDSC is in hw >control mode and then skip the checks because the clocks are no >longer under the control of the registers. I presume we only >enable the clocks here to turn on parent clocks which don't turn >on/off automatically, i.e. the PLL. > I was thinking clocks in the powerdomain still needs to be turned on explicitly, these are branch clocks, irrespective of the PLLs. Putting the gdsc in hw_ctrl, only makes the polling on their status invalid. Anyways would be good to be aligned on this. >Given that hw control is a static decision I guess that is an >over-engineered solution though? The problem is that this seems >brittle because we have to keep two things in sync, the branches >and the gdsc. So I guess this is ok, but it deserves a comment >like "GDSC is in HW control" so we know what's going on. Also the >commit text could be more explicit that clocks within the gdsc >power domain don't work when the gdsc is off, and with hw control >of a gdsc we can't tell when the gdsc may be off or on. > ok, i will reword the commit log better as above. So i understand its ok to continue with this way of checking ? since we are always having a static association which never changes, than introducing additional fields in the clk_branch which can get the status of the gdsc. 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
