monarudo-display: remove regulators controlled by mdp
acpuclock-8960 is not used anymore, remove it

I keep getting confused when doing greps/diffs/etc.

Conflicts:
	arch/arm/mach-msm/acpuclock-8960.c
monarudo-gpu: remove unused (duplicated) definitions

These were moved to device-monarudo-gpu awhile ago, but seem to still
exists here as well.  Clean it up.
Sync with caf's board-8064-gpu.c

Note that this changes the second GPU frequency from 325000000
to 320000000.  This is important because the Fmax table has entries
for 400000000 and 320000000 and the frequencies are matched against
the Fmax table.

Prior to this commit the actual frequencies were 400000000 for the
first two scaling levels and 325000000 was never possible.
Set the default GPU speed to be 200000000

For some reason this seems to let it scale better.  When left at
32000000, it doesn't seem to want to go lower than that for me.

While this doesn't look believable in the code, setting the lower
default speed should in theory have no negative impact as the scaling
will change it as needed.

This also matches the setting of the M7 kernel.
msm: clock-local: Make branch ctl_reg optional

Branch clocks will soon be used for reset-only purposes, in which
case the ctl_reg field will be NULL. Update the branch handoff
and disable code to check for a NULL register address before
reading the register.

Change-Id: I728b2c1ab2ea6a25010b15b3fb553390003175e2
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: clock: Fix hardware clock gating detection for mdp_axi_clk

clock-debug uses a clock flag (CLKFLAG_HWCG) to determine if a
clock is capable of hardware gating. Unfortunately, recent
changes to clock handoff cause this flag to not always be set.

Take mdp_axi_clk for example. It is a depends of mdp_clk, and so
if mdp_clk is on out of the bootloader, mdp_axi_clk is indirectly
enabled by the clk_prepare_enable() call in __handoff_clk() when
mdp_clk is enabled. We could add support for handing off depends
clocks, but we're planning on removing the depends code and there
isn't a real problem in failing to hand off branches that are
depends since they're hidden from consumers anyway.

The only problem with this scenario is that branch_handoff() is
not called and so mdp_axi_clk is not marked as supporting
hardware clock gating. The clock flag is only used to indicate
support for hardware clock gating, so let's just read the
hardware anytime a users wants to know if the clock has hardware
gating or not.

This changes the semantics of the has_hw_gating file because we
read the hardware instead of returning a cached value and the
state of the hardware changes at runtime (e.g. if the clock is
put into reset hardware gating is turned off). In practice these
clocks aren't switching in and out of hardware gating mode while
a clock test is in progress so the impact of this change is
minimal to zero.

Change-Id: I4f646b1b32b42e3ef00067b47ffb78df8fb761d5
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
msm: clock: Move voltage scaling to prepare/unprepare

Move the voltage calls to a sleepable context so we can avoid
spinning for hundreds of microseconds with interrupts disabled
waiting for a regulator to increase. This change also paves the
way to making the clock driver into a real regulator consumer
that uses the proper regulator APIs instead of the MSM specific
rpm_vreg API.

Doing this also requires us to make clk_set_rate() a sleeping
call so that concurrent clk_prepare() and clk_set_rate() calls
are synchronized. Making clk_set_rate() sleepable also
necessitates moving the clk_set_rate() call in clock-voter.c to a
sleepable context. Do that by having clock-voter aggregate and
update the rate in prepare/unprepare instead of enable/disable
(note that enable/disable of voter clocks implicitly calls
enable/disable on the parent via generic clock code).

Now that clk_set_rate() is sleeping, call clk_prepare() and
clk_unprepare() in the clock-local code when a rate change
requires reparenting the clock. This cleans up a problem we have
where sources may be left unprepared by a clock rate switch
(hence the default true warned flag for PLLs and crystals).

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
(cherry picked from commit d86d1f2d968f194e3db46bb683e370a9fa3a6037)

Conflicts:

	arch/arm/mach-msm/clock-local2.c

Change-Id: Ie5bbb17537d5b33de92f8ea1c2da6070b18c14f1
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/clock-8960.c
	arch/arm/mach-msm/clock-local2.c
	arch/arm/mach-msm/clock.c
msm: clock-rpm: Have RPM handoff account for the RPM-SMD driver

The RPM-SMD driver and the correponding communication protocol
with the RPM does not currently support querying of clock rates.
Allow handoff to always succeed for RPM-SMD clocks. Previously,
the older RPM driver API stub would always return failure
causing RPM handoff to fail.

Change-Id: I357430dec06a2305cdad2af4c213a3b98965e1e1
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/clock-rpm.c
msm: clock-rpm: Set the sleep vote only for sleep set clocks in handoff

The RPM clock handoff is erroneously setting last_sleep_set_khz
for clocks that only vote in the active-set. This results in an
incorrect sleep set vote to the RPM that does not go away even
when the corresponding (peer) sleep-and-active-set RPM clock is
disabled.

Set the last_sleep_set_khz value only if the clock in question
is not an active-set-only clock.

An example failure occurs as follows:

The system fabric clock is running at 192MHz on bootup. The
handoff code for the sfab_a_clk (the active set only clock)
sets last_set_khz and last_sleep_set_khz to 192MHz. Now, in
late_init, when sfab_clk is disabled, the sfab_a_clk's
last_sleep_set_khz value is sent to the RPM. This is wrong -
we are disabling the sleep-and-active-set clock, but we just
sent a rate of 192MHz to the RPM as our sleep set vote.
When the apps procesor transitions to the sleep set, if there
have been no other votes for sfab_clk and sfab_a_clk, the RPM
will figure that the apps needs 192 MHz on the system fabric
in the sleep set, even though sfab_clk on the apps side is
"disabled".

With the fix in place, sfab_a_clk's last_sleep_set_khz is 0,
and therefore when sfab_clk is disabled, the correct vote of
0 goes to the RPM.

CRs-Fixed: 392302
Change-Id: Iee47a3c4e683e335454d2485c4c4c5b1bc0d772c
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
(cherry picked from commit af72b71744e4c09ba210f2a68f1961dfe4d34c25)