Enable the AESS auto-gating control bit during AESS hwmod setup.  This
fixes the following boot warning on OMAP4:

omap_hwmod: aess: _wait_target_disable failed

Without this patch, the AESS IP block does not indicate to the PRCM
that it is idle after it is reset.  This prevents some types of SoC
power management until something sets the auto-gating control bit.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
[paul@pwsan.com: copy patch description into hwmod data comments]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk->enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.

According to comments received[1] for related patches the idea is
to get rid of leaf clocks in future. So remove these two while at it.

[1] http://lkml.org/lkml/2012/8/20/226Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
Tested-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Based on earlier discussions[1] we attempted to find a suitable
location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
to dmaengine is complete.

Unfortunately that was before I was able to try to test compile
of the ARM multiplatform builds for omap2+, and the end result
was not very good.

So I'm creating yet another all over the place patch to cut the
last dependency for building omap2+ for ARM multiplatform. After
this, we have finally removed the driver dependencies to the
arch/arm code, except for few drivers that are being worked on.

The other option was to make the <plat-omap/dma-omap.h> path
to work, but we'd have to add some new header directory to for
multiplatform builds.

Or we would have to manually include arch/arm/plat-omap/include
again from arch/arm/Makefile for omap2+.

Neither of these alternatives sound appealing as they will
likely lead addition of various other headers exposed to the
drivers, which we want to avoid for the multiplatform kernels.

Since we already have a minimal include/linux/omap-dma.h,
let's just use that instead and add a note to it to not
use the custom omap DMA functions any longer where possible.

Note that converting omap DMA to dmaengine depends on
dmaengine supporting automatically incrementing the FIFO
address at the device end, and converting all the remaining
legacy drivers. So it's going to be few more merge windows.

[1] https://patchwork.kernel.org/patch/1519591/#

cc: Russell King <linux@arm.linux.org.uk>
cc: Kevin Hilman <khilman@ti.com>
cc: "Benoît Cousson" <b-cousson@ti.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: "David S. Miller" <davem@davemloft.net>
cc: Vinod Koul <vinod.koul@intel.com>
cc: Dan Williams <djbw@fb.com>
cc: Mauro Carvalho Chehab <mchehab@infradead.org>
cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
cc: Hans Verkuil <hans.verkuil@cisco.com>
cc: Vaibhav Hiremath <hvaibhav@ti.com>
cc: Lokesh Vutla <lokeshvutla@ti.com>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
cc: Afzal Mohammed <afzal@ti.com>
cc: linux-crypto@vger.kernel.org
cc: linux-media@vger.kernel.org
cc: linux-mtd@lists.infradead.org
cc: linux-usb@vger.kernel.org
cc: linux-fbdev@vger.kernel.org
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is not used anymore
in the i2c driver. Remove the flag.
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.

Partially based on an earlier version by Ido Yariv <ido@wizery.com>.

Cc: Ido Yariv <ido@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NJoerg Roedel <joro@8bytes.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.

For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
have the fields clock-activity, wakeup-enable and auto-idle and so this
function could configure the OCP_CFG register incorrectly.

Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
register for timers that have this field. Commit 0f0d0807 (ARM: OMAP: DMTimer:
Use posted mode) configures the clock-activity field to keep the f-clk enabled
so that the wake-up capability is enabled. Therefore, add the appropriate flags
to the timer HWMOD structures to configure this field in the same way.

For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.

Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.

This is needed to fix MUSB regression caused by commit c9e4412a
(arm: omap: phy: remove unused functions from omap-phy-internal.c)
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[tony@atomide.com: updated comments for regression info]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Most of the prototypes in plat-omap/common.h are not
common to omap1 and omap2+, they are local to omap2+
and should not be in plat-omap/common.h.

The only shared function prototype in this file is
omap_init_clocksource_32k(), let's put that into
counter-32k.h.

Note that the new plat/counter-32k.h must not be
included from drivers, that will break omap2+ build
for CONFIG_MULTIPLATFORM.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Resolve this kernel boot message:

omap_hwmod: mcpdm: cannot be enabled for reset (3)

