History log of /arch/arm/mach-omap2/prm3xxx.c
Revision Date Author Comments
7db143b89137de06ed289cf8b302f3bbbc5baa1f 17-Sep-2014 Tony Lindgren <tony@atomide.com> ARM: OMAP3: Fix I/O chain clock line assertion timed out error

We are getting "PRM: I/O chain clock line assertion timed out" errors
on early omaps for device tree based booting. This is because we are
unconditionally calling reconfigure_io_chain while legacy booting
has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c.

For device tree based booting, we are calling reconfigure_io_chain
unconditionally from pinctrl framework. So we need to add a check for
omap3_has_io_chain_ctrl() to avoid the errors for trying to access
a register that does not exist.

For es3.0, the documentation in "4.11.2 Device Off-Mode Configuration"
just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in
documentation for "4.11.2.2 I/O Wake-Up Mechanism" that describes the
PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get
added until in es3.1 probaly to fix issues with flakey wake-up events.

We are doing proper checks for ST_IO_CHAIN already in id.c and with
omap3_has_io_chain_ctrl(). For more information, see also commit
b02b917211d5 ("ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock
control detection").

Let's fix the issue by selecting the right function during init for
reconfigure_io_chain depending on the omap revision. For es3.0 and
earlier we need to just toggle EN_IO. By doing this, we can move the
check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code
in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain.

Thanks to Paul Walmsley and Nishanth Menon for help with debugging the
issue.

Fixes: 30a69ef785e8 ("ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap")
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
1e037794f7f00ff464db446ace892dae84175a6a 12-Aug-2014 Nishanth Menon <nm@ti.com> ARM: OMAP3+: PRM: register interrupt information from DT

Allow the PRM interrupt information to be picked up from device tree.
OMAP3 may use legacy boot and needs to be compatible with old dtbs
(without interrupt populated), for these, we use the value which is
pre-populated.

Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ba12c24286296159a1271eb19f2fc5c2ef59fbde 04-Mar-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: control: isolate control module init to its own function

Control module related PM initializations are now moved within control
module driver. Done in preparation to isolate the code to its own driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
c2148e5930cdd2dd964e18fb7057c1e07f63c363 04-Mar-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: PRM: move modem reset and iva2 idle to PRM driver

Done in preparation to move PRM into its own driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
c5180a2b3e26d9b82277986f830c89a50103e65a 26-Feb-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: PRM: move PRM init code from PM core to the driver

Helps to isolate the PRM driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
7e28b465fdea3f0601a1c76e47c50d05c7c603e2 25-Feb-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: PRM: add API for saving PRM scratchpad contents

This isolates the PRM register access within the PRM driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
9efcea09b0b56488e46ab3a36fe8dbce9eded529 26-Feb-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: PRM: add API for checking and clearing cold reset status

This isolates the PRM register access within the PRM driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
55c6c3ad90f606d458d798b36f8ffca98c1894e0 04-Mar-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: PRM: move modem reset to PRM driver

This is a more proper isolation of the code. Done in preparation of making
PRM an individual driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
9de367fae0d9907e19d065e0381ecd3f4003e08f 25-Feb-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: PRM: move iva reset to PRM driver

This is a more proper isolation of the code. Done in preparation of making
PRM an individual driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
0efc0f6ec2d6c6497e401df171705c5762f5a061 25-Feb-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3: PRM: move prcm wakeup helper to prm driver

Done in preparation to make the prm an individual driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
b550e47f5e9e74999f754371bdc79331d19f84a3 31-Mar-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3/4: PRM: add support of late_init call to prm_ll_ops

SoC specific late_init call is now registered during PRM init, and will
be called automatically by PRM core. This helps to get rid of some
redundant initcalls and cpu_is_X checks from the PRM code.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2541d15f16479fd56debe1ea55dee03c3886e33c 31-Mar-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3/OMAP4: PRM: add prm_features flags and add IO wakeup under it

prm_features flag will contain SoC specific feature enabler flags. Initially
IO wakeup is added under this. Helps to get rid of runtime cpu_is_X checks.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
81243651ba25c4418af26c3c6f1aeabb41f734e0 31-Mar-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP3/4: PRM: provide io chain reconfig function through irq setup

This helps to make the PRM registration modular, and also gets rid of a
cpu type check done later.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
d8871cd245ece932ced994457e044d0f68b0aab4 12-May-2014 Tero Kristo <t-kristo@ti.com> ARM: OMAP2+: PRM: remove unnecessary cpu_is_XXX calls from prm_init / exit

Done in preparation to make PRM its own driver, as the cpu_is_XXX calls are
not available outside mach-omap2 folder.

The init functions are called only from cpu specific init chain, and thus
don't need to double check against cpu type.

The exit calls check against the data provided during init-time registration
and thus don't need cpu check either.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
b76c8b19b082c3fc84725de0d3ba5ee1f571c0ae 11-Jan-2013 Tony Lindgren <tony@atomide.com> ARM: OMAP2+: Use omap initcalls

This way the initcalls don't run on other SoCs on multiplatform
kernels. Otherwise we'll get something like this when booting
on vexpress:

omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
...
WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
_init_omap_device: could not find omap_hwmod for mpu
...
omap-dma-engine omap-dma-engine: OMAP DMA engine driver
...

Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
7e7fff8254e318cede06a1a8c55b0d86dd4d8c5b 28-Dec-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2/3: PRM: fix bogus OMAP2xxx powerstate return values

On OMAP2xxx chips, the register bitfields for the
PM_PWSTCTRL_*.POWERSTATE and PM_PWSTST_*.LASTSTATEENTERED are
different than those used on OMAP3/4. The order is reversed. So, for
example, on OMAP2xxx, 0x0 indicates 'ON'; but on OMAP3/4, 0x0
indicates 'OFF'. Similarly, on OMAP2xxx, 0x3 indicates 'OFF', but on
OMAP3/4, 0x3 indicates 'ON'.

To fix this, we treat the OMAP3/4 values as the powerdomain API
values, and create new low-level powerdomain functions for the
OMAP2xxx chips which translate between the OMAP2xxx values and the
OMAP3/4 values.

Without this patch, the conversion of the OMAP2xxx PM code to the
functional powerstate code results in a non-booting kernel.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
e8d3d47a98cd7184a86d58febc00b4ac47485332 16-Dec-2012 Tony Lindgren <tony@atomide.com> ARM: OMAP2+: Drop plat/cpu.h for omap2plus

The cpu_is_omap macros are now local to arch/arm/mach-omap2
in soc.h and plat/cpu.h can finally be dropped for omap2+.
Thanks everybody for help with fixing the drivers.

Note that we can now also remove the unused plat/cpu.h from
smartreflex.c and isp.c as they will cause compile errors
with ARCH_MULTIPLATFORM enabled.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Jean Pihet <jean.pihet@newoldbits.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
63a293e0005eb86c76657256737a931add8acbdc 22-Nov-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2+: PRM: initialize some PRM functions early

Some PRM functions will need to be called by the hwmod code early in
kernel init. To handle this, split the PRM initialization code into
early and late phases. The early init is handled via mach-omap2/io.c,
while the late init is handled by subsys_initcall().

Signed-off-by: Paul Walmsley <paul@pwsan.com>
b99db36cdf37decb1b5575c5f293d170cbbc53d6 30-Oct-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2+: PRCM: remove obsolete prcm.[ch]

arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h
are now completely unused and can be removed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
d08cce6a1d6952a7774e4b61066d469c16d47a11 30-Oct-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)

Add SoC reset functions into the PRM code. These functions are based
on code from mach-omap2/prcm.c. They reset the SoC using the CORE DPLL
reset method (as opposed to one of the other two or three chip reset
methods).

Adding them here will facilitate their removal from
arch/arm/mach-omap2/prcm.c. (prcm.c is deprecated.)

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2bb2a5d30abb0dc99d074877bfad2056142c730b 21-Oct-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver

The OMAP watchdog timer driver needs to determine what caused the SoC
to reset for its GETBOOTSTATUS ioctl. So, define a set of standard
reset sources across OMAP SoCs. For OMAP2xxx, 3xxx, and 4xxx SoCs,
define mappings from the SoC-specific reset source register bits to
the standardized reset source IDs. Create SoC-specific PRM functions
that read the appropriate per-SoC register and use the mapping to
return the standardized reset bits. Register the SoC-specific PRM
functions with the common PRM code via prm_register(). Create a
function in the common PRM code, prm_read_reset_sources(), that
calls the SoC-specific function, registered during boot.

This patch does not yet handle some SoCs, such as AM33xx. Those SoCs
were not handled by the code this will replace.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
498153995b9ff41279be54fc56facb92f5cad793 21-Oct-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions into PRM

Move the low-level SoC-specific powerdomain control functions into
prm*.c. For example, OMAP2xxx low-level powerdomain functions go into
prm2xxx.c. Then remove the unnecessary powerdomain*xxx*.c files.

The objective is to centralize low-level PRM register accesses into
the prm*.[ch] files, and then to export an OMAP SoC-independent API to
higher-level OMAP power management code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
139563ad27e7baad7935b8113940f0d804cf513b 21-Oct-2012 Paul Walmsley <paul@pwsan.com> ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files

Move OMAP3xxx-specific PRM functions & macros into prm3xxx.[ch] and
OMAP2xxx-specific macros into prm2xxx.h. (prm2xxx.c will be created
by a subsequent patch when it's needed.) Move basic PRM register
access functions into static inline functions in prm2xxx_3xxx.h, leaving
only OMAP2/3 hardreset functions in prm2xxx_3xxx.c.

Also clarify the initcall function naming to reinforce that this code
is specifically for the PRM IP block.

This is in preparation for the upcoming powerdomain series and the
upcoming move of this code to drivers/.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>