Add a dummy clk definition for the APB pclk signal on all platforms
using the AMBA bus infrastructure.  This ensures that these platforms
continue to work when the core amba bus code controls the APB pclk.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add clock framework support for changing the rate of sys_clkout2.
Signed-off-by: NLaine Walker-Avina <lwalkera@ieee.org>
[paul@pwsan.com: added commit message, added .round_rate pointer]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit 678bc9a2 split dpll4_m2_ck,
creating a 34xx and a 36xx variant, to handle the additional 16
divider steps provided on the 36xx.  This in turn required dynamic
rewriting of the clock tree during initialization, which is
undesirable.  All this seems to be unnecessary, though, since the
additional 16 divider steps can simply be marked with RATE_IN_36XX.
This patch does so and re-merges the affected structures.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Vishwanath Sripathy <vishwanath.bs@ti.com>

Rename the RATE_IN_343X clksel_rate.rate flag to be RATE_IN_3XXX, to reflect
that these rates are valid on all OMAP3 platforms, not just 343X.

Also rename the RATE_IN_OMAP3430ES2 clksel_rate.rate flag to be
RATE_IN_OMAP3430ES2PLUS, to reflect that these flags are valid on all
OMAP3 platforms after 3430ES2.

This patch should not result in any functional changes.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>

The DEFAULT_RATE clksel_rate flag is essentially useless.  It was set
on some of the lowest divisors, which, when switching to a much
higher-rate parent, could have potentially resulted in rates that
exceeded the hardware specifications for downstream clocks in the
window between the clk_set_parent(), and a subsequent clk_set_rate().
It seems much safer to just remove the flag and always use the highest
available divisor (resulting in the lowest possible rate) after the
switch, and this patch does so.

Ideally, it would be best to first attempt to switch to a divisor that
matches the clock's rate with the previous parent, if at all possible.
But that is a project for some other day or some other person.  The
parent changing code is rarely used.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The emac driver currently uses Davinci clock names for the module and phy
clocks. Updated the omap3xxx_clks table to match the names
used by the Davinci emac driver.

Note that eventually the EMAC clocks should be renamed to be generic.
Signed-off-by: NSriramakrishnan <srk@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: updated patch description to match the patch]
Signed-off-by: NTony Lindgren <tony@atomide.com>

- registration with multi OMAP kernels support
- clocks
Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@nokia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The enable bit for dpll4_m4x2 clock should be OMAP3430_PWRDN_DSS1_SHIFT.
The code erroneously uses OMAP3430_PWRDN_CAM_SHIFT which is meant for
dpll4_m5x2 clock.

This came into notice during a recent review of the clock tree.
Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add necessary clk_sel definitions to clock framework to allow changing
dpll4_m5_ck_3630 rate. This is used by the ISP driver.
Signed-off-by: NVimarsh Zutshi <vimarsh.zutshi@nokia.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The RATE_FIXED clock flag is pointless.  In the OMAP1 clock code, it
simply causes the omap1_clk_round_rate() function to return the
current rate of the clock.  omap1_clk_round_rate(), however, should
never be called for a fixed-rate clock, since none of these clocks
have a .round_rate function pointer set in their struct clk records.
Similarly, in the OMAP2+ clock code, the RATE_FIXED flag just causes
the clock code to emit a warning if the OMAP clock maintainer was
foolish enough to add a .round_rate function pointer to a fixed-rate
clock.  "Doctor, it hurts when I pretend that a fixed-rate clock is
rate-changeable."  "Then don't pretend that a fixed-rate clock is
rate-changeable."  It has no functional value.  This patch drops the
RATE_FIXED clock flag, removing it from all clocks that are so marked.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>

clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c.  Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate.  So now "clock3xxx.*" refers to the OMAP3
superset.

The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family.  To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.

