Commit 32518852 ("ARM: OMAP4+: Reset CPU1 properly for kexec") started
unconditionally resetting CPU1 because of a kexec boot issue I was seeing
earlier on omap4 when doing kexec boot between two different kernel
versions.

This caused issues on some systems. We should only reset CPU1 as a last
resort option, and try to avoid it where possible. Doing an unconditional
CPU1 reset causes issues for example when booting a bootloader configured
secure OS running on CPU1 as reported by Andrew F. Davis <afd@ti.com>.

We can't completely remove the reset of CPU1 as it would break kexec
booting from older kernels. But we can limit the CPU1 reset to cases
where CPU1 is wrongly parked within the memory area used by the booting
kernel. Then later on we can add support for parking CPU1 for kexec out
of the SDRAM back to bootrom.

So let's first fix the regression reported by Andrew by making CPU1 reset
conditional. To do this, we need to:

1. Save configured AUX_CORE_BOOT_1 for later

2. Modify AUX_CORE_BOOT_0 reading code to for HS SoCs to return
   the whole register instead of the CPU mask

3. Check if CPU1 is wrongly parked into the booting kernel by the
   previous kernel and reset if needed

Fixes: 32518852 ("ARM: OMAP4+: Reset CPU1 properly for kexec")
Reported-by: NAndrew F. Davis <afd@ti.com>
Cc: Andrew F. Davis <afd@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Tested-by: NAndrew F. Davis <afd@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

All the boards booting with device tree use
drivers/pinctrl-single.c instead.

Note that mach-omap1 is still using the legacy mux,
so let's move the related Kconfig options from plat-omap
to mach-omap1.
Signed-off-by: NTony Lindgren <tony@atomide.com>

The function is empty, remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We need to properly initialize mpuss also on omap5 like we do on omap4.
Otherwise we run into similar kexec problems like we had on omap4 when
trying to kexec from a kernel with PM initialized.

Fixes: 0573b957 ("ARM: OMAP4+: Prevent CPU1 related hang with kexec")
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Kexec needs omap4_cpu_kill, otherwise kexec will produce on SMP:

kexec_load failed: Invalid argument
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Kexec booted kernels on omap4 will hang early during the boot if the
booted kernel is different version from the previous kernel.

This is because the previous kernel may have configured low-power mode
using CPU1_WAKEUP_NS_PA_ADDR. In that case it points to the previous
kernel's omap4_secondary_startup(), and CPU1 can be in low power mode
from the previous kernel. When the new kernel configures the CPU1
clockdomain, CPU1 can wake from low power state prematurely during
omap44xx_clockdomains_init() running random code.

Let's fix the issue by configuring CPU1_WAKEUP_NS_PA_ADDR before we
call omap44xx_clockdomains_init(). Note that this is very early during
the init, and we will do proper CPU1 reset during SMP init a bit later
on in omap4_smp_prepare_cpus(). And we need to do this when SMP is
not enabled as the previous kernel may have had it enabled.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Prepare things for making kexec work on SMP omap variants by initializing
SARM RAM base early. This allows us to configure CPU1 for kexec in case
the previous kernel has put CPU1 in low power mode.

Note that this should not prevent moving other SAR RAM code to live
under drivers. However for kexec, we will need this very early.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These smp_operations structures are not over-written, so add "const"
qualifier and replace __initdata with __initconst.

Also, add "static" where it is possible.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NMoritz Fischer <moritz.fischer@ettus.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org> # qcom part
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NPatrice Chotard <patrice.chotard@st.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NWei Xu <xuwei5@hisilicon.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Acked-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NShawn Guo <shawnguo@kernel.org>
Acked-by: NMatthias Brugger <matthias.bgg@gmail.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

this function is not only about the 32k sync
timer, it's OMAP's generic init_time implementation.

Let's rename it to make that detail easier to
notice.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

instead of constantly defining a small wrapper
around __omap_sync32k_timer_init(), let's define
a generic one which can be used by all OMAPs.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Restore the OMAP4 barrier behaviour using the new implementation which
allows multiplatform systems to hook into the mb() and wmb() ARM
implementations to perform any necessary additional barrier maintanence.
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NRichard Woodruff <r-woodruff2@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This reverts commit 606da482.

