Commit 32aaeffb (Merge branch
'modsplit-Oct31_2011'...) caused some build errors. Fix these
and make sure we always have export.h or module.h included
for MODULE_ and EXPORT_SYMBOL users:

$ grep -rl ^MODULE_ arch/arm/*omap*/*.c | xargs \
  grep -L linux/module.h
  arch/arm/mach-omap2/dsp.c
  arch/arm/mach-omap2/mailbox.c
  arch/arm/mach-omap2/omap-iommu.c
  arch/arm/mach-omap2/smartreflex.c

Also check we either have export.h or module.h included
for the files exporting symbols:

$ grep -rl EXPORT_SYMBOL arch/arm/*omap*/*.c | xargs \
  grep -L linux/export.h | xargs grep -L linux/module.h

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.

Having single/global registration of all the idle states,
dynamic C-state transitions on x86 are handled by
the boot cpu. Here, the boot cpu  would disable all the devices,
re-populate the states and later enable all the devices,
irrespective of the cpu that would receive the notification first.

Reference:
https://lkml.org/lkml/2011/4/25/83Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: NTrinabh Gupta <g.trinabh@gmail.com>
Tested-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: NTrinabh Gupta <g.trinabh@gmail.com>
Tested-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Cpuidle governor only suggests the state to enter using the
governor->select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver and can be accounted
correctly. Current cpuidle code uses last_state field to capture the
actual state entered and based on that updates the statistics for the
state entered.

Ideally the driver enter routine should update the counters,
and it should return the state actually entered rather than the time
spent there. The generic cpuidle code should simply handle where
the counters live in the sysfs namespace, not updating the counters.

Reference:
https://lkml.org/lkml/2011/3/25/52Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: NTrinabh Gupta <g.trinabh@gmail.com>
Tested-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert to use matrix keyboard to remove the warning
"Please update the board to use matrix-keypad driver".

Based on similar setup in palmtc.c. Note that this
patch is compile tested only because of lack of working
hardware.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove the structure since a default one is now available.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The commit 318c3e15
added some "fck" clock alias to timer devices that are
not needed anymore since hwmod framework will create
them automatically.

A warning was added to highlight and thus fix the redundancy.

[    0.616424]  omap_timer.1: alias fck already exists
[    0.621948]  omap_timer.2: alias fck already exists
[    0.627380]  omap_timer.3: alias fck already exists
[    0.632781]  omap_timer.4: alias fck already exists
[    0.638214]  omap_timer.5: alias fck already exists
[    0.643615]  omap_timer.6: alias fck already exists
[    0.649078]  omap_timer.7: alias fck already exists
[    0.654479]  omap_timer.8: alias fck already exists
[    0.659881]  omap_timer.9: alias fck already exists
[    0.665283]  omap_timer.10: alias fck already exists
[    0.670776]  omap_timer.11: alias fck already exists

Remove all the clkdev entries for timer fck alias.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove the init of card detect pin because
omap_mux_init_gpio() is called during hsmmc initialization
for the write protect and card detect pin.
Signed-off-by: NThomas Weber <weber@corscience.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Not in use anymore.
Signed-off-by: NBjarne Steinsbo <bsteinsbo@gmail.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.

Change the functions to return an int, with negative value meaning an
error.

OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
hsmmc code handles the returned value as an int, with negative value
meaning an error, this patch actually fixes hsmmc code also.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: updated to fix a warning with recent dmtimer changes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix the typo, instead it should be SDMMC1
USBC1 is not related to MMC1 I/Os
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator is OFF.
Keep the IO's in power pown mode after regulator OFF otherwise VMODE_ERROR
interrupt is generated due to mismatch in input (regulator)
voltage and MMC IO drive voltage.
Delete incorrect comments which are not applicable for OMAP4.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Reported-by: NViswanath Puttagunta <vishp@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit d6504acd ("OMAP2+: hwmod:
remove OMAP_CHIP*") tests the inverse condition of what it should be
testing for the return value from omap_hwmod_register().  This causes
several IP blocks to not be registered on several OMAP3 family devices.

Fixing that bug also unmasked another bug, originally reported by
Chase Maupin <chase.maupin@ti.com> and then subsequently by Abhilash K
V <abhilash.kv@ti.com>, which caused SmartReflex IP blocks to be
registered on SoCs that don't support them.

Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for comments
on a previous version of the patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Chase Maupin <chase.maupin@ti.com>
Cc: Abhilash K V <abhilash.kv@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Include linux/module.h to fix below build error:

  CC      arch/arm/mach-omap2/omap_l3_noc.o
arch/arm/mach-omap2/omap_l3_noc.c:240: error: expected ',' or ';' before 'MODULE_DEVICE_TABLE'
arch/arm/mach-omap2/omap_l3_noc.c:250: error: 'THIS_MODULE' undeclared here (not in a function)
make[1]: *** [arch/arm/mach-omap2/omap_l3_noc.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit f718e2c0 (ARM: OMAP2+: devices:
Remove all omap_device_pm_latency structures) removed these structures.
Commit 3528c58e (OMAP: omap_device:
when building return platform_device instead of omap_device) now
returns platform_device instead of omap_device.

Fix up the omap-mcpdm init function since this part comes via sound
tree, and there has been changes regarding to hwmod/omap_device_build.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
CC: Benoit Cousson <b-cousson@ti.com>
CC: Kevin Hilman <khilman@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

When customizing omap2plus_defconfig to build for only
one board (omap3evm), I came across these warnings and
errors (filenames truncated):

arch/arm/mach-omap2/board-generic.c:76:20: warning: 'omap4_init' defined but not used
arch/arm/mach-omap2/built-in.o: In function `omap2420_init_early':
arch/arm/mach-omap2/io.c:364: undefined reference to `omap2_set_globals_242x'
arch/arm/mach-omap2/io.c:366: undefined reference to `omap2xxx_voltagedomains_init'
arch/arm/mach-omap2/io.c:367: undefined reference to `omap242x_powerdomains_init'
arch/arm/mach-omap2/io.c:368: undefined reference to `omap242x_clockdomains_init'
arch/arm/mach-omap2/io.c:369: undefined reference to `omap2420_hwmod_init'
arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early':
arch/arm/mach-omap2/io.c:376: undefined reference to `omap2_set_globals_243x'
arch/arm/mach-omap2/io.c:378: undefined reference to `omap2xxx_voltagedomains_init'
arch/arm/mach-omap2/io.c:379: undefined reference to `omap243x_powerdomains_init'
arch/arm/mach-omap2/io.c:380: undefined reference to `omap243x_clockdomains_init'
arch/arm/mach-omap2/io.c:381: undefined reference to `omap2430_hwmod_init'
arch/arm/mach-omap2/built-in.o: In function `omap4430_init_early':
arch/arm/mach-omap2/io.c:436: undefined reference to `omap2_set_globals_443x'
arch/arm/mach-omap2/io.c:438: undefined reference to `omap44xx_voltagedomains_init'
arch/arm/mach-omap2/io.c:439: undefined reference to `omap44xx_powerdomains_init'
arch/arm/mach-omap2/io.c:440: undefined reference to `omap44xx_clockdomains_init'
arch/arm/mach-omap2/io.c:441: undefined reference to `omap44xx_hwmod_init'

This patch fixes them.
Signed-off-by: NSanjeev Premi <premi@ti.com>
Acked-by: NThomas Weber <weber@corscience.de>
[tony@atomide.com: updated to fix warnings for board-generic.c]
Signed-off-by: NTony Lindgren <tony@atomide.com>

These files all make use of one of the EXPORT_SYMBOL variants
or the THIS_MODULE macro.  So they will need <linux/export.h>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

To fix things like this:

arch/arm/mach-omap2/usb-tusb6010.c:58: error: implicit declaration of function 'memset'
arch/arm/kernel/leds.c:40: error: implicit declaration of function 'strcspn'
arch/arm/kernel/leds.c:40: warning: incompatible implicit declaration of built-in function 'strcspn'
arch/arm/kernel/leds.c:45: error: implicit declaration of function 'strncmp'
arch/arm/kernel/leds.c:55: error: implicit declaration of function 'strlen'
arch/arm/kernel/leds.c:55: warning: incompatible implicit declaration of built-in function 'strlen'
arch/arm/mach-omap2/clockdomain.c:52: error: implicit declaration of function 'strcmp'
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

We currently have two symbols to control compilation the MFD subsystem,
MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required
at all, it only hides the submenu when not set, with the effect that
Kconfig warns about missing dependencies when another driver selects
an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu
back from menuconfig into a plain menu simplifies the Kconfig syntax
for those kinds of users and avoids the surprise when the menu
suddenly appears because another driver was enabled that selects this
symbol.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NKyle Manna <kyle@kylemanna.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

PPI handling is a bit of an odd beast. It uses its own low level
handling code and is hardwired to the local timers (hence lacking
a registration interface).

Instead, switch the low handling to the normal SPI handling code.
PPIs are handled by the handle_percpu_devid_irq flow.

This also allows the removal of some duplicated code.

Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: NDavid Brown <davidb@codeaurora.org>
Tested-by: NDavid Brown <davidb@codeaurora.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Rather than clipping the number of CPUs using the compile-time NR_CPUS
constant, use the runtime nr_cpu_ids value instead.  This allows the
nr_cpus command line option to work as expected.

Cc: <stable@kernel.org>
Reported-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We don't have cpu_is_omapxxxx SoC detection initialized until
SoC detection is initialized from init_early.

Note that with the common map_io we should no longer need
cpu_is_omapxxxx for ioremap.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This allows us to remove omap hacks for map_io.
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This way we don't need to initialize SoC detection early
and can start using generic map_io.
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Boards used to specify zreladdr in their Makefile.boot with
zreladdr-y := x, so conflicting zreladdrs were silently overwritten.
This patch changes this to zreladdr-y += x, so that we end
up with multiple words in zreladdr in such a case. We can
detect this later and complain if necessary.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Based on the documents that I have here, there doesn't appear to be an
equivalent to erratum i443 for OMAP3630, so restrict this one to OMAP34xx
chips.

Also, explicitly restrict this erratum to EMU and HS devices.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The way that we detect which OMAP3 chips support I/O wakeup and
software I/O chain clock control is broken.

Currently, I/O wakeup is marked as present for all OMAP3 SoCs other
than the AM3505/3517.  The TI81xx family of SoCs are at present
considered to be OMAP3 SoCs, but don't support I/O wakeup.  To resolve
this, convert the existing blacklist approach to an explicit,
whitelist support, in which only SoCs which are known to support I/O
wakeup are listed.  (At present, this only includes OMAP34xx,
OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.)

Also, the current code incorrectly detects the presence of a
software-controllable I/O chain clock on several chips that don't
support it.  This results in writes to reserved bitfields, unnecessary
delays, and console messages on kernels running on those chips:

    http://www.spinics.net/lists/linux-omap/msg58735.html

Convert this test to a feature test with a chip-by-chip whitelist.

Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem
and doing some testing to help isolate the cause.  Thanks to Steve
Sakoman <sakoman@gmail.com> for catching a bug in the first version of
this patch.  Thanks to Russell King <linux@arm.linux.org.uk> for
comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Tested-by: NSteve Sakoman <sakoman@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The context lost count is modified in omap_sram_idle() path when
pwrdm_post_transition() is called. But pwrdm_post_transition() is called
only after omap_gpio_resume_after_idle() is called. Correct this so that
context lost count is modified before calling omap_gpio_resume_after_idle().

This would be useful when OMAP GPIO save/restore context is called by
the OMAP GPIO driver itself.
Signed-off-by: NCharulatha V <charu@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.  This removes quite a few warnings on boot for AM35x.
Signed-off-by: NAbhilash K V <abhilash.kv@ti.com>
[paul@pwsan.com: dropped 'mailbox class' comments; updated changelog]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Fix the shift and mask macros for DSIx_PPID fields in CONTROL_DSIPHY. The
OMAP4430 Public TRM vV has these fields mentioned correctly.
Signed-off-by: NArchit Taneja <archit@ti.com>
Acked-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check for the correct frequency ranges
for OMAP36xx and OMAP4xxx.

For OMAP36xx and OMAP4xxx devices, DPLLs fint range is 0.5MHz to
2.5MHz for j-type DPLLs and otherwise it is 32KHz to 52MHz for all
other DPLLs.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...

ABE_FCLK --> AESS_FCLK --> OCP_ABE_ICLK

The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
determine their operational frequency. However, the dividers for
the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
which is the CM1_ABE_AESS_CLKCTRL[24] bit. When this bit is set to
0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
and the OCP_ABE_ICLK is 1.

The above relationship between the AESS_FCLK and OCP_ABE_ICLK
dividers ensure that the OCP_ABE_ICLK clock is always half the
frequency of the ABE_CLK...

OCP_ABE_ICLK = ABE_FCLK/2

The divider for the OCP_ABE_ICLK is currently missing so add a
divider that will ensure the OCP_ABE_ICLK frequency is always half
the ABE_FCLK frequency.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP4460 specific clocks are not getting added as the
cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes.
Changing it to add to OMAP4460 specific clocks also.
This is clocks are required of temperature sensor.
Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Cc: paul@pwsan.com
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This is a continuation of Mike Turquette's patch "OMAP3+: use
DPLL's round_rate when setting rate".

omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function and so use the DPLLs recalc()
function pointer instead.

An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
in addition to the usual MN multipler and dividers and therefore
uses a different round_rate and recalc function.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Cc: Mike Turquette <mturquette@ti.com>
Cc: Misael Lopez Cruz <misael.lopez@ti.com>
[paul@pwsan.com: merged this patch with Mike's "use clock's recalc in DPLL
 handling" patch; also reported by Misael]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The rounded rate can differ from target rate, so to better reflect
reality set clk->rate equal to the rounded rate when setting DPLL frequency.
This avoids issues where the DPLL frequency is slightly different than what
debugfs clock tree reports using the old target rate.

An example of a clock that requires this is DPLL_ABE on OMAP4 which
can have a 4x multiplier on top of the usual MN dividers depending on
register settings.  This requires a special round_rate function that
might yield a rate different from the initial target.
Signed-off-by: NMike Turquette <mturquette@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly.  Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.

An example of a clock that requires this is DPLL_ABE on OMAP4 which
can have a 4x multiplier on top of the usual MN dividers depending on
register settings.  This requires a special round_rate function that
might yield a rate different from the initial target.
Signed-off-by: NMike Turquette <mturquette@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: split rate assignment portion into a separate patch]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
bit in CKGEN module of CM1. From the OMAP4 TRM:

Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
applicable to DPLL_ABE).

Add new round_rate() and recalc() functions for OMAP4, that check the
setting of REGM4XEN bit and handle this appropriately. The new functions
are a simple wrapper on top of the existing omap2_dpll_round_rate() and
omap2_dpll_get_rate() functions to handle the REGM4XEN bit.

The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
omap4_dpll_regm4xen_recalc() functions.
Signed-off-by: NMike Turquette <mturquette@ti.com>
Tested-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed attempt to return a negative from a fn returning
		 unsigned; pass along errors from omap2_dpll_round_rate();
		 added documentation; added Jon's S-o-b]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add nodes for devices used by PM code (mpu, dsp, iva).

Add a cpus node as well as recommended in the DT spec.

Remove mpu, dsp, iva devices init if is populated.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Kevin Hilman <khilman@ti.com>