OMAP5: Init sram from omap_sdrc_init like other archs

_omap2_map_common_io has been deprecated upstream by patch
   a66cb345 "ARM: OMAP: Map SRAM later on with ioremap_exec()"
Make OMAP5 toe the same line.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set

During system suspend, when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set on
an omap_device, call the corresponding driver's ->suspend() and
->suspend_noirq() callbacks (if present).  Similarly, during resume,
the driver's ->resume() and ->resume_noirq() callbacks must both be
called, if present.  (The previous code only called ->suspend_noirq()
and ->resume_noirq().)

If all of these callbacks aren't called, some important driver
suspend/resume code may not get executed.

In current mainline, the bug fixed by this patch is only a problem
under the following conditions:

- the kernel is running on an OMAP4

- an OMAP UART is used as a console

- the kernel command line parameter 'no_console_suspend' is specified

- and the system enters suspend ("echo mem > /sys/power/state").

Under this combined circumstance, the system cannot be awakened via
the serial port after commit be4b0281956c5cae4f63f31f11d07625a6988766c
("tty: serial: OMAP: block idle while the UART is transferring data in
PIO mode").  This is because the OMAP UART driver's ->suspend()
callback is never called.  The ->suspend() callback would have called
uart_suspend_port() which in turn would call enable_irq_wake().  Since
enable_irq_wake() isn't called for the UART's IRQ, check_wakeup_irqs()
would mask off the UART IRQ in the GIC.

On v3.3 kernels prior to the above commit, serial resume from suspend
presumably occurred via the PRCM interrupt.  The UART was in
smart-idle mode, so it was able to send a PRCM wakeup which in turn
would be converted into a PRCM interrupt to the GIC, waking up the
kernel.  But after the above commit, when the system is suspended in
the middle of a UART transmit, the UART IP block would be in no-idle
mode.  In no-idle mode, the UART won't generate wakeups to the PRCM
when incoming characters are received; only GIC interrupts.  But since
the UART driver's ->suspend() callback is never called,
uart_suspend_port() and enable_irq_wake() is never called; so the UART
interrupt is masked by check_wakeup_irqs() and the UART can't wake up
the MPU.

The remaining mechanism that could have awakened the system would have
been I/O chain wakeups.  These wouldn't be active because the console
UART's clocks are never disabled when no_console_suspend is used,
preventing the full chip from idling.  Also, current mainline doesn't
yet support full chip idle states for OMAP4, so I/O chain wakeups are
not enabled.

This patch is the result of a collaboration.  John Stultz
<johnstul@us.ibm.com> and Andy Green <andy.green@linaro.org> reported
the serial wakeup problem that led to the discovery of this problem.
Kevin Hilman <khilman@ti.com> narrowed the problem down to the use of
no_console_suspend.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Andy Green <andy.green@linaro.org>
Cc: Kevin Hilman <khilman@ti.com>
omap4plus scm stop crash on suspend

Signed-off-by: Andy Green <andy.green@linaro.org>
ti st kim stop crash on suspend

Signed-off-by: Andy Green <andy.green@linaro.org>
mux BUG if we cant find ball mode

Signed-off-by: Andy Green <andy.green@linaro.org>
OMAP5 ES1.0 needs cold reset to restart

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
config 5432

Signed-off-by: Andy Green <andy.green@linaro.org>
Remove ghost copy of omap2plus-cpufreq.c

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Rename 443x specific data as such

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Add the missing volt_data for 4430 at 300MHz

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
omap4 clocks detect clock rounding error

Signed-off-by: Andy Green <andy.green@linaro.org>
omap2plus clock fix dcc error path and solve random crashes

This corrects dcc state if there is an error in dpll_set_rate.

It also migrates dcc setting to AFTER clock setting on >1GHz case.

This is necessary to stop random crashes when cpufreq does this code.

Signed-off-by: Andy Green <andy.green@linaro.org>
omap4460: Fix core domain frequency

Signed-off-by: Sebastien Jan <s-jan@ti.com>
omap4430: disable OPP50 support for core and iva

Prevent core and iva voltage domains from scaling (they will remain
in OPP100).
This will prevent borders effects while constrains and notification
frameworks are not in place (ex: avoid scaling down core if an high
L3 bdw is requried).

MPU can still scale, which is sufficient for thermal considerations.
But SGX, IVA, Ducati and L3 won't scale anymore and stay at OPP100.

Signed-off-by: Sebastien Jan <s-jan@ti.com>
omap4 clocks allow 1MHz leeway

With smartreflex(?) pll settings no long always match exactly
this allows match on up to 1MHz lower frequency.

Signed-off-by: Andy Green <andy.green@linaro.org>
Improve DPLL frequency rounding code

Maintain a list of successful frequency translations for any given DPLL.
Speed up frequency calculations by searching the cache first.
Do a more exhaustive search for the best possible DPLL paramters for a
new frequency.
If an exact fit is not found, return the best possible match within jitter
constraints.
Change the worst case match criteria from +/-1MHZ to +/-0.01% (on the 4460
350MHz will be off by 0.003%).

Signed-off-by: David A. Long <dave.long@linaro.org>
opp 446x cleanup

Signed-off-by: Jaswinder Singh <jaswinder.singh@linaro.org>
omap id recognize 4460 es1.1

Signed-off-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Chris Lalancette <clalancette@gmail.com>
OMAP4: Adding ID for OMAP4460 ES1.1

Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@linaro.org>
Signed-off-by: Chris Lalancette <clalancette@gmail.com>
OMAP4460: L2X0: Temporary work-around for stability.

OMAP4460 ES1.0 seems to suffer from stability with L2 cache enabled.
The root-cause analysis is ongoing but in meantime this chabe is
to enable a software WA with L2 cache enabled build. The WA consist
of locking certain cache ways based on their positions on the
physical memory layout.

Downside of this WA is that effective L2 cache size will be 512 KB
instead of 1 MB.

Of course this is temporary WA and needs to removed once the root
cause and the right fix is found.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>