We actually need this code for proper behaviour of OMAP4, and it needs
fixing a different way other than just removing the code.  Disabling
code which is necessary in the hopes of persuing multiplatform kernels
is a stupid approach.
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NRichard Woodruff <r-woodruff2@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

DRA7 uses OMAP5 IO table at the moment. This is purely spurious since
the OMAP5 and DRA7 register maps are different in many aspects.

AM57xx/DRA7 TRM Reference: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf

NOTE: Most of the drivers are already doing ioremap, so, there should'nt
be any functional improvement involved here, other than making the
initial iotable more accurate.

Fixes: a3a9384a ("ARM: DRA7: Reuse io tables and add a new .init_early")
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
contradiction in it's dependencies.
The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
enabled. These options inherit a dependency from an enclosing menu,
that requires ARCH_MULTIPLATFORM to be 'enabled'.
This is a contradiction and made this option also unavailable for
non-multiplatform configurations.

Since there are no selects on OMAP4_ERRATA_I688, which would ignore
dependencies, the code related to that option is dead and can be
removed.

This (logical) defect has been found with the undertaker tool.
(https://undertaker.cs.fau.de)
Signed-off-by: NStefan Hengelein <stefan.hengelein@fau.de>
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain")
changed the GIC driver to use a non-legacy IRQ domain on DT
platforms. This patch assumes that DT-driven systems are getting
all of their interrupts from device tree.

Turns out that OMAP has quite a few hidden gems, and still uses
hardcoded interrupts despite having fairly complete DTs.

This patch attempts to work around these by offering a translation
method that can be called directly from the hwmod code, if present.
The same hack is sprinkled over PRCM and TWL.

It isn't pretty, but it seems to do the job without having to add
more hacks to the interrupt controller code.

Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: updated to fix make randconfig issue]
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch implements generic DT L2C initialisation (the one from
init_IRQ in arch/arm/kernel/irq.c) for Omap4 and AM43 platforms and
kills the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We are missing proper hooks for 81xx for reboot to work.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise it will return true for cpu_is_omap34xx() which we don't
want for the clocks and hwmod. It's closer to am33xx for the clocks
and hwmod than to the omap34xx. We also want to be able to detect
814x and 816x separately as at least the clocks are different with
814x using a apll and 816x using a fapll for the source clocks.

Note that we can also remove omap3xxx_clk_init() call as it's wrong
and ti81xx are booting in device tree only mode.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If the boot loader enables HYP mode on the boot CPU, the secondary CPU
also needs to call into the ROM to switch to HYP mode before booting.
The firmwares on the omap5 and dra7xx unfortunately do not take care
of this, so it has to be handled by the kernel.

This patch is based on "[PATCH 2/2] ARM: OMAP5: Add HYP mode entry support
for secondary CPUs" by Santosh Shilimkar <santosh.shilimkar@ti.com>,
except this version does not require a compile time CONFIG to control
if it should enable HYP mode or not, it simply does it based on the mode
of the boot CPU, so it works whether the CPU boots in SVC or HYP mode,
and should even work as a guest kernel inside kvm if qemu decides to
support emulating the omap5 or dra7xx.

Cc: stable@vger.kernel.org #v3.16+
Signed-off-by: NLen Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP INTC irqchip driver will be moved under
drivers/irqchip/ soon but we still have a dependency
with mach-omap2 when it comes to idle functions.

In order to make it easy to share those function
prototypes with OMAP PM code, we introduce this new
header.

To avoid modifying several board-files and some of
the PM-related code, we just include the new header
from common.h which was already included by all
users of IRQ-related PM code.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

that was just a no-op wrapper around omap_intc_handle_irq
anyway.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

now that we're calling set_handle_irq() from
init_irq(), we can safely drop all callers to
omap3_intc_handle_irq() and its definition.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

now we can safely drop those fields from our machine_desc.

While at that, also drop the now unused omap_intc_of_init()
definition.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

nobody uses that function outside of this file,
so we don't need to expose it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

of_device_ids (i.e. compatible strings and the respective data) are not
supposed to change at runtime. All functions working with of_device_ids
provided by <linux/of.h> work with const of_device_ids. So mark the
non-const function parameters and structs for OMAP2+ as const, too.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With consolidated code, now we can add the required hooks for
DRA7 to enable power management.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[nm@ti.com: minor modifications]
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With consolidated code, now we can add the required hooks for
OMAP5 to enable power management.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[nm@ti.com: minor rebase updates]
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>

