The SGX device on OMAP3 does not support retention, so remove RET from the
list of possible SGX power states.  Problem debugged by Richard Woodruff
<r-woodruff2@ti.com>.
Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Each DPLL exists in its own powerdomain (cf 34xx TRM figure 4-18) and
clockdomain; so, create powerdomain and clockdomain structures for them.
Mark each DPLL clock as belonging to their respective DPLL clockdomain.
cf. 34xx TRM Table 4-27 (among other references).

linux-omap source commits are acdb615850b9b4f7d1ab68133a16be8c8c0e7419 and
a8798a48f33e9268dcc7f30a4b4a3ce4220fe0c9.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

sys_clkout2 belongs in the core_clkdm (3430 TRM section 4.7.2.2).
It's not clear whether it actually is in the CORE clockdomain, or whether
it is technically in a different clockdomain; but this is closer to
reality than the present configuration.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add clockdomains for the CM and PRM.  These will ultimately replace the
"wkup_clkdm", which appears to not actually exist on the hardware.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

struct clockdomain contains a struct powerdomain *pwrdm and const char
*pwrdm_name.  The pwrdm_name is only used at initialization to look up
the appropriate pwrdm pointer.  Combining these into a union saves
about 100 bytes on 3430SDP.  This patch should not cause any change in
kernel function.

Updated to gracefully handle autodeps that contain invalid powerdomains,
per Russell King's review comments.

Boot-tested on BeagleBoard ES2.1.

linux-omap source commit is 718fc6cd4db902aa2242a736cc3feb8744a4c71a.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch adds a CPUfreq frequency-table implementation for OMAP2 by
walking the PRCM rate-table for available entries and adding them to a
CPUfreq table.

CPUfreq can then be used to manage switching between all the available
entries in the PRCM rate table.  Either use the CPUfreq sysfs
interface directly, (see Section 3 of Documentation/cpu-freq/user-guide.txt)
or use the cpufrequtils package:
http://www.kernel.org/pub/linux/utils/kernel/cpufreq/cpufrequtils.htmlSigned-off-by: NKevin Hilman <khilman@mvista.com>

Updated to try to use cpufreq_table if it exists.

linux-omap source commit is 77ce544fa48deb7a2003f454624e3ca10d37ab87.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Filling the set_rate and round_rate fields of dpll4_m4_ck makes
this clock programmable through clk_set_rate().  This is needed
to give omapfb control over the dss1_alwon_fck rate.

This patch includes a fix from Tomi Valkeinen <tomi.valkeinen@nokia.com>.

linux-omap source commits are e42218d45afbc3e654e289e021e6b80c657b16c2 and
9d211b761b3cdf7736602ecf7e68f8a298c13278.
Signed-off-by: NMåns Rullgård <mans@mansr.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add CSI2 clock struct for handling it with clock API when TI PM is disabled.

linux-omap source commit is 8b20f4498928459276bd3366e3381ad595d23432.
Signed-off-by: NSergio Aguirre <saaguirre@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The GFX/SGX functional and interface clocks have different masks, for
some unknown reason, so split EN_SGX_SHIFT into one each for fclk and
iclk.

Correct according to the TRM and the far more important 'does this
actually work at all?' metric.

linux-omap source commit is de1121fdb899f762b9e717f44eaf3fae7c00cd3e.
Signed-off-by: NDaniel Stone <daniel.stone@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix some bugs in the OMAP3 clock tree pertaining to the 96MHz clocks.
The 96MHz portion of the clock tree should now have reasonable
fidelity to the 34xx TRM Rev I.

One remaining question mark: it's not clear exactly which 96MHz source
clock the USIM uses.  This patch sticks with the previous setting, which
seems reasonable.

linux-omap source commit is 15c706e8179ce238c3ba70a25846a36b73bd2359.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove usbhost_sar_fclk from the OMAP3 clock framework.  The bit that
the clock was tweaking doesn't actually enable or disable a clock; it
controls whether the hardware will save and restore USBHOST state
when the powerdomain changes state.  (That happens to coincidentally
enable a clock for the duration of the operation, hence the earlier
confusion.)

In place of the clock, mark the USBHOST powerdomain as supporting
hardware save-and-restore functionality.

linux-omap source commit is f3ceac86a9d425d101d606d87a5af44afef27179.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch adds a missing OMAP24xx clock, the SSI L4 interface clock,
as "ssi_l4_ick".

