Move the OMAP1-specific RNG device creation off to mach-omap1/devices.c,
and create a omap_device-backed registration function for OMAP2+ devices
in mach-omap2/devices.c.

As a nice side-benefit, we can also get rid of
arch/arm/plat-omap/devices.c, thanks to some recent changes from Tony.

One change from the previous behavior is that the RNG devices are now
registered unconditionally.  This should allow the RNG drivers to be
loaded as modules, even if the original kernel was not built that way.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Convert the OMAP onboard hardware RNG driver to use runtime PM.

This allows us to remove some OMAP-specific cpu_is_omap*() calls from
the RNG driver.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>

Encapsulate all of the RNG per-device state into a single per-device
structure record, as opposed to a set of per-driver file variables.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add integration data for the hardware random number generator IP block
on some OMAP SoCs.  This appears to be present on at least OMAP2xxx
and OMAP3xxx SoCs, although it is not so easy to tell.  It may also be
present on other OMAP2+ SoCs.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Create a minimal driver out of gpmc code.  Responsibilities handled by
earlier gpmc initialization is now achieved in probe.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Reviewed-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed some checkpatch messages]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Create API for platforms to adapt GPMC to HWMOD
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Reviewed-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add gpmc hwmod and associated interconnect data
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
[paul@pwsan.com: added comments to the use of HWMOD_INIT_NO_RESET]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add mmu hwmod data for ipu and dsp.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
Acked-by: NBenoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: cleaned up whitespace]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add mmu hwmod data for iva and isp.

Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be migrated
to iommu framework.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: fixed some kerneldoc and whitespace; ISP MMUs not present
 on AM35xx so restricted these hwmods to 34xx/36xx]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

If included without IOMMU_API being selected it will break
compilation:

arch/arm/plat-omap/include/plat/iommu.h:
	In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
	error: 'struct dev_archdata' has no member named 'iommu'

This will be seen when hwmod includes iommu.h to get the
structure for attributes. Also needed for tidspbridge
incremental migration to use iommu code.

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some struct omap_hwmod records belonging to PRCM IP blocks are missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
Since this ocp2scp module does not have any fck but does have a
single opt_clock, it is added as the main_clk for ocp2scp. Also
removed phy_48m as the optional clock since it is now made as the
main clock. By this the driver need not enable/disable phy_48m clk
separately and runtime_get/runtime_put will take care of that.

Cc: Benoît Cousson <b-cousson@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NBenoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

ocp2scp_usb_phy was missing the address space data and thus
the sysconfig was not populated either.
The usb_host_hs address space was wrong.

Fix both of them and add the missing sysconfig entry.
Reported-by: NKishon Vijay Abraham <kishon@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

SAD2D stands for the die to die interface, and is used for communicating
with the optional stacked modem. This hwmod is added in preparation for
the d2d_idle move from pm34xx.c to hwmod data.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
[paul@pwsan.com: SAD2D presumably doesn't exist on non-OMAP34xx/OMAP36xx,
 so only add it to the OMAP34xx/OMAP36xx lists]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.

E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- As of now cpu1 is not used and hence (with previous check) the
  IP block isn't fully enabled by hwmod code.
- Usually ipu and dsp processors configure their mmu module first
  and then enable the processors, this involves:
    * Deasserting mmu reset line, and enabling the module.
    * Deasserting cpu0 reset line, and enabling the processor.
  The ones portrayed in this example are controlled through
  rproc_fw_boot in drivers/remoteproc/remoteproc_core.c

While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.

