Previously, the TI clock driver initialized all the clocks hierarchically
under each separate clock provider node. Now, each clock that requires
IO access will instead check their parent node to find out which IO range
to use.

This patch allows the TI clock driver to use a few new features provided
by the generic of_clk_init, and also allows registration of clock nodes
outside the clock hierarchy (for example, any external clocks.)
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Stefan Assmann <sassmann@kpanic.de>
Acked-by: NTony Lindgren <tony@atomide.com>

Replace obsolete strict_strto call with kstrto calls.
Simplify copy_from_user/strict_strto by using kstrto_from_user
Signed-off-by: NDaniel Walter <dwalter@google.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix coding style problems in arch/arm/mach-omap2/control.c.
Signed-off-by: NJeremy Vial <jvial@adeneo-embedded.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

According to the comment “restore_es3: applies to 34xx >= ES3.0" in
"arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used
if the revision of an OMAP34xx is ES3.1.2.
Signed-off-by: NJeremy Vial <jvial@adeneo-embedded.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

The fields are not used by the driver and will be removed from platform
data. Don't set them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Change the behavior of omap2_dpll_round_rate() to round to either the
exact rate requested, or the next lowest rate that the clock is able to
provide.

This is not an ideal fix, but is intended to provide a relatively safe
way for drivers to set PLL rates, until a better solution can be
implemented.

For the time being, omap3_noncore_dpll_set_rate() is still allowed to
set its rate to something other than what the caller requested; but will
warn when this occurs.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This patch adds bch8 ecc software fallback which is mostly used by
omap3s because they lack hardware elm support.

Fixes: 0611c419 (ARM: OMAP2+: gpmc:
update gpmc_hwecc_bch_capable() for new platforms and ECC schemes)
Cc: <stable@vger.kernel.org> # 3.15.x+
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Reviewed-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Since the OPP layer is a kernel library which has been converted to be
directly selectable by its callers rather than user selectable and
requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
has become redundant and can be removed. Do so.
Signed-off-by: NMark Brown <broonie@linaro.org>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NNishanth Menon <nm@ti.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NShawn Guo <shawn.guo@freescale.com>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add hwmod data for RTC
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Tested-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Tested-by: NKishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
for pcie1 phy and pcie2 phy.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Tested-by: NKishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This module is needed for the SATA and PCIe PHYs.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

DMA interrupts are now available in of, and the definitions are
duplicates in hwmod. This prevents us from dynamically allocating
interrupt resources for dma from devicetree.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

we have currently 2 DMA drivers that try to co-exist.
drivers/dma/omap-dma.c which registers it's own IRQ and is device tree
aware and uses arch/arm/plat-omap/dma.c instance created by
arch/arm/mach-omap2/dma.c to maintain channel usage (omap_request_dma).

Currently both try to register interrupts and mach-omap2/plat-omap dma.c
attempts to use the IRQ number registered by hwmod to register it's own
interrupt handler.

Now, there is no reasonable way of static allocating DMA irq in GIC
SPI when we use crossbar. However, since the dma_chan structure is
freed as a result of IRQ not being present due to devm allocation,
maintaining information of channel by platform code fails at a later
point in time when that region of memory is reused.

So, if hwmod does not indicate an IRQ number, then, assume that
dma-engine will take care of the interrupt handling.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

ARMv6 and greater introduced a new instruction ("bx") which can be used
to return from function calls.  Recent CPUs perform better when the
"bx lr" instruction is used rather than the "mov pc, lr" instruction,
and this sequence is strongly recommended to be used by the ARM
architecture manual (section A.4.1.1).

We provide a new macro "ret" with all its variants for the condition
code which will resolve to the appropriate instruction.

