This way we can remove includes of plat/gpio.h which won't work
with the single zImage support.

Note that we also remove the cpu_class_is_omap2() check
in gpio-omap.c as the drivers should not call it as we need to
make it local to arch/arm/mach-omap2 for single zImage support.

While at it, arrange the related includes in the standard way.

Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-mtd@lists.infradead.org
Cc: alsa-devel@alsa-project.org
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This reverts commit 58f0829b.

Converstion to per-pwrdm per/post transition calls was a bit
premature.  Only tracking MPU, PER & CORE in the idle path means we
lose the accounting for all the other powerdomains which may also
transition in idle.  On OMAP3, due to autodeps, several powerdomains
transition along with MPU (e.g. DSS, USBHOST), and the accounting for
these was lost with this patch.  Since the accounting includes the
context loss counters, drivers for devices in those power domains
would never notice context lost, so would likely hang after any
off-mode transitions.

This patch should be revisited when the upcoming clkdm/pwrmdm/voltdm
use-counting seires is merged since then we can properly do accounting
without relying on a call in the idle path.

In addition, the original patch had another bug because the PER
powerdomain accounting was not updated until after the GPIO resume
hook is called.  Since gpio_resume_after_idle() checks the context
loss count (which is not yet updated) it would not properly restore
context, leaving the GPIO banks in an undefined state.

Cc: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reported-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

commit e7410cf7 (OMAP3: PM: move device-specific special cases from PM
core into CPUidle) moved mangement of cam_pwrdm to CPUidle but left
some remnants behind, namely the call to clkcm_allo_idle() for the
clockdomains in the MPU pwrdm.  Remove these since they are not
necessary and cause unwanted latency in the idle path.
Acked-by: NTero Kristo &lt;Tero Kristo <t-kristo@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

We only need to call the pre/post transtion methods when we know the
power state is changing.  First, split up the pre/post transition
calls to be per-powerdomain, and then make them conditional on whether
the power domain is actually changing states.
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Iteration over all power domains in the idle path is unnecessary since
only power domains that are transitioning need to be accounted for.
Also PRCM register accesses are known to be expensive, so the
additional latency added to the idle path is signficiant.

In order allow the pre/post transitions to be isolated and called
per-pwrdm, change the API so passing in a specific power domain will
trigger the pre/post transtion accounting for only that specific power
domain.  Passing NULL means iterating over all power domains as is
current behavior.
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.

Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.

Thanks to Nishanth Menon <nm@ti.com> for contributing a fix to the
timeout code waiting for WUCLKOUT to go high.
Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: renamed omap3_trigger_io_chain() to better describe the
 end result and to match other PRM functions; removed
 omap3_disable_io_chain(); moved MAX_IOPAD_LATCH_TIME to prcm-common as it
 will also be used by the OMAP4 code; removed unnecessary barrier;
 added kerneldoc; added credit for fix from Nishanth]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain, based loosely on the "Sec 3.5.7.2.2
I/O Wake-Up Mechanism" section in OMAP3630 Public TRM[1].

Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.

Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.

Step [e] & [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.

[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zipSigned-off-by: NMohan V <mohanv@ti.com>
Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
[paul@pwsan.com: modified commit message to clarify that these steps are
 based loosely on the TRM section, rather than documented exactly]
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: resolved new warnings from checkpatch]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

prcm_setup_regs() blindly accesses IVA bits
in the PRM and calls omap3_iva_idle() which
does more IVA related register accesses.
Only do this if the IVA hardware actually
exists.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

By default, request_irq() will auto-enable the requested IRQ.

For PRCM interrupts, we may want to avoid that until the PM core code
is fully ready to handle the interrupts.  This is particularily true
for IO pad interrupts on OMAP3, which are shared between the hwmod
core and the PRM core.

In order to avoid PRCM IO-chain interrupts until the PM core is ready
to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain
interrupt,  which means it will remain disabled after request_irq().

Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)

Special thanks to Tero Kristo for suggesting to isolate the fix to
only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts.

