J-Type DPLLs have additional configuration parameters that need to
be programmed when setting the multipler and divider for the DPLL.
These parameters being the sigma delta divider (SD_DIV) for the DPLL
and the digital controlled oscillator (DCO) to be used by the DPLL.

The current code is implemented specifically to configure the
OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL
and so this code needs to be updated to work for both OMAP3 and OMAP4
devices and any other future devices that have J-TYPE DPLLs.

For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are
used but for the OMAP4430 USB DPLL only the SD_DIV field is used.
The current implementation will only program the SD_DIV and DCO
fields if the DPLL has both and hence this does not work for
OMAP4430.

In order to make the code more generic add two new fields to the
dpll_data structure for the SD_DIV field and DCO field bit-masks
and only program these fields if the masks are defined for a specific
DPLL. This simplifies the code and allows us to remove the flag
DPLL_NO_DCO_SEL.

Tested on OMAP36xx Zoom3 and OMAP4 Blaze.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*()
 functions; added testing info to commit message; added 35xx comments back in]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.

This process also requires the #includes in each of these files to be
changed to reference the new file name.  As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.

Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: NFelipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are
one increment higher than they should be.  See for example the
OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the
OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL".  Programming a 0 into
the DPLL's M register bitfield is valid for OMAP2/3 and indicates that
the DPLL should enter MN-bypass mode.  Also, increase the minimum
multiplier (M) value for the DPLL rate rounding code from 1 to 2, to
ensure that it does not inadvertently put the DPLL into bypass.

Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs
does not make clear that the actual DPLL divider value (the "N") is
the content of the appropriate register bitfield for the N value,
_plus one_.  (In other words, an N register bitfield of 0 indicates a
DPLL divider value of 1.)  This is only clearly documented in the
OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167
"CM_CLKSEL_DPLL_USB".

While here, update copyrights, add kerneldoc for struct dpll_data,
drop the unused struct dpll_data.max_tolerance field, remove some
unnecessary #includes in DPLL-related code, and replace the #include
of <linux/module.h> with <linux/list.h>, which is what was really
needed.  The OMAP4 clock autogenerator script has been updated
accordingly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>

DPLL4 for 3630 introduces a changed block called j type dpll, requiring
special divisor bits and additional reg fields. To allow for silicons to
use this, this is introduced as a flag and is enabled for 3630 silicon.
OMAP4 also has j type dpll for usb.

Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
[paul@pwsan.com: added some comments; updated copyrights and credits; fixed
 some style issues]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
OMAP3630. So remove references to that.
Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
[paul@pwsan.com: added comment fix from Sergei Shtylyov]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Move all static functions up to the top of the file to match the
practice in other OMAP clock code.  Make omap3_noncore_dpll_program()
static (noted by sparse) and prepend an underscore to the function
name to mark that it is file-local.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Mark the OMAP3-specific DPLL functions as being OMAP3-specific by moving
them from mach-omap2/dpll.c to mach-omap2/dpll3xxx.c.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

Most of the dpll api's from dpll.c are reused for OMAP4.
This patch does extend a few api's for OMAP4 support.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>

This patch moves all the dpll control api's to a
common file dpll.c. This is in preperation of omap4
support wherein most of these api's can be reused.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>

The OMAP3 clock code currently #includes a large .h file full of static
data structures.  Instead, define the data in a .c file.

Russell King <linux@arm.linux.org.uk> proposed this new arrangement:

    http://marc.info/?l=linux-omap&m=125967425908895&w=2Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Russell King <linux@arm.linux.org.uk>

clock34xx.c contains some macros which probably belong in mach-omap2/sdrc.h.
Move those macros to mach-omap2/sdrc.h.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some parts of the clock code took advantage of the fact that the statically
allocated clock tree was in clock{,24xx,34xx}.c's local namespace to do some
extra argument checks.  These are overzealous and are more difficult to
maintain when the clock tree is in a separate namespace, so, remove them.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The upcoming new display subsystem driver is divided to two devices,
omapdss and omapfb, of which omapdss handles the actual hardware.

This patch adds a dummy omapdss platform device for the current omapfb
driver, which is then used to get the clocks. This will make it possible
for the current and the new display drivers to co-exist.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: NTony Lindgren <tony@atomide.com>

This enables on-chip tracing components found in omap3xxx.
Signed-off-by: NAlexander Shishkin <virtuoso@slind.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix the freqsel value computation. Use n instead of (n+1)