linux-omap source commit is ace129d39b3107d330d4cf6934385d13521f2fec.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix sparse & checkpatch warnings in OMAP2/3 PRCM & PM code.  This mostly
consists of:

- converting pointer comparisons to integers in form similar to
  (ptr == 0) to the standard idiom (!ptr)

- labeling a few non-static private functions as static

- adding prototypes for *_init() functions in the appropriate header
  files, and getting rid of the corresponding open-coded extern
  prototypes in other C files

- renaming the variable 'sclk' in mach-omap2/clock.c:omap2_get_apll_clkin
  to avoid shadowing an earlier declaration

Clean up checkpatch issues.  This mostly involves:

- converting some asm/ includes to linux/ includes

- cleaning up some whitespace

- getting rid of braces for conditionals with single following statements

Also take care of a few odds and ends, including:

- getting rid of unlikely() and likely() - none of this code is particularly
  fast-path code, so the performance impact seems slim; and some of those
  likely() and unlikely() indicators are probably not as accurate as the
  ARM's branch predictor

- removing some superfluous casts

linux-omap source commit is 347df59f5d20fdf905afbc26b1328b0e28a8a01b.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add non-CORE DPLL rate set code and M,N programming for OMAP3.
Connect it to OMAP34xx DPLLs 1, 2, 4, 5 via the clock framework.

You may see some warnings on rate sets from the freqsel code.  The
table that TI presented in the 3430 TRM Rev F does not cover Fint <
750000, which definitely occurs in practice.  However, the lack of this
freqsel case does not appear to impair the DPLL rate change.

linux-omap source commit is 689fe67c6d1ad8f52f7f7b139a3274b79bf3e784.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

... rather than the clock names themselves.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

... which now means no driver requests the "armxor_ck" clock directly.
Also, fix the error handling for clk_get(), ensuring that we propagate
the error returned from clk_get().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

By providing a dummy ick for OMAP1510 and OMAP310, we avoid having
SoC conditional clock information in i2c-omap.c.  Also, fix the
error handling by making sure we propagate the error returned via
clk_get().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rather than introducing a special 'mcbsp_clk' with code behind it in
mach-omap*/mcbsp.c to handle the SoC specifics, arrange for the mcbsp
driver to be like any other driver.  mcbsp requests its fck and ick
clocks directly, and the SoC specific code deals with selecting the
correct clock.

There is one oddity to deal with - OMAP1 fiddles with the DSP clocks
and DSP reset, so we move this to the two callback functions.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

... rather than the clock names themselves.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Eliminate the OMAP1 vs OMAP2 clock knowledge in the MMC driver.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Convert OMAP MMC driver to match clocks using the device ID and a
connection ID rather than a clock name.  This allows us to eliminate
the OMAP1/OMAP2 differences for the function clock.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Eliminate the OMAP1 vs OMAP2 clock knowledge in the watchdog driver.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This eliminates the need for separate OMAP24xx and OMAP34xx clock
requesting code sections.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

By providing a dummy clock node, we can eliminate the SoC conditional
clock handing in the OMAP drivers, moving this knowledge out of the
driver and into the machine clock support code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This stops things blowing up if a 'struct clk' to be passed more
than once to clk_register(), which will be required when we decouple
struct clk's from their names.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This is needed to use these with the clkdev helpers.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It makes no sense to have the CKCTL rate selection implemented as a flag
and a special exception in the top level set_rate/round_rate methods.
Provide CKCTL set_rate/round_rate methods, and use these for where ever
RATE_CKCTL is used and they're not already overridden.  This allows us
to remove the RATE_CKCTL flag.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

propagate_rate() is recursive, so it makes sense to minimise the
amount of stack which is used for each recursion.  So, rather than
recursing back into it from the ->recalc functions if RATE_PROPAGATES
is set, do that test at the higher level.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We've always called propagate_rate() in the parent function to
the .set_rate methods, so there's no point having the .set_rate
methods also call this heavy-weight function - it's mere
duplication of what's happening elsewhere.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move the clock propagation calls for set_parent and set_rate into
the core omap clock code, rather than having these calls scattered
throughout the OMAP1 and OMAP2 implementations.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

which only has to return clk->parent.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Nothing makes any use of these functions, so there's little point in
providing them.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>