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>

Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 & 3 hwmod table.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and OMAP3.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Wamsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and the OMAP4 hwmod data
will be using the same name.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the HDQ1W hwmod for all OMAP2xxx devices.

Assume that OMAP2xxx chips have the same HDQ idle handling bug
as OMAP3:

   http://www.spinics.net/lists/linux-omap/msg63576.html

and set the OCPIF_SWSUP_IDLE flag accordingly on the HDQ's OCP interface.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the HDQ1W hwmod for OMAP34xx, OMAP36xx, and AM3505/3517 devices.
According to the respective TRMs, it doesn't appear to be available for the
816x/814x or the AM335x.

The OCPIF_SWSUP_IDLE flag is added to work around an apparent hardware
bug: the hardware is not taking the CM_FCLKEN*_CORE.EN_HDQ bit into
account when considering whether to go idle:

    http://www.spinics.net/lists/linux-omap/msg63576.html

This causes HDQ transfers to fail or become corrupt.  Thanks to
NeilBrown for his help diagnosing and testing fixes for this problem.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NNeilBrown <neilb@suse.de>

Much of the HDQ1W integration data is common between multiple generations
of OMAP SoCs, so rather than make several copies, we add it once into
files which are compiled for multiple SoCs.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NNeilBrown <neilb@suse.de>

Implement a custom reset function for the HDQ1W IP block.  This is
because the HDQ1W IP block, like I2C, has an internal clock gating bit
that needs to be toggled after setting the SOFTRESET bit to allow the
reset to propagate.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Avinash.H.M <avinashhm@ti.com>
Tested-by: NNeilBrown <neilb@suse.de>

Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
[paul@pwsan.com: updated to apply on top of the 3.5 hwmod cleanup;
 changed mmc hwmod name/class to "msdi" as documented in the 2420 TRM Rev X;
 added sysconfig register information; added 16 bit register width flag;
 added MSDI custom reset code]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Merge branches 'clock_am35xx_cleanup_3.5', 'prm_cm_devel_a_3.5', 'clock_devel_a_3.5' and 'pwrdm_clkdm_cleanup_3.5' into prcm_devel_a_3.5

Clean up clockdomains3xxx_data.c a bit by removing the superfluous
commas in gfx_sgx_3xxx_wkdeps[].
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

With patch 'ARM: OMAP2+: powerdomain: Wait for powerdomain transition
in pwrdm_state_switch()', the pwrdm_clkdm_state_switch() API becomes
duplicate of pwrdm_state_switch().

Get rid off duplicate pwrdm_clkdm_state_switch() and update the
users of it with pwrdm_state_switch()
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the correct clockdomain for the HDQ functional clock.  This is needed
for the clock and hwmod PM code to work correctly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>

The current DPLL code enables and disables autoidle features
without checking whether the autoidle register is available.
Fix this by putting a check for the existence of the autoidle
register in the DPLL data.

With such a check in place, for DPLLs which do not support this
feature, simply skipping the autoidle_reg entry in the DPLL data
is sufficient.
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

We do not use iclk anywhere in the dmtimer driver and so removing it.
Hence removing the timer iclk entries from OMAP4 clkdev table as well.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Instead of statically defining seperate arrays for every OMAP4+ archs,
have a generic init function to populate the arrays. This avoids the
need for creating new array for every arch added in the future that
reuses the prm and cm registers read/write code.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add missing idle_st bit for 32k-sync timer into the prcm-common
header file, required for hwmod data.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The register bits for MPU_CLK_SRC and IVA2_CLK_SRC in CM_CLKSEL1_PLL
register are 3 bits wide.  Fix the MASK definition accordingly.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

To improve the clarity of the code, replace the CK_3517 flag used in
the clock data with CK_AM35XX.  The CK_3505 flag can also be
removed, since it is now unused.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The init for 3505/3517 specific clocks depends on the ordering of
cpu_is checks, is error prone and confusing (there are 2 separate
checks for cpu_is_omap3505()).

Remove the 3505-specific checking since CK_3505 flag is not used, and
treat all AM35x clocks the same.

This means that the SGX clock (the only AM35x clkdev not currently
flagged for 3505) will now be registered on 3505, but that is
harmless.  That can be cleaned up when the clkdev nodes are removed in
favor of them being registered by hwmod.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The AM35x UART4 is common to all AM35x devices, so use CK_AM35XX instead
of (CK_3505 | CK_3517), which is equivalent.
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add a skeleton hwmod for the DEBUGSS and associated interconnect data.
This is a basic set of data that will need further additions as
further DEBUGSS information becomes available.
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the PRCM, CM, PRM, and related hwmod and associated interconnect
data.  These IP blocks handle most of the on-chip power, reset, and clock
control.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Add the System Control Module hwmod and associated interconnect data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Add the OCP-WP hwmod and associated interconnect data.  The OCP-WP,
or OCP watchpoint, can be used to collect interconnect data and
transmit it via the STM port.
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the OCM RAM IP block and interconnect data.  This is an oh-chip
block of SRAM connected directly to the L3 bus.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Add the OCP2SCP IP block and interconnect data.  The OCP2SCP can be
used in conjunction with the on-chip embedded USB PHY, associated with
the OTG controller.

Add the on-chip full-speed USB host controller IP block and
interconnect data.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the SL2 interface IP block and interconnect data.  The SL2 is related
to the IVA-HD subsystem.

Add IP block and interconnect data for the C2C ("Chip-to-chip")
interconnect.  This can provide a direct system interconnect link to
other devices stacked on the OMAP package.

Add the ELM IP block and interconnect data.  The ELM can be used
to locate errors in NAND flash connected to the GPMC.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Add the McASP hwmod and associated interconnect data.  The McASP is a
general-purpose audio serial port.
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the Slimbus hwmods and associated interconnect data.  The Slimbus
IP blocks implement a two-wire serial interface.
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the GPU hwmod and associated interconnect data.  The GPU is a
graphics accelerator.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Add the EMIF1 and 2 hwmods and associated interconnect data.  The EMIFs
are SDRAM interface IP blocks.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Add the GPMC hwmod and associated interconnect data.   The GPMC is a
programmable parallel-bus memory controller.
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add the HDQ/1-wire hwmod and associated interconnect data.  The
HDQ/1-wire IP block is a low-speed serial interconnect.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>

Add hwmod data for the OMAP4 FDIF IP block.

This patch also includes a change (originally from Fernando Guzman
Lugo <fernando.lugo@ti.com>) to set a softreset delay for the FDIF IP
block:

   http://www.spinics.net/lists/arm-kernel/msg161874.htmlSigned-off-by: NMing Lei <ming.lei@canonical.com>
Acked-by: NBenoît Cousson <b-cousson@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: rearranged to match script output; fixed FDIF end address to
 match script data; wrote trivial changelog; combined the FDIF portion of
 Fernando's srst_udelay patch]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The PRM and CM implicit clockdomains will soon be used by OMAP44xx.
So, make them common to OMAP2+ and modify the OMAP4 clockdomains code
so use of these clockdomains doesn't crash the system.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

N800 logs this message on boot:

[    0.182281] omap_hwmod: iva: cannot be enabled for reset (3)

Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
hwmod for OMAP2430.  There is still more information to be added, but
this should resolve the immediate issue.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The IVA hwmod data is missing some fields that cause the following
warning on boot:

[    0.118011] omap_hwmod: iva: cannot be enabled for reset (3)

Fix by encoding the IP block's main functional clock, reset lines, and
clockdomain.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP3 hwmod data listed iva2_ck as an interface clock between the
IVA and L3.  This is incorrect.  iva2_ck is not an interface clock.
Since it cannot auto-idle, specifying it here prevents the IVA and at
least one of the CORE clockdomains from going idle, which causes PM
problems such as these upon system suspend:

[   70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1
[   70.626190] Powerdomain (core_pwrdm) didn't enter target state 1

Fix by specifying the actual interface clock in the hwmod data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>