Cc: Tero Kristo <t-kristo@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>

Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:

    [arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
    [arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
    [arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
    [arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
    [arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
    [arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
    [arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
    [arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
    [arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
    [arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
    [arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
    [arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
    [arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
    [arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
    [arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
    [arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used

Some of them are pretty good catches, such as gpio.c:56 and
usb-tusb6010.c:129.

Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
It seems that the kernel sscanf() ignores the field width anyway for the
%d format, so those changes have been dropped from this second version.

Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
out that a variable was unnecessarily marked static in the
board-omap3evm.c change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Charulatha Varadarajan <charu@ti.com>
Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c

Disintegrate asm/system.h for ARM.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Russell King <linux@arm.linux.org.uk>
cc: linux-arm-kernel@lists.infradead.org

Currently, pm34xx.c has a mix of printk() and pr_*() statements
so replace the printk() statements with the equivalent pr_*()
statements.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

It appears that the error paths were overlooked when the
omap3_pm_init() routine had the prcm chain handler code
added.  Fix this by adding a goto target and reordering
the error handling code.  Also fix how the irq argument
for free_irq() is determined.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The platform_suspend_ops can be shared across OMAP2, 3, and 4, along
with all of the functions referenced in that structure.  This patch
shares them.  It also removes the suspend_state file-scoped variable
in the OMAP2 and 3 PM code; it does not appear to be actually needed
by anything.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
[khilman@ti.com: minor rework needed due to rebase/merge with conflicting changes]
Signed-off-by: NKevin Hilman <khilman@ti.com>

clkdms_setup() is identical across OMAP2, 3, and 4, so share it.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Remove some superfluous calls to pwrdm_clear_all_prev_pwrst().
pwrdm_pre_transition(), which appears a few lines after these calls,
invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no
need to do it twice.

N.B.: some of us have observed that accesses to the previous
powerstate registers seem to be quite slow.  Although the writes
removed by this patch should be buffered by the write buffer, there is
a read to a PRM register immediately afterwards.  That will block the
OMAP3 MPU until all of those writes complete.  So this patch should
result in a minor performance improvement during idle entry.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NTero Kristo <t-kristo@ti.com>
[khilman@ti.com: removed a couple more for OMAP4]
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Modify omap_gpio_prepare_for_idle() & omap_gpio_resume_after_idle() functions
to handle save context & restore context respectively in the OMAP GPIO driver
itself instead of calling these functions from pm specific files.
For this, in gpio_prepare_for_idle(), call *_get_context_loss_count() and in
gpio_resume_after_idle() call it again. If the count is different, do restore
context.
Signed-off-by: NCharulatha V <charu@ti.com>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Signed-off-by: NNicolas Pitre <nico@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>

PM interrupt handling is now done through the PRCM chain handler. The
interrupt handling logic is also split in two parts, to serve IO and
WKUP events separately. This allows us to handle IO chain events in a
clean way.

Core event code is also changed in accordance to this, as PRCM
interrupt handling is done by independent handlers, and the core
handler should not clear the IO events anymore.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: use pr_err(); combined with portions of earlier patches and
 the "do not enable PRCM MPU interrupts manually" patch]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Omap_uart_can_sleep function blocks system wide low power state until
uart is active remove this func and add qos requests to prevent
MPU from transitioning.

Keep qos request to default value which will allow MPU to transition
and while uart baud rate is available calculate the latency value
from the baudrate and use the same to hold constraint while uart clocks
are enabled, and if uart is auto-idled the constraint is updated with
default constraint value allowing MPU to transition.

Qos requests are blocking notifier calls so put these requests to
work queue, also the driver uses irq_safe version of runtime API's
and callbacks can be called in interrupt disabled context.
So to avoid warn on slow path warning while using qos update
API's from runtime callbacks use the qos_work_queue.

During bootup the runtime_resume call backs might not be called and runtime
callback gets called only after uart is idled by setting the autosuspend
timeout. So qos_request from runtime resume callback might not activated during
boot if uart baudrate is calculated during bootup for console uart, so schedule
the qos_work queue once we calc_latency while configuring the uart port.

Flush and complete any pending qos jobs in work queue while suspending.
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
Signed-off-by: NKevin Hilman <khilman@ti.com>

In preparation to UART runtime conversion remove uart specific calls
from pm24xx/34xx files and their definition from serial.c
These func calls will no more be used with upcoming uart runtime design.

1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks.
2.) omap_uart_enable_irqs :- Used to enable/disable uart irq's in suspend
    path from PM code, this is removed as same is handled by
    uart_suspend_port/uart_resume_port in omap-serial driver which will
    do an port_shutdown on suspend freeing irq and port_startup on resume
    enabling back irq.
3.) Remove prepare_idle/resume_idle calls used to gate uart clocks.
    UART clocks can be gated within driver using runtime funcs
    and be woken up using irq_chaining from omap_prm driver.
4.) Remove console_locking from idle path as clock gating is done withing
    driver itself with runtime API. Remove is_suspending check used to acquire
    console_lock.
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>,
there's no need to keep local prototypes in non-local headers.

Add mach-omap1/common.h and mach-omap2/common.h and move the
local prototypes there from plat/common.h and mach/omap4-common.h.
Signed-off-by: NTony Lindgren <tony@atomide.com>
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>

During the idle/suspend path, we expect the console lock to be held so
that no console output is done during/after the UARTs are idled.

However, when using the no_console_suspend argument on the
command-line, the console driver does not take the console lock.  This
allows the possibility of console activity after UARTs have been
disabled.

To fix, update the current is_suspending() to also check the
console_suspend_enabled flag.
Reported-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

There are SoCs where attempting to enter a low power state is ignored,
and the CPU continues executing instructions with all state preserved.
It is over-complex at that point to disable the MMU just to call the
resume path.

Instead, allow the suspend finisher to return error codes to abort
suspend in this circumstance, where the cpu_suspend internals will then
unwind the saved state on the stack.  Also omit the tlb flush as no
changes to the page tables will have happened.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move the saving of the auxiliary control registers into C; there's
no need for this to be in assembly code.  This results in less
assembly code to deal with in OMAP.

Kevin tested full-chip retention and off on 3430/n900, 3530/Overo and
3630/Zoom3.
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF
mode.  However only a small part of the code really needs to run from
internal SRAM.

This fix lets most of the ASM idle code run from the DDR in order to
minimize the SRAM usage and the overhead in the code copy.

The only pieces of code that are mandatory in SRAM are:
- the i443 erratum WA,
- the i581 erratum WA,
- the security extension code.

SRAM usage:
- original code:
  . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
  . 852 bytes for omap_sram_idle (used by suspend/resume in RETention),
  . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x),
  . 108 bytes for save_secure_ram_context (used on HS parts only).

With this fix the usage for suspend/resume in RETention goes down 288
bytes, so the gain in SRAM usage for suspend/resume is 564 bytes.

Also fixed the SRAM initialization sequence to avoid an unnecessary
copy to SRAM at boot time and for readability.

Tested on Beagleboard (ES2.x) in idle with full RET and OFF modes.

Kevin Hilman tested retention and off on 3430/n900, 3530/Overo and
3630/Zoom3
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The first and second arguments shouldn't concern platform code, so
hide them from each platforms caller.
Tested-by: NKevin Hilman <khilman@ti.com>
Acked-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Convert omap34xx to use the generic CPU suspend/resume support, rather
than implementing its own version.  Tested on 3430 LDP.
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Acked-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is
currently available as an OMAP-specific debugfs entry.

This duplicates existing ARM-generic functionality available as a
boot-time option using the boot cmdline option 'hohlt'.

If runtime configuration of this is needed, then adding a debugfs
entry for the ARM-generic hlt/nohlt interface should be added.
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

This removes the support for setting the wake-up timer for debugging.

Later on we can reserve gptimer1 for PM code only and have similar
functionality.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>

It shows up on the console despite using "silent" in the bootargs, and
it's really just noise in the boot log since PM init is always called.
Signed-off-by: NSanjeev Premi <premi@ti.com>
Cc: jhnikula@gmail.com
[khilman@ti.com: minor changelog edits]
Signed-off-by: NKevin Hilman <khilman@ti.com>

The achievable power modes of the power domains in cpuidle
depends on the system wide 'enable_off_mode' knob in debugfs.
Upon changing enable_off_mode, do not change the C-states
'valid' field but instead dynamically restrict the power modes
when entering idle.

The C-states 'valid' field is just used to enable/disable some
C-states at init and shall not be changed later on.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The patch adds the new power management trace points for
the OMAP architecture.

The trace points are for:
- default idle handler. Since the cpuidle framework is
  instrumented in the generic way there is no need to
  add trace points in the OMAP specific cpuidle handler;
- SoC clocks changes (enable, disable, set_rate),
- power domain states: the desired target state and -if different-
  the actually hit state.

Because of the generic nature of the changes, OMAP3 and OMAP4 are supported.

Tested on OMAP3 with suspend/resume, cpuidle, basic DVFS.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Remove the custom restore_control_register() and use the exported
set_cr() instead to set the system control register(SCTRL) value.

No functional change.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The OMAP2 and OMAP3 PM code clears clockdomain wakeup and sleep
dependencies.  This is unnecessary after commit
6f7f63cc ("OMAP clockdomain:
initialize clockdomain registers when the clockdomain layer starts")
which clears these dependencies during clockdomain init.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>