OMAP4 is also affected by this.  It duplicated the OMAP3 non-CORE DPLL
clkops structure.  The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it.  (The OMAP4 clock autogeneration scripts have 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>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

After the clkdev conversion, the struct clk.id field became
superfluous, so, drop it.  Bring the clock names closer to the TRMs
and ensure they are unique for debugfs.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

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>

In 3630, DPLL4M2 output can be 96MHz or 192MHz (for SGX to run at
192). This patch has changes to support this feature. 96MHz clock is
generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register.
SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's
functional clock. In summary changes done are:
1. Added a feature called omap3_has_192mhz_clk and enabled for 3630
2. Added a new clock node called omap_192m_alwon_ck
3. Made omap_96m_alwon_fck to derive its clock from omap_192m_alwon_ck
Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
[paul@pwsan.com: fixed whitespace]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
in 3630. This patch has changes to accommodate this in CM dynamically
based on chip version.
Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
M6 and value of these nodes are used if cpu type is 3630.
Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
[paul@pwsan.com: updated to apply on 2.6.34 queue; comments added]
Signed-off-by: NPaul Walmsley <paul@pwsan.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>

This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.

Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).

Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
        (in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
        (CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: NMike Turquette <mturquette@ti.com>
Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: NVijaykumar GN <vijaykumar.gn@ti.com>
[paul@pwsan.com: updated patch to apply; made workaround function static;
 marked as being 36xx-specific]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This patch adds clock support for the following AM35xx modules
	- Ethernet MAC
	- CAN Controller (HECC)
	- New MUSB OTG Controller with integrated Phy
	- Video Processing Front End (VPFE)
	- Additional UART (UART4)
Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Rename clkops_noncore_dpll_ops for omap3 and omap4.
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Rename the omap2_clk_init() in the OMAP2, 3, and 4 clock code to be
omap2xxx_clk_init(), omap3xxx_clk_init(), etc.  Remove all traces of
the (commented) old virt_prcm_set code from omap3xxx_clk_init() and
omap4xxx_clk_init(), since this will be handled with the OPP code that
is cooking in the PM branch.

After this patch, there should be very little else in the clock code
that blocks a multi-OMAP 2+3 kernel.  (OMAP2420+OMAP2430 still has some
outstanding issues that need to be resolved; this is pending on some
additions to the hwmod data.)
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

One of the OMAP1 clocks can use the fixed divisor recalculation code
introduced in the OMAP2 clock code, so rename the
omap2_fixed_divisor_recalc() function to omap_fixed_divisor_recalc()
and make it available to all OMAPs.  A followup patch converts the OMAP1
clock.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

AM3505/17 though a OMAP3530 derivative have the following
main differences

	- Removal of the following OMAP3 modules
		- IVA
		- ISP/CAM
		- Modem and D2D components (MAD2D, SAD2D)
		- USIM
		- SSI
		- Mailboxes
		- USB OTG
		- ICR
		- MSPRO
		- SmartReflex
	- SDRC replaced with EMIF4 Controller in the SDRC subsystem
	  thus adding support for DDR2 memory devices
	- Addition of the following new modules
		- Ethernet MAC (CPGMAC)
		- CAN Controller (HECC)
		- New USB OTG Controller with integrated Phy
		- Video Processing Front End (VPFE)
		- Additional UART (UART4)
	- All security accelerators disabled on GP devices and not to
	  be accessed or configured

This patch defines CPU flags for AM3505/17 and update the clock table.
Clock support for new modules will be added by subsequent patches.
Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com>
[paul@pwsan.com: updated for 2.6.34 clock layout]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add CK_* flags for the two new Sitara chips, AM3505 and AM3517, and
the OMAP34xx die shrink, OMAP36xx/OMAP37xx.  Introduce a new CK_*
flag, CK_3XXX, that marks all clocks that are common to OMAP3 family
chips.  CK_343X now refers to clocks that are available only on
OMAP34{1,2,3,4}0 (WTBU) and OMAP35{03,15,25,30} (any version).
At some point, the RATE_IN_* flags should be updated also.

While here, add some documentation describing the chip families
covered by these clock flags.

This patch is partially based on patches from Ranjith Lohithakshan
<ranjithl@ti.com> and Vishwanath Sripathy <vishwanath.bs@ti.com>.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Vishwanath Sripathy <vishwanath.bs@ti.com>

The first thing that omap2_init_clksel_parent() does is check for
a non-zero .clksel field in the struct clk.  Therefore, it is
pointless calling this function on clocks where the clksel field
is unset.

Remove init calls to omap2_init_clksel_parent() on clocks without
a clksel field.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add necessary definitions to clock framework to allow changing
dpll4_m5_ck rate.  This is used by the camera code.
Signed-off-by: NJouni Högander <jouni.hogander@nokia.com>
Signed-off-by: NTuukka Toivonen <tuukka.o.toivonen@nokia.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The correct parent of the McBSP 2, 3, and 4 functional clocks is
PER_96M_FCLK, not CORE_96M_FCLK.  Fix this in the OMAP clock tree.
Reported by Nicole Chalhoub <n-chalhoub@ti.com>.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Nicole Chalhoub <n-chalhoub@ti.com>

UART1 & 2 were missing clockdomains resulting in broken omap_hwmod
init for these devices.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.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>

Current calculation does not take into account any changes to M2 divisor, and
thus when we change VDD2 OPP, dpll3_m2x2 rate does not change. Fixed by
re-routing dpll3_m2x2 parent to dpll3_m2.
Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.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>

omap2_init_clk_clkdm() is called as part of the chip architecture-specific
initialization code, so calling it again from the struct clk init pointer
just wastes cycles.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

All MPU-related clocks should be in the mpu_clkdm.  This is needed for the
upcoming omap_hwmod patches, which needs to know the clockdomain that arm_fck
is in.
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>

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>

Processor specific macros should be used instead.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Processor specific macros should be used instead.
Signed-off-by: NTony Lindgren <tony@atomide.com>

GPIO de-bounce clocks don't have any impact on the module idle state, so
the clock code should not wait for the module to enable after the de-bounce
clocks are enabled.

Problem found by Kevin Hilman <khilman@deeprootsystems.com>.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files
to use in .init_irq functions to configure the system tick GPTIMER.
Practical choices at this point are GPTIMER1 or GPTIMER12.  Both of
these timers are in the WKUP powerdomain, and so are unaffected by
chip power management.  GPTIMER1 can use sys_clk as a source, for
applications where a high-resolution timer is more important than
power management.  GPTIMER12 has the special property that it has the
secure 32kHz oscillator as its source clock, which may be less prone
to glitches than the off-chip 32kHz oscillator.  But on HS devices, it
may not be available for Linux use.

It appears that most boards are fine with GPTIMER1, but BeagleBoard
should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs
in revisions B4 and below.  Modify board-omap3beagle.c to use GPTIMER12.

This patch originally used a Kbuild config option to select the GPTIMER,
but was changed to allow this to be specified in board-*.c files, per
Tony's request.

Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of
this patch - thanks Kalle.

Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and
3430SDP.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Cc: Kalle Valo <kalle.valo@nokia.com>

This patch avoids waiting for the camera module to become ready,
since it doesn't have IDLEST bit.

Based on a earlier hack done by Paul Walmsley on Sep 9 2008 on
linux-omap tree.
Signed-off-by: NSergio Aguirre <saaguirre@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.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>