The McPDM on OMAP4 can only receive its functional clock from an
off-chip source.  This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C.  This would
introduce a board dependency to the early hwmod code which it was not
designed to handle.  Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks.  This effectively
makes it impossible to enable and reset this device during hwmod init.

At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source.  (This is true for almost
every IP block on the chip.  As far as I know, McPDM is the only
exception.)  If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state.  Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.

This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

Let's make omap_hwmod local to mach-omap2 for
ARM common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We cannot keep this in plat/common.h for common zImage support.
Signed-off-by: NTony Lindgren <tony@atomide.com>

There's no need to keep the device related things in the
common i2c.c as omap2+ is using hwmod. Split the code to
mach-omap1 and mach-omap2 parts and only leave common
code to plat-omap/i2c.c.

Note that as omap1 only has one i2c controller, we can
now remove the old device related macros.
Reviewed-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move plat/dma.h to plat-omap/dma-omap.h as part of single
zImage work
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We need to remove this from plat for ARM common zImage
support.

Also remove includes not needed by the omap_hsmmc.c driver.

Cc: linux-mmc@vger.kernel.org
Acked-by: NChris Ball <cjb@laptop.org>
Acked-by: NVenkatraman S <svenkatr@ti.com>
[tony@atomide.com: fold in removal of unused driver includes]
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these
interrupts to the MPU HWMOD so we can use these for PMU events on these
devices. The PMU interrupts need to be the first interrupts in the array of
interrupts as the ARM PMU driver assumes this.

By using these dedicated interrupts we only need to enable the MPU and DEBUG
sub-systems for PMU to work. This is different to OMAP4430 that did not have
dedicated interrupts and required other power domains in addition to the DEBUG
sub-system to be enabled so we could route the PMU events to the CTI interrupts.
Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
the PMU device that is using by OMAP3.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some instances of the DMTIMER peripheral on OMAP devices have the ability
to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER
attribute to indicate which timers can interrupt the DSP. By using the
omap_dm_timer_request_by_cap() API, driver will now be able to allocate
a DMTIMER that can interrupt the DSP based upon this attribute and not require
the driver to know which instance has this capability.

DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as
follows ...

- OMAP1 (OMAP5912/16xx/17xx) devices	- All 8 DMTIMERs
- OMAP2/3/4 devices			- DMTIMERs 5-8

Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and
generate a PWM output.
Signed-off-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>

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>

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>