Rather than doing this piecemeal, and miss some instances, change all
the "mov pc" instances to use the new macro, with the exception of
the "movs" instruction and the kprobes code.  This allows us to detect
the "mov pc, lr" case and fix it up - and also gives us the possibility
of deploying this for other registers depending on the CPU selection.
Reported-by: NWill Deacon <will.deacon@arm.com>
Tested-by: Stephen Warren <swarren@nvidia.com> # Tegra Jetson TK1
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> # mioa701_bootresume.S
Tested-by: Andrew Lunn <andrew@lunn.ch> # Kirkwood
Tested-by: NShawn Guo <shawn.guo@freescale.com>
Tested-by: Tony Lindgren <tony@atomide.com> # OMAPs
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> # Armada XP, 375, 385
Acked-by: Sekhar Nori <nsekhar@ti.com> # DaVinci
Acked-by: Christoffer Dall <christoffer.dall@linaro.org> # kvm/hyp
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> # PXA3xx
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> # Xen
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # ARMv7M
Tested-by: Simon Horman <horms+renesas@verge.net.au> # Shmobile
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It was added to support DSP Bridge. Since DSP Bridge was removed, and
nothing else is using the platform device, remove it too.
Signed-off-by: NKristina Martšenko <kristina.martsenko@gmail.com>
Cc: Omar Ramirez Luna <omar.ramirez@copitl.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead, copy the used constants from the header file to the source file.
This allows the code to be migrated under drivers folder where we don't
have access to the OMAP specific header files.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some of the machine specific header includes are no longer used, so remove
these from the source file. This allows migration of the file under clock
driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some of the machine specific header includes are no longer used, so remove
these from the source file. This allows migration of the file under clock
driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Helps to get rid of some runtime cpu_is_x checks. This also allows eventual
migration of the code under clock driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently DPLL code uses runtime cpu_is_343x checks to see if the DPLL
has freqsel fields in its control register or not. Instead, add a new
flag to the clk_features.flags and use this during runtime. Allows
eventual move of the DPLL code under clock driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

OMAP2 DPLL code for checking whether DPLL is in bypass mode now uses
clk_features data provided during boot. This avoids the need to use
cpu_is_X type checks runtime, and allows us to eventually move the
clock code under the clock driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently, same functionality is copy pasted in two locations. Instead,
add a private API for this and get rid of some duplicated code.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

These are SoC specific and get their init values based on the SoC type.
Previously the values were hard coded within the DPLL clock code, but
having them inside the clock features avoids runtime cpu_is_X type checks.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This shall be used to replace the cpu type checks around the clock code.
Actual bit values will be introduced in patches later.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Instead, copy the used bitfield definitions to the source file. Done in
preparation to migrate the clock implementation under clock driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

These are unnecessary, as the clock code is only used on OMAP4+ platforms
through clock registrations. This also allows to eventually migrate the
clock type implementation under clock driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The legacy-style definition of the hwmod addr space is no longer
required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
DT nodes have been added, so clean up this data.
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The legacy-style definition of the hwmod addr space is no longer
required after the addition of the OMAP4 mailbox DT node, so
clean up this data.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <bcousson@baylibre.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP2 devices are devicetree boot only, and the legacy mode
of mailbox device creation should no longer be used, so remove
the mailbox attribute data and the hwmod addr space used for
creating mailboxes in legacy mode.
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The legacy platform device for mailbox should not be created for
a DT boot, so adjust the platform device initialization logic
appropriately.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is hardware controlled.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

On OMAP SOCs using PL310 controllers, power_ctrl register is not
accessible from non-secure software even on PL310 versions which
support it. The secure code takes care of setting it up correctly
and power transitions are proven on these devices.

For example, AM437x has L2C-310 version r3p3 and ROM code on that
device does not support writing to L2C-310 power control register.
The L2C driver, however, tries writing to this register for all
revisions >= r3p0.

This leads to a warning dump on boot which leads most users to believe
that L2 cache is non-functional.

Since the problem is understood, and cannot be addressed through
software, replace the warning with a pr_info() while maintaining the
WARN_ON() for other truly unexpected scenarios.
Reported-by: NNishanth Menon <nm@ti.com>
Tested-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated "struct platform_device
gpmc_nand_device" it is not possible to configure the system to
use more than one NAND device connected to the GPMC. This
modification makes it possible to use up to 8 NAND devices
connected to the GPMC controller.
Signed-off-by: NRostislav Lisovy <lisovy@merica.cz>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

This clock type declaration is no longer used as all omap4+ SoC clock
data has been moved to DT, thus remove it.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NMike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The mach-omap2 directory contains full register defines for OMAP4
control module but only around 27 of those are used. There are is
a total of 1795 register defines in four files with only 27 in use.
That is pretty low usefulness ratio...

I guess alot more was used when we had omap4 board files and
mach-omap2 contained more drivers but this has now changed.
Signed-off-by: NJoachim Eastwood <manabian@gmail.com>
[tony@atomide.com: updated to apply]
Signed-off-by: NTony Lindgren <tony@atomide.com>

This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently, child nodes of the gpmc node are iterated and probed
regardless of their 'status' property. This means adding 'status =
"disabled";' has no effect.

This patch changes the iteration to only probe nodes marked as
available.
Signed-off-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Tested-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The DSP platform device for TI DSP/Bridge is currently
created unconditionally whenever CONFIG_TIDSPBRIDGE is
enabled. This device should only be created on OMAP34xx/
OMAP36xx SoCs, and not for other OMAP3 derived SoCs or when
booting multi-arch images on other SoCs. So, add a check for
the SoC family both before creating the device and allocating
the carveout memory for the device.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>