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>

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>

Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

Add device-tree support for the l3-noc driver.

Use platform_driver_register to defer the probing at device init
time.

Add documentation for the l3-noc bindings.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

Still needed to boot until the i2c & twl driver is adapted to
device-tree. Otherwise the voltage control code will try to
access the twl and crash.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

Re-cycle the original board-generic.c file to support Device Tree
for every OMAP2+ variants.

The current approach is an intermediate step before having only
one machine descriptor that will use some generic DT aware
functions.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

Remove all these duplicated structures since a default one is now
available.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Since the device pointer is now retrieved using the hwmod name, remove
the static variables used to store the device pointers for DSP, MPU, IVA
and L3 devices for PM/DVFS usage.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Replace the struct device parameter of omap2_set_init_voltage
by the hwmod name. It will avoid having to store explicitely
the device pointer into a static variable.

Moreover, it will be a little bit more scalable if we introduce
new DVFS devices.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Replace the multiple omap2_get_XXX_device APIs with the new
omap_hwmod_name_get_dev that uses the hwmod name to get the proper
device.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Fixes bug where variable i was redundantly used for counting two nested loops.
Signed-off-by: NTapani Utriainen <tapani@technexion.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

`keypad_pads' is referred to by `keypad_data' which is
not __initdata, so `keypad_pads' should not be __initdata either.
Signed-off-by: NBjarne Steinsbo <bsteinsbo@gmail.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Support for the cpu_suspend functions is only built-in
when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4
and pxa always call cpu_suspend when CONFIG_PM is enabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Current code calls omap4430_phy_init() twice in usb_musb_init().
Calling omap4430_phy_init() once is enough.
This patch removes the first omap4430_phy_init() call, which using an
uninitialized pointer as parameter.

This patch elimates below build warning:
arch/arm/mach-omap2/usb-musb.c: In function 'usb_musb_init':
arch/arm/mach-omap2/usb-musb.c:141: warning: 'dev' may be used uninitialized in this function
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Bjarne Steinsbo <bsteinsbo@gmail.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Looks like 2600 kHz rate does not work reliably on 2430,
so just use the 100 kHz rate.

Otherwise the system often fails to boot properly with:

omap_i2c omap_i2c.2: timeout waiting for bus ready
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
twl: clock init err [-110]
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
TWL4030 Unable to unlock IDCODE registers --110
Signed-off-by: NTony Lindgren <tony@atomide.com>