This will allow the driver to:
  a. Deassert the reset line.
  b. Enable the hwmod through runtime PM default callbacks.
  c. Do its usecase.
  d. Disable hwmod through runtime PM.
  e. Assert the reset line.
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by adding a
flag bit, HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT.  Rest have a valid
'context_offs' populated in .prcm structure already.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
[paul@pwsan.com: add flag bit rather than overloading .context_offs;
 update changelog message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Currently hwmod only provides the offset for the context lose
register, and if we attempt to share the same register between two or
more hwmods, the resulting context loss counts get wrong. Thus, we
need a way to specify which bits are used for the context loss
information for each.  This is accomplished by adding a new field to
the omap4 prcm struct, 'lostcontext_mask', which specifies a bit-mask
to use for filtering the register.

Mark the affected hwmods appropriately.  'l4_abe' hwmod uses the
LOSTMEM_AESSMEM bit of RM_ABE_AESS_CONTEXT register, as l4_abe doesn't
have its own dedicated register for this purpose. This register is
shared with 'aess' hwmod, thus both hwmods must also specify which
bits of the register are used for them.

This patch only adds the hwmod data, but a future patch should add
code support such that only the specified bits are read and cleared by
the context lose counter update code. If a hwmod doesn't specify
'lostcontext_mask' (default behavior), the whole contents of the
context register should be used without any filtering.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
[paul@pwsan.com: updated to apply after conversion to use flag bit for
 missing module context-loss register; combined data and code patches;
 dropped code change due to serial driver breakage]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.

In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.

If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
[paul@pwsan.com: removed dependency on functional power state series for now;
 bumped copyright date]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The decision was made a few months ago to allow struct omap_hwmod
records and struct clk records to omit clockdomain information if the
clockdomain is not software-controllable.  See for example commit
868c157d ("ARM: OMAP2+: hwmod: remove
prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain").

So convert an existing pr_warning() to a pr_debug() (regarding missing
clockdomains in clocks), and add a pr_debug() for missing hwmod
clockdomains.  It's still useful to enable these messages for
debugging, since missing clockdomains can cause hard-to-debug problems
with power management; see for example commit
6c4a057b ("ARM: OMAP4: clock data:
Force a DPLL clkdm/pwrdm ON before a relock").
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

We're no longer requiring struct omap_hwmod records to contain a
clockdomain.  So we shouldn't return -EINVAL any more from
_omap4_wait_target_disable() or _omap4_wait_target_ready() if there's
no clockdomain defined, since that just gets passed back to the
caller.  This can result in pointless warnings under the relaxed data
format.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

This API is meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data to
control their reset lines, they are expected to know the name of the
reset line they are trying to control.
Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
[paul@pwsan.com: tweaked some documentation; fixed CodingStyle issue]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Several hwmod function prototypes appear to not have an implementation
because the corresponding functions were removed or renamed.
Those prototypes are unneeded anymore - remove them.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
[paul@pwsan.com: tweaked subject]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Conflicts:
	arch/arm/mach-omap2/clkt34xx_dpll3m2.c
	arch/arm/mach-omap2/clkt_clksel.c
	arch/arm/mach-omap2/clock.c

From Paul Walmsley <paul@pwsan.com>:

AM33xx hwmod data and miscellaneous clock and hwmod fixes.  AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.

These fixes are needed to fix non-omap build breakage for
twl-core driver and to fix omap1_defconfig compile when
led driver changes and omap sparse IRQ changes are merged
together. Also fix warnings for omaps not using pinctrl
framework yet.

smatch and string-wrapping cleanups for the OMAP subarch code.

These changes fix some of the more meaningful warnings that smatch
returns for the OMAP subarch code, and unwraps strings that are
wrapped at the 80-column boundary, to conform with the current
practice.

Basic build, boot, and PM logs are available here:

http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/

The new common clk framework includes basic definitions for mux and
divider clocks.  These definitions depend on shift and width values
instead of the pre-computed masks that the OMAP/AM33XX clk framework
has traditionally used when accessing the register to control the
mux or divisor.

To ease this transition the masks are left intact and
the width field is simply added alongside the shift and mask data.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The new common clk framework includes basic definitions for mux and
divider clocks.  These definitions depend on shift and width values
instead of the pre-computed masks that the OMAP clk framework has
traditionally used when accessing the register to control the mux or
divisor.

To ease this transition the masks are left intact and the width field is
simply added alongside the shift and mask data.
Signed-off-by: NMike Turquette <mturquette@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.

While here also concatenate some strings split across multiple lines
which seem to be needed anyway.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: simplified some compound expressions; reformatted some
 messages]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>

Moving to Common clk framework for OMAP would mean we no longer use
internal lookup mechanism like omap_clk_get_by_name().
get rid of all its usage mostly from hwmod and omap_device
code.

Moving to clk_get() also means the respective platforms
need the clkdev tables updated with an entry for all clocks
used by hwmod to have clock name same as the alias.

Based on original changes from Mike Turquette.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
[paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment);
 restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx
 clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added
 aliases rng_ick and several emulation clocks]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

As part of Common Clk Framework (CCF) the clk_enable() operation
was split into a clk_prepare() which could sleep, and a clk_enable()
which should never sleep. Similarly the clk_disable() was
split into clk_disable() and clk_unprepare(). This was
needed to handle complex cases where in a clk gate/ungate
would require a slow and a fast part to be implemented.
None of the clocks below seem to be in the 'complex' clocks
category and are just simple clocks which are enabled/disabled
through simple register writes.
Most of the instances also seem to be called in non-atomic
context which means its safe to move all of those from
using a clk_enable() to clk_prepare_enable() and clk_disable() to
clk_disable_unprepare().

For some others, mainly the ones handled through the hwmod framework
there is a possibility that they get called in either an atomic
or a non-atomic context.

The way these get handled below work only as long as clk_prepare
is implemented as a no-op (which is the case today) since this gets
called very early at boot while most subsystems are unavailable.
Hence these are marked with a *HACK* comment, which says we need
to re-visit these once we start doing something meaningful with
clk_prepare/clk_unprepare like doing voltage scaling or something
that involves i2c.

This is in preparation of OMAP moving to CCF.

Based on initial changes from Mike Turquette.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Remove unnecessary includes of plat/clock.h from the OMAP SPI
controller drivers.  These need to be removed to build multi-subarch
ARM kernels which include these drivers.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>

For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
power domains. Hence, when the dmtimer is configured to use the "timer_sys_ck"
as its functional clock the actual clock used is different depending on whether
the clock is in the Wake-up, ABE or PER domain. So when we look-up the dmtimer's
"timer_sys_ck" we need to specify the timer device name as well as clock alias
to find the right clock.

Currently, the device names for the timers have the format "omap_timer.X" where
X is the timer instance number. When using to device tree, the format of the
device name created by device-tree is different and has the format
"<reg-address>.<device-name>" (this is assuming that the device-tree "reg"
property is specified). This causes the look-up for the OMAP4 "timer_sys_ck" to
fail. To fix this add new timer clock alias for using device-tree.

Please note that adding a 2nd set of clock aliases for the same clocks to only
temporary until device-tree migration is complete. Then we can remove the legacy
aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add AM335x cpu0 clock entry to the corresponding clock data file. This
is useful in getting the correct mpu clock pointer to change the cpu
frequency in cpufreq driver.
Signed-off-by: NAnilKumar Ch <anilkumar@ti.com>
[paul@pwsan.com: changed patch subject]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

These clkdev aliases should make it possible to remove the
cpu_is_omap*() calls and the omap_device*() call from
drivers/cpufreq/omap-cpufreq.c during the next merge window.  Those
are interfering with multi-subarch ARM kernels.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: NKevin Hilman <khilman@ti.com>

The platform device name "usbhs_tll" is added for the functional,
interface and channel clocks of the TLL module.
Signed-off-by: NKeshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: NPartha Basak <parthab@india.ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

In commit c59b537d (ARM: OMAP2+: Simplify dmtimer clock aliases) new clock
aliases were added for OMAP2+ devices. For OMAP2420, I incorrectly set the
clock flag as CK_243X instead of CK_242X. This did not introduce a regression
as the clock flags are not checked for OMAP2 devices. This also explains why
I did not catch this when testing on OMAP2420.

Fix the clock flags for these aliases for correctness.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>

The file is currently called 'clock3xxx_data.c', so this comment is
out of date.
Signed-off-by: NMichael Jones <michael.jones@matrix-vision.de>
[paul@pwsan.com: wrote changelog]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

From Paul Walmsley <paul@pwsan.com>:

AM33xx hwmod data and miscellaneous clock and hwmod fixes.  AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.