To help the driver to get the correct memory range to access McPDM
registers.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Platform data for device drivers should be defined in
include/linux/platform_data/*.h, not in the architecture
and platform specific directories.

This moves such data out of the omap include directories
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Jean Pihet <j-pihet@ti.com>
Cc: J Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org

As the plat and mach includes need to disappear for single zImage work,
we need to remove plat/hardware.h.

Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.

The old plat/hardware.h already has omap1 only defines, so it gets moved
to mach/hardware.h for omap1. For omap2+, we use the local soc.h
that for now just includes the related SoC headers to keep this patch more
readable.

Note that the local soc.h still includes plat/cpu.h that can be dealt
with in later patches. Let's also include plat/serial.h from common.h for
all the board-*.c files. This allows making the include files local later
on without patching these files again.

Note that only minimal changes are done in this patch for the
drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
patches are needed to eventually remove cpu_is_omap usage in the drivers.

Also only minimal changes are done to sound/soc/omap/* to remove the
unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
no need to include omap44xx.h.

While at it, also sort some of the includes in the standard way.

Cc: linux-watchdog@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Acked-by: NWim Van Sebroeck <wim@iguana.be>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

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>

The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.

Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Acked-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The OMAP4 sl2if IP block requires some special programming for it to
enter idle. Without this programming, it will prevent the rest of
the chip from entering full chip idle.

This patch comments out the IP block data.

Later, once the appropriate support is available, this patch can be
reverted.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The commit 503d0ea2
  ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks

added a wrong "prcm_clk" alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using "prcm_fck".

It thus lead to the following warning.

[   47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck

Fix that by changing the opt_clk role to prcm_fck.
Reported-by: NMisael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NSebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special
programming for them to enter idle.  Without this programming, they
will prevent the rest of the chip from entering full chip idle.

To implement the idle programming cleanly, this will take some
coordination between maintainers.  This is likely to take some time,
so it is probably best to leave this for 3.6 or 3.7.  So, in the
meantime, prevent these IP blocks from being registered.

Later, once the appropriate support is available, this patch can be
reverted.

This second version comments out the IP block data since Benoît didn't
like removing it.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

As per the OMAP4 documentation, audio over HDMI must be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
no-idle/force-idle settings instead of smart-idle mode.

This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
[b-cousson@ti.com: Update the subject and align the .flags
location with the script template]
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The 32k sync timer IP block target idle modes in the hwmod data are
incorrect.  The IP block does not support any smart-idle modes.
Update the data to reflect the correct modes.

This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson <b-cousson@ti.com>.  A patch description
bug in the first version was also identified by Benoît.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>

Remove prm_clkdm and cm_clkdm and allow hwmods to have no clockdomain.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The enable/disable module functions are specific to SoCs with
OMAP4-class PRCM.  Rather than use cpu_is* checks at runtime inside
the enable/disable module functions, use cpu_is at init time to
initialize function pointers only for SoCs that need them.

NOTE: the cpu_is* check for _enable_module was different than
      the one for _disable_module, and this patch uses
      cpu_is_omap44xx() for both.
Signed-off-by: NKevin Hilman <khilman@ti.com>
[paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than
 per-hwmod since they do not vary by hwmod; added kerneldoc]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Fix the following issues with the timer device attributes for OMAP2+ devices:

1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
   that these timers are in an ALWAYS-ON power domain. This is not the case
   only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
   that these timers are in an ALWAYS-ON power domain. This is not the case
   only timer1 and timer12 are in an ALWAYS-ON power domain.
3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but
   is in an always-on power domain.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move the smartreflex header file
(arch/arm/mach-omap2/smartreflex.h) in a new header file
include/linux/power/smartreflex.h.

This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: NJean Pihet <j-pihet@ti.com>
Signed-off-by: NJ Keerthy <j-keerthy@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Without runtime PM enabled, hwmod needs to leave all IP blocks in an
enabled state by default so any driver access to the HW will succeed.
This is accomplished by seting the postsetup_state to enabled for all
hwmods during init when runtime PM is disabled.

Currently, we have a special case for WDT in that its postsetup_state
is always set to disabled.  This is done so that the WDT is disabled
and the timer is disarmed at boot in case there is no WDT driver.
This also means that when runtime PM is disabled, if a WDT driver *is*
built in the kernel, the kernel will crash on the first access to the
WDT hardware.

We can't simply leave the WDT module enabled, because the timer is
armed by default after reset. That means that if there is no WDT
driver initialzed or loaded before the timer expires, the kernel will
reboot.

To fix this, a custom reset method is added to the watchdog class of
omap_hwmod.  This method will *always* disarm the timer after hwmod
reset.  The WDT timer then will only be rearmed when/if the driver is
loaded for the WDT.  With the timer disarmed by default, we no longer
need a special-case for the postsetup_state of WDT during init, so it
is removed.

Any platforms wishing to ensure the watchdog remains armed across the
entire boot boot can simply disable the reset-on-init feature of the
watchdog hwmod using omap_hwmod_no_setup_reset().

Tested on 3530/Overo, 4430/Panda.

NOTE: on 4430, the hwmod OCP reset does not seem to rearm the timer as
documented in the TRM (and what happens on OMAP3.)  I noticed this
because testing the HWMOD_INIT_NO_RESET feature with no driver loaded,
I expected a reboot part way through the boot, but did not see a
reboot.  Adding some debug to read the counter, I verified that right
after OCP softreset, the counter is not firing.  After writing the
magic start sequence, the timer starts counting.  This means that the
timer disarm sequence added here does not seem to be needed for 4430,
but is technically the correct way to ensure the timer is disarmed, so
it is left in for OMAP4.

Special thanks to Paul Walmsley for helping brainstorm ideas to fix
this problem.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: updated the omap2_wd_timer_reset() function in the
 wake of commit 3c55c1ba ("ARM:
 OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset
 wait for reset status""); added kerneldoc; rolled in warning fix from Kevin]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>