omap44xx_restart is defined as a static void inline when DRA7/AM437X is
defined alone, which implies that the restart function is no longer
functional even though it is built in. So, fix the definition of the
same.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit d941f86f ("ARM: l2c: AM43x: add L2 cache support") enabled
the L2 cache support for the am43xx SoC, but caused a build regression
when the driver for that cache controller is disabled:

arch/arm/mach-omap2/built-in.o: In function `am43xx_init_early':
:(.init.text+0xb20): undefined reference to `omap_l2_cache_init'

This did not happen for OMAP4, which has the same call, but enables
the l2x0 driver unconditionally. We could do the same thing for
am43xx, but it seems better to allow turning it off and make the
code work in either case.

This adds an inline wrapper for omap_l2_cache_init for the disabled
case, and removes the 'select' from OMAP4 so it becomes a user
visible option.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org

gic_init_irq() is no longer used as of:

    commit b42b9181
    Author: Tony Lindgren <tony@atomide.com>
    Date:   Thu May 30 12:53:05 2013 -0700

        ARM: OMAP2+: Remove board-omap4panda.c

Drop it.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

Get rid of init call to initialize L2 cache.  Instead use the init_early
machine hook. This helps in using the initialization routine across
SoCs without the need of ugly cpu_is_*() checks.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As there is no common panel framework in the kernel, we have OMAP
specific panel drivers. However, the DT data should be generic. This
brings the issue that some other platform could use the same panels, and
would need to create a driver with the same 'compatible' string as the
OMAP driver.

In the long run, we have to get a common panel framework. For the time
being, this patch solves the issue:

At early boot time, we go through the DT nodes looking for the panels
the kernel supports for OMAP. For each found node, the 'compatible'
string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
"omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
at the beginning of their compatible field.

This allows us to have generic DT data, but OMAP specific display
drivers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The OMAP display architecture requires a bunch of platform devices which
are not created via .dts (for now). We also need to pass a few function
pointers and the DSS hardware version from the arch code to omapdss
driver.

This patch adds omapdss_init_of() function, called from board-generic at
init time, which handles those tasks.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Move all OMAP4 PM errata initializations to centralized location in
omap4_pm_init_early. This allows for users to utilize the erratas
in various submodules as needed.
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The same workaround as ff999b8a
"ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..."
need to be applied not only when system is booting, but when MPUSS hits
OSWR state through CPUIdle too. Without this WA the same issue is
reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460
when CONFIG_CPU_IDLE is enabled.
After MPUSS has enterred OSWR and waken up:
- GIC distributor became disabled forever
- scheduling is not performed any more

Cc: Kevin Hilman <khilman@linaro.org>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reported-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

clk_init is now separated to a common function which gets called for all
SoC:s, which initializes the DT clocks and calls the SoC specific clock init.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

As we currently need to support a mix of legacy platform data and
device tree intialized data, let's make sure things keep working
for the TWL GPIOs.

Mostly the issue is caused by the fact that DSS does not yet have
device tree bindings, so we need to rely on the TWL GPIO callback
for setting up things like LCD backlight for some boards.

As of_platform_populate() for the TWL GPIO is called by twl-core
after the I2C bus has been initialized, we cannot pass the auxdata
table from the board init code to twl-core like we used to with
just legacy platform data.

So let's use the omap_device bus hook to patch in the platform
data for TWL GPIO until we have sorted out the issues with the
TWL GPIOs and device tree bindings.

The other option was be to initialize twl core using legacy
platform data, which seems like a step backwards as we're moving
to device tree only initialization.  And we really don't want to
add custom configuration functions to the TWL GPIO driver either
for this.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is no longer used, omap4 is device tree based now.
Signed-off-by: NTony Lindgren <tony@atomide.com>

AM335x, AM43xx, OMAP5 and DRA7 have missing late init hook. Introduce
SoC specific hook with a call to OMAP2+ generic lateinit hook. This
allows the generic late initializations such as cpufreq hooks to be
active.

Based on out-of-tree patches that need to be introduced in
mainline, this introduction allows us to provide the foundation for
further SoC specific features as they are developed.

Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For few things we're still going to be needing platform
data for device tree based drivers. Let's set up auxdata
handling and do it in pdata-quirks.c so we have all the
legacy calls in one place.
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>