The formula in the TRM uses a zero-based N, hence the (n+1); however
at this point in the clock34xx.c code, N is one-based.

Hayati Bayrakdar <h-bayrakdar@ti.com> and Nishanth Menon <nm@ti.com> helped
track down this bug.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
[paul@pwsan.com: modified commit message]
Cc: Hayati Bayrakdar <h-bayrakdar@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.

This was done with:

#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"

for header in $headers; do
	old="#include <mach\/$header"
	new="#include <plat\/$header"
	for dir in $omap_dirs; do
		find $dir -type f -name \*.[chS] | \
			xargs sed -i "s/$old/$new/"
	done
	find drivers/ -type f -name \*omap*.[chS] | \
		xargs sed -i "s/$old/$new/"
	for file in $other_files; do
		sed -i "s/$old/$new/" $file
	done
done

for header in $(ls $mach_dir_old/*.h); do
	git mv $header $plat_dir_new/
done
Signed-off-by: NTony Lindgren <tony@atomide.com>

Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and
USBTLL f-clock are the only users of this DPLL, and 120MHz is
is the only recommended rate for these clocks.

With this patch, the 60 MHz ULPI clock is generated correctly.

Tested on an OMAP3430 SDP.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The argument 'mpurate' had no effect on the MPU
frequency. This patch fixes the same.
Signed-off-by: NSanjeev Premi <premi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:

    Clock usbhost_48m_fck didn't enable in 100000 tries

Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.

Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.

This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].

In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.

Problem reported by Jarkko Nikula <jhnikula@gmail.com>:

    http://marc.info/?l=linux-omap&m=124306184903679&w=2

...

1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).

2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.

3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.htmlSigned-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>

Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2
SDRAM parts connected to the SDRC.

This patch adds the following:
- add a new argument of type omap_sdrc_params struct*
to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw
- add the SDRC 2nd CS registers offsets defines
- adapt the sram sleep code to configure the SDRC for the 2nd CS

Note: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registers

Tested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume and frequency changes (cpufreq).
Signed-off-by: NJean Pihet <jpihet@mvista.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control.
Signed-off-by: NTero Kristo <tero.kristo@nokia.com>

Program the SDRC_MR_0 register as well during SDRC clock changes.
This register allows selection of the memory CAS latency.  Some SDRAM
chips, such as the Qimonda HYB18M512160AF6, have a lower CAS latency
at lower clock rates.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

When changing the SDRAM clock from 166MHz to 83MHz via the CORE DPLL M2
divider, add a short delay before returning to SDRAM to allow the SDRC
time to stabilize.  Without this delay, the system is prone to random
panics upon re-entering SDRAM.

This time delay varies based on MPU frequency.  At 500MHz MPU frequency at
room temperature, 64 loops seems to work okay; so add another 32 loops for
environmental and process variation.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

On the OMAP3, initialize SDRC timings when the kernel boots.  This ensures
that the kernel is running with known, optimized SDRC timings, rather than
whatever was configured by the bootloader.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add D2D clocks (modem_fck, sad2d_ick, mad2d_ick) to clock framework
and ensure that auto-idle bits are set for these clocks during PRCM
init.

Also add omap3_d2d_idle() function called durint PRCM setup which
ensures D2D pins are MUX'd correctly to enable retention for
standalone (no-modem) devices.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This makes the framebuffer work on omap3.

Also fix the clk_get usage for checkpatch.pl
"ERROR: do not use assignment in if condition".

Cc: Imre Deak <imre.deak@nokia.com>
Cc: linux-fbdev-devel@lists.sourceforge.net
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Rename clk_init_one() to clk_preinit() to distinguish its function
from clk_init() and the individual struct clk init functions.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The CORE DPLL M2 frequency change code should use pr_debug(), not
pr_info(), for its debug messages.  Same with
omap2_clksel_round_rate_div().  While here, convert a few printk(KERN_ERR ..
into pr_err().
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

According to the 34xx TRM Rev. K section 11.2.4.4.11.1 "Purpose of the
DLL/CDL Module," the SDRC delay-locked-loop can be locked at any SDRC
clock frequency from 83MHz to 166MHz.  CDP code unconditionally
unlocked the DLL whenever shifting to a lower SDRC speed, but this
seems unnecessary and error-prone, as the DLL is no longer able to
compensate for process, voltage, and temperature variations.  Instead,
only unlock the DLL when the SDRC clock rate would be less than 83MHz.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

With the clkdev, musb_core.c needs to register clock with name "ick".

Once all the platforms using the musb driver have been converted
to use clockdev, the clock name does not need to be passed
from the low-level init code.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This roughly corresponds with OMAP commits: 7d06c48, 3241b19,
88b5d9b, 18a5500, 9c909ac, 5c6497b, 8b1f0bd, 2ac1da8.

For both OMAP2 and OMAP3, we note the reference and bypass clocks in
the DPLL data structure.  Whenever we modify the DPLL rate, we first
ensure that both the reference and bypass clocks are enabled.  Then,
we decide whether to use the reference and DPLL, or the bypass clock
if the desired rate is identical to the bypass rate, and program the
DPLL appropriately.  Finally, we update the clock's parent, and then
disable the unused clocks.

This keeps the parents correctly balanced, and more importantly ensures
that the bypass clock is running whenever we reprogram the DPLL.  This
is especially important because the procedure for reprogramming the DPLL
involves switching to the bypass clock.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

linux-omap source commit 33d000c99ee393fe2042f93e8422f94976d276ce
introduces a way to "dry run" clock changes before they're committed.
However, this involves putting logic to handle this into each and
every recalc function, and unfortunately due to the caching, led to
some bugs.

Solve both of issues by making the recalc methods always return the
clock rate for the clock, which the caller decides what to do with.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Clock rate change code executes inside a spinlock with hardirqs
disabled.  The only code that should be messing around with the
hardirq state should be the plat-omap/clock.c code.  In the
omap2_reprogram_dpllcore() case, this probably just wastes cycles, but
in the omap3_core_dpll_m2_set_rate() case, this is a nasty bug.

linux-omap source commit is b9b6208dadb5e0d8b290900a3ffa911673ca97ed.
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>

Traditionally, we've tracked the parent/child relationships between
clk structures by setting the child's parent member to point at the
upstream clock.  As a result, when decending the tree, we have had
to scan all clocks to find the children.

Avoid this wasteful scanning by keeping a list of the clock's children.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This implements the remainder of:
  OMAP clock: move rate recalc, propagation code up to plat-omap/clock.c
from Paul Walmsley which is not covered by the previous:
  [ARM] omap: move clock propagation into core omap clock code
  [ARM] omap: remove unnecessary calls to propagate_rate()
  [ARM] omap: move propagate_rate() calls into generic omap clock code
commits.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the standard clk_set_rate() function in omap2_clk_arch_init()
rather than omap2_select_table_rate() -- this will ensure that clock
rates are recalculated and propagated correctly after those operations
are consolidated into clk_set_rate().

linux-omap source commit is 03c03330017eeb445b01957608ff5db49a7151b6.
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 the omap3_core_dpll_m2_set_rate() function to the OMAP3 clock code,
which calls into the SRAM function omap3_sram_configure_core_dpll() to
change the CORE DPLL M2 divider.  (SRAM code is necessary since rate changes
on clocks upstream from the SDRC can glitch SDRAM accesses.)

Use this function for the set_rate function pointer in the dpll3_m2_ck
struct clk.  With this function in place, PM/OPP code should be able to
alter SDRAM speed via code similar to:

      clk_set_rate(&dpll3_m2_ck, target_rate).

linux-omap source commit is 7f8b2b0f4fe52238c67d79dedcd2794dcef4dddd.
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>

Move the contents of the arch/arm/mach-omap2/memory.h file to the
existing mach/sdrc.h file, and remove memory.h.  Modify files which
include memory.h to include asm/arch/sdrc.h instead.

linux-omap source commit is e7ae2d89921372fc4b9712a32cc401d645597807.
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>

During _omap3_noncore_dpll_lock(), if a DPLL has no active downstream
clocks and DPLL autoidle is enabled, the DPLL may never lock, since it
will enter autoidle immediately.  To resolve this, disable DPLL
autoidle while locking the DPLL, and unconditionally wait for the DPLL
to lock.  This fixes some bugs where the kernel would hang when returning
from retention or return the wrong rate for the DPLL.

This patch is a collaboration with Peter de Schrijver
<peter.de-schrijver@nokia.com> and Kevin Hilman
<khilman@deeprootsystems.com>.

linux-omap source commit is 3b7de4be879f1f4f55ae59882a5cbd80f6dcf0f0.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Peter de Schrijver <peter.de-schrijver@nokia.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>