On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote:

On 11/04, Sricharan wrote:

quoted

Hi,

quoted

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.

Sure. We also need to make sure the branches are on themselves.
When the gdsc is disabled the clocks are killed though. This is
why we can't enable clocks until the gdsc is enabled.

quoted

quoted

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.

Well I'm also curious which case is failing. Does turning on the
clocks work after the gdsc is enabled? Does turning off the
clocks fail because we don't know when the gdsc has turned off? I
would hope that the firmware keeps the gdsc on when it's done
processing things, goes idle, and hands back control to software.
Right now I'm failing to see how the halt bits fail to toggle
assuming that firmware isn't misbehaving and the kernel driver is
power controlling in a coordinated manner with the firmware.

What fails is turning ON the clocks after the gdsc is put under
hardware control (by fails I mean the halt checks fail to indicate
the clock is running, but register accesses etc thereafter suggest
the clocks are actually running)
The halt checks seem to work only while the gdsc is put in SW enabled
state.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation