The OMAP3 clock code contains some legacy code to allow the MPU rate
to be specified as a kernel command line parameter.  If the 'mpurate'
parameter is specified, the kernel will attempt to switch the MPU rate
to this rate during boot.  As part of this process, a short message
"Switched to new clocking rate" is generated -- and in this message,
the "Core" clock rate and "MPU" clock rate are transposed.

This patch ensures that the clock rates are displayed in the correct
order.

Thanks to Bruno Guerin <br.guerin@free.fr> for reporting this bug and
proposing a fix.  Thanks to Richard Woodruff <r-woodruff2@ti.com> for
reviewing the problem and passing the report on.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Bruno Guerin <br.guerin@free.fr>
Cc: Richard Woodruff <r-woodruff2@ti.com>

Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use
bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505,
etc.).  Superset flags, such as CK_3XXX or CK_AM35XX, are now defined
as disjunctions of individual SoC variant flags.  This simplifies the
definition and use of these flags.  struct omap_clk record definitions
can now simply specify the bitmask of actual SoCs that the records are
valid for.  The clock init code can simply set a single CPU type mask
bit for the SoC that is currently in use, and test against that,
rather than needing to set some combination of flags.

Similarly, clarify the use of struct clksel_rate.flags.  The bit
allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has
been defined as a disjunction of the 34xx and 36xx rate flags.  The
advantages are the same as the above.

Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only
apply to the SoCs that they name, e.g., OMAP34xx chips.  The previous
practice caused significantly different SoCs, such as OMAP36xx, to be
included in CK_34XX.  In my opinion, this is much more intuitive.

Similarly, clarify the use of struct clksel_rate.flags, such that
RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level >= 2
- it does not apply to OMAP36xx.

...

At some point, it probably makes sense to collapse the CK_* and
RATE_IN_* flags together into a single bitfield, and possibly use the
existing CHIP_IS_OMAP* flags for platform detection.

...

This all seems to work fine on OMAP34xx and OMAP36xx Beagle.  Not sure
if it works on Sitara or the TI816X, unfortunately I don't have any
here to test with.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

dss2_fck is a clksel clock, and therefore its rate should be recalculated
with the clksel mechanism.  This was working in early 2009, but was one of
the casualties of the big OMAP clock merge between 2.6.29 and 2.6.30.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The CORE and PER M3 post dividers are different from the rest of the
DPLL post dividers as in they go to SCRM, and are used
there to export clocks for instance used by external sensor.

There is no automatic HW dependency in PRCM to manage them. Hence these
two clocks (dpll post dividers) should be managed by SW and explicitly
enabled/disabled.

Add control in clock framework to handle that.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add support for auxiliary clocks nodes which are part of SCRM.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Add register address, mask and link to the clksel structure that
were missing in the IVA DPLL mux clock node.
Signed-off-by: NJonathan Bergsagel <jbergsagel@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

This patch extends the OMAP4 clock data to include
various x2 clock nodes between DPLL and HS dividers as the
clock framework skips a x2 while calculating the dpll locked
frequency.

The clock database extensions are autogenerated using
the scripts maintained by Benoit Cousson.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NThara Gopinath <thara@ti.com>
[paul@pwsan.com: fixed merge conflicts against v2.6.37-rc5; dropped
 dpll_mpu_x2_ck on advice from Benoît]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

The smartreflex modules belong to an ALWON_FCLK clock domain that
does not have any SW control. The gating of that interface clock
is triggered by a transition of the WKUP clock domain to idle.

Attach both smartreflex instances on OMAP3 to the WKUP clock domain.

The missing clock domain field in srX_fck clock nodes was reported by
Kevin during the discussion about smartreflex on OMAP3:
https://patchwork.kernel.org/patch/199342/Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>

The gating of pad_clks and slimbus_ck is controlled by the PRCM, but
since the clock source is external, this is the SW responsability
to gate / un-gate it when the mcpdm or slimbus module need to be used.
There is no autogating possible with such external clock.

Add SW control to enable / disable this SW gating in the pad_clks_ck
and slimbus_clk clock node.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

Move the padconf save code from pm34xx.c to the System Control Module
code in mach-omap2/control.c.  This is part of the general push to
move direct register access from middle-layer core code to low-level
core code, so the middle-layer code can be abstracted to work on
multiple platforms and cleaned up.

In the medium-to-long term, this code should be called by the mux
layer code, not the PM idle code.  This is because, according to the
TRM, saving the padconf only needs to be done when the padconf
changes[1].
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Tony Lindgren <tony@atomide.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H]
   Section 4.11.4 "Device Off-Mode Sequences"

The OMAP powerdomain code and data is all OMAP2+-specific.  This seems
unlikely to change any time soon.  Move plat-omap/include/plat/powerdomain.h
to mach-omap2/powerdomain.h.  The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access powerdomain code
and data directly.

As part of this process, remove the references to powerdomain data
from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap.
Change the DSPBridge code to point to the new location for the
powerdomain headers.  The DSPBridge code should not be including the
powerdomain headers; these should be removed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>

The OMAP clockdomain code and data is all OMAP2+-specific.  This seems
unlikely to change any time soon.  Move plat-omap/include/plat/clockdomain.h
to mach-omap2/clockdomain.h.  The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access clockdomain code
and data directly.

DSPBridge also uses the clockdomain headers for some reason, so,
modify it also. The DSPBridge code should not be including the
clockdomain headers; these should be removed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Reverse some of the effects of commit
84c0c39a ("ARM: OMAP4: PM: Make OMAP3
Clock-domain framework compatible for OMAP4").  On OMAP2/3, the
CM_CLKSTCTRL register is at a constant offset from the powerdomain's
CM instance.

Also, remove some of the direct CM register access from the
clockdomain code, moving it to the OMAP2/3 CM code instead.  The
intention here is to simplify the clockdomain code.  (The long-term
goal is to move all direct CM register access across the OMAP core
code to the appropriate cm*.c file.)
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Add PRCM partition, CM instance register address offset, and clockdomain
register address offset to each OMAP4 struct clockdomain record.  Add OMAP4
clockdomain code to use this new data to access registers properly.

While here, clean up some nearby clockdomain code to allocate auto variables
in my recollection of Linus's preferred style.

The autogeneration scripts have been updated.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP,
CM_DYNAMICDEP, and the module-specific registers underneath) are
organized by clockdomain.  Add the clockdomain offset macros to the
appropriate PRCM module header files.

This data was almost completely autogenerated from the TI hardware
database; the autogeneration scripts have been updated.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Split _omap2_clkdm_set_hwsup() into _disable_hwsup() and _enable_hwsup().

While here, also document that the autodeps are deprecated and that they
should be removed at the earliest opportunity.

The documentation has been fixed for _{enable,disable}_hwsup(), thanks
to Kevin Hilman <khilman@deeprootsystems.com> for pointing out that those
functions still had placeholder documentation in an earlier patch revision.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

OMAP4 powerdomain control registers are split between the PRM hardware
module and the PRCM_MPU local PRCM.  Add this PRCM partition
information to each OMAP4 powerdomain record, and convert the OMAP4
powerdomain function implementations to use the OMAP4 PRM instance
functions.

Also fixes a potential null pointer dereference of pwrdm->name.

The autogeneration scripts have been updated.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Now that OMAP4-specific PRCM functions have been added, distinguish the
existing OMAP2/3-specific PRCM functions by prefixing them with "omap2_".

This patch should not result in any functional change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Move the OMAP4 global software reset function to the OMAP4-specific
prm44xx.c file, where it belongs.  Part of the long-term process of
moving all of the direct PRCM register writes into lower-layer code.

Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU
will continue executing while the system is supposed to be resetting
itself.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

In some ways, the OMAP4 PRCM register layout is quite different than
the OMAP2/3 PRCM register layout.  For example, on OMAP2/3, from a
register layout point of view, all CM instances were located in the CM
subsystem, and all PRM instances were located in the PRM subsystem.
OMAP4 changes this.  Now, for example, some CM instances, such as
WKUP_CM and EMU_CM, are located in the system PRM subsystem.  And a
"local PRCM" exists for the MPU - this PRCM combines registers that
would normally appear in both CM and PRM instances, but uses its own
register layout which matches neither the OMAP2/3 PRCM layout nor the
OMAP4 PRCM layout.

To try to deal with this, introduce some new functions, omap4_cminst*
and omap4_prminst*.  The former is to be used when writing to a CM
instance register (no matter what subsystem or hardware module it
exists in), and the latter, similarly, with PRM instance registers.
To determine which "PRCM partition" to write to, the functions take a
PRCM instance ID argument.  Subsequent patches add these partition IDs
to the OMAP4 powerdomain and clockdomain definitions.

As far as I can see, there's really no good way to handle these types
of register access inconsistencies.  This patch seemed like the least
bad approach.

Moving forward, the long-term goal is to remove all direct PRCM
register access from the PM code.  PRCM register access should go
through layers such as the powerdomain and clockdomain code that can
hide the details of how to interact with the specific hardware
variant.

While here, rename cm4xxx.c to cm44xx.c to match the naming convention
of the other OMAP4 PRCM files.

Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
<rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

The OMAP3 PRM module is in the WKUP powerdomain, which is always
powered when the chip is powered, so it shouldn't be necessary to save
and restore those PRM registers.  Remove the PRM register save/restore
code, which should save several microseconds during off-mode
entry/exit, since PRM register accesses are relatively slow.

While doing so, move the CM register save/restore code into
CM-specific code.  The CM module has been distinct from the PRM module
since 2430.

This patch includes some minor changes to pm34xx.c.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Kalle Jokiniemi <kalle.jokiniemi@digia.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.

This process also requires the #includes in each of these files to be
changed to reference the new file name.  As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.

Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: NFelipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Back in the OMAP2/3 PRCM interface days, the macros that referred to
the offsets of individual PRM/CM instances from the top of the PRM/CM
hardware modules were incorrectly suffixed with "_MOD".  (They should
have been suffixed with something like "_INST" or "_INSTANCE".)  These
days, now that we have better contact with the OMAP hardware people,
we know that this naming is wrong.  And in fact in OMAP4, there are
actual hardware module offsets inside the instances, so the incorrect
naming gets confusing very quickly for anyone who knows the hardware.

Fix this naming for OMAP4, before things get too far along, by
changing "_MOD" to "_INST" on the end of these macros.  So, for
example, OMAP4430_CM2_INSTR_MOD becomes OMAP4430_CM2_INSTR_INST.

This unfortunately creates quite a large diff, but it is a
straightforward rename.  This patch should not result in any
functional changes.

The autogeneration scripts have been updated accordingly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Add the header file with scrm registers absolute address, offset
and bitfields.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: renamed OMAP4_SCRM to OMAP4_SCRM_BASE]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files
so they match their underlying OMAP hardware modules.  Add clockdomain
offset information.

Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the
SCRM, scrm44xx.h.  SCRM register offsets still need to be added; TI
should do this.

Move the "_MOD" macros out of the prcm-common.h header file, into the
header file of the hardware module that they belong to.  For example,
OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header.

Adjust #includes of all files that used the old PRCM header file names
to point to the new filenames.

The autogeneration scripts have been updated accordingly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

For some reason, the PRCM context save/restore code also saves and
restores a single System Control Module register,
CONTROL_PADCONF_SYS_NIRQ.  This is probably just an error -- the
register should be handled by SCM code -- so this patch moves it
there.

If this register really does need to be saved and restored before the
rest of the PRCM registers, the code to do so should live in the SCM
code, and the PM code should call this separate function.  This
register pertains to devices with a stacked modem, so this patch is
unlikely to affect most OMAP devices out there.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Get rid of the open-coded scratchpad write in mach-omap2/prcm.c and
replace it with an actual API, omap3_ctrl_write_boot_mode().  While
there, get rid of the gratuitous omap_writel().

There's not much documentation available for what should wind up in
the scratchpad here, so more documentation would be appreciated.
Also, at some point, we should formalize our treatment of the scratchpad;
right now, accesses to the scratchpad are not well-documented.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Static data should be declared in .c files, not .h files.  It should be
possible to #include .h files at any point without creating multiple
copies of the same data.

We converted the clock data to .c files some time ago.  This patch does
the same for the clockdomain data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Static data should be declared in .c files, not .h files.  It should be
possible to #include .h files at any point without creating multiple
copies of the same data.

We converted the clock data to .c files some time ago.  This patch does
the same for the powerdomain data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Like OMAP3, OMAP4430 ES2 has additional bitfields in PWRSTST register
which help identify the previous power state entered by the
powerdomain.  Add pwrdm_clear_all_prev_pwrst to the OMAP4 powerdomains
implementation to support this.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: clarified commit message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_mem_onst
.pwrdm_set_mem_retst
.pwrdm_read_mem_pwrst
.pwrdm_read_prev_mem_pwrst
.pwrdm_read_mem_retst
.pwrdm_clear_all_prev_pwrst
.pwrdm_enable_hdwr_sar
.pwrdm_disable_hdwr_sar
.pwrdm_wait_transition
.pwrdm_set_lowpwrstchange

Convert the platform-independent framework to call these functions.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: rearranged Makefile changes]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_logic_retst
.pwrdm_read_logic_pwrst
.pwrdm_read_prev_logic_pwrst
.pwrdm_read_logic_retst

Convert the platform-independent framework to call these functions.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_next_pwrst
.pwrdm_read_next_pwrst
.pwrdm_read_pwrst
.pwrdm_read_prev_pwrst

Convert the platform-independent framework to call these functions.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: remove remaining static allocations in powerdomains.h file;
 remove path in file header comments, rearranged Makefile changes]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

powerdomains.h header today has only static definitions.  Adding any
function declarations into it and including it in multiple source file
is expected to cause issues.  Hence move all the static definitions
from powerdomains.h file into powerdomains_data.c file.

Also, create a new powerdomain section of the mach-omap2/Makefile, and
rearrange the prcm-common part of the Makefile, now that the
powerdomain code is in its own Makefile section.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: rearrange Makefile changes, tweaked commit message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NRajendra Nayak <rnayak@ti.com>

The OMAP watchdog timer IP blocks require a specific set of register
writes to occur before they will be disabled[1], even if the device
clocks appear to be disabled in the CM_*CLKEN registers.  In the MPU
watchdog case, failure to execute this reset sequence will eventually
cause the watchdog to reset the OMAP unexpectedly.

Previously, the code to disable this watchdog was manually called from
mach-omap2/devices.c during device initialization.  This causes the
watchdog to be unconditionally disabled for a portion of kernel
initialization.  This should be controllable by the board-*.c files,
since some system integrators will want full watchdog coverage of
kernel initialization.  Also, the watchdog disable code was not
connected to the hwmod shutdown code.  This means that calling
omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the
goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip
OMAP device.

To resolve the latter problem, populate the pre_shutdown pointer in
the watchdog timer hwmod classes with a function that executes the
watchdog shutdown sequence.  This allows the hwmod code to fully
disable the watchdog.

Then, to allow some board files to support watchdog coverage
throughout kernel initialization, add common code to mach-omap2/io.c
to cause the MPU watchdog to be disabled on boot unless a board file
specifically requests it to remain enabled.  Board files can do this
by changing the watchdog timer hwmod's postsetup state between the
omap2_init_common_infrastructure() and omap2_init_common_devices()
function calls.

1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH
   [SWPU222H], Section 16.4.3.6, "Start/Stop Sequence for WDTs (Using
   WDTi.WSPR Register)"
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Charulatha Varadarajan <charu@ti.com>

Split the wd_timer disable code out into its own file,
mach-omap2/wd_timer.c; it belongs in its own file rather than
cluttering up devices.c.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Charulatha Varadarajan <charu@ti.com>

Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).

Identifying if a module has lost context requires atleast one
register read, and since a register read has more latency than
a write, it makes sense to do a blind write always.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

Trivial cleanup and documentation changes on the hwmod code and data:

- add some hwmod documentation to indicate flags that should be moved
  outside the static hwmod data in a future patch

- remove some unused fields in the struct omap_hwmod_ocp_if and
  struct omap_hwmod structures
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Change the per-hwmod mutex to a spinlock.  (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.)  Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR.  The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.

This patch also effectively reverts commit
84824022 - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions.  Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.

Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
patch - thanks Kevin.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoît Cousson <b-cousson@ti.com>