ARM: OMAP2+: Drop unused PRM defines for omap4

These are unused and should be handled by drivers/soc/ti/omap_prm.c
driver nowadays.

Signed-off-by: Tony Lindgren <tony@atomide.com>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

ARM: OMAP2+: PRM: move SoC specific init calls within a generic API

This gets rid of need for some exported driver APIs, and simplifies the
initialization of the PRM driver. Done in preparation to m

ARM: OMAP2+: PRM: move SoC specific init calls within a generic API

This gets rid of need for some exported driver APIs, and simplifies the
initialization of the PRM driver. Done in preparation to make PRM a
separate driver. The init data is now also passed to the SoC specific
implementations, allowing future expansion to add feature flags etc.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

show more ...

ARM: OMAP4+: PRM: Move function prototypes to common header for re-use

OMAP5 reuses OMAP4 PRM IP block which lets us re-use PRM functions.
So move the function prototypes from prm44xx.h to prm44xx_5

ARM: OMAP4+: PRM: Move function prototypes to common header for re-use

OMAP5 reuses OMAP4 PRM IP block which lets us re-use PRM functions.
So move the function prototypes from prm44xx.h to prm44xx_54xx.h
header. The suggestion came from Paul Walmsley as part of the
OMAP5 data file review.

This is preparatory patch to add OMAP5 PRM data file.

Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets

RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
OMAP4460.

Signed-off-by: Nishanth Menon <nm@ti.com>
[ivan.khoronzhuk@ti.com: ported fr

ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets

RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
OMAP4460.

Signed-off-by: Nishanth Menon <nm@ti.com>
[ivan.khoronzhuk@ti.com: ported from k3.4]
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

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

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>

show more ...

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

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>

show more ...

ARM: OMAP4: PRM: Add IO Daisychain support

IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows

ARM: OMAP4: PRM: Add IO Daisychain support

IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows the hardware module behind the pad to be powered down, but
still have device level capability to detect IO events, and once this
happens the module can be powered back up to resume IO. See section
3.9.4 in OMAP4430 Public TRM for details.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use the shared MAX_IOPAD_LATCH_TIME declaration; renamed
omap4_trigger_io_chain() to conform to other PRM function names;
added kerneldoc; resolved checkpatch warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

ARM: OMAP: PRCM: add suspend prepare / finish support

PRCM chain handler needs to disable forwarding of interrupts during
suspend, because runtime PM is disabled and most of the drivers
are potentia

ARM: OMAP: PRCM: add suspend prepare / finish support

PRCM chain handler needs to disable forwarding of interrupts during
suspend, because runtime PM is disabled and most of the drivers
are potentially not able to handle interrupts coming at this time.

This patch masks all the PRCM interrupt events if a PRCM interrupt
occurs during suspend, but does not ack them. Once suspend finish
is called, all the masked events will be re-enabled, which causes
immediate PRCM interrupt and handles the postponed event.

The suspend prepare and complete callbacks will be called from
pm34xx.c / pm44xx.c files in the following patches.

The functions defined in this patch should eventually be moved to
suspend->prepare and suspend->finish driver hooks, once the PRCM
chain handler will be made as its own driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: add kerneldoc, add omap_prcm_irq_setup.saved_mask, add fn
ptrs for save_and_clear_irqen() and restore_irqen()]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrier

Add PRM functions to test for pending PRM IRQs. This will be used in
a subsequent patch to implement the PRM interrupt handler on

ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrier

Add PRM functions to test for pending PRM IRQs. This will be used in
a subsequent patch to implement the PRM interrupt handler on the MPU.

Add PRM functions to ensure that all outstanding writes from the MPU
to the PRM IP block have completed before continuing execution. This
will be used in a subsequent patch to ensure that all PRM interrupt
status bits are cleared in the hardware before exiting the ISR.
Normally we would not expose such a low-level function to other code.
But the current implementation of the PRM interrupt code, which uses
the generic IRQ chip code, doesn't give us a choice.

The pending PRM IRQ functions are based on code originally written by
Tero Kristo <t-kristo@ti.com>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>

show more ...

OMAP2+: PRM: add register access functions for VC/VP

On OMAP3+, the voltage controller (VC) and voltage processor (VP) are
inside the PRM. Add some PRM helper functions for register access to
these

OMAP2+: PRM: add register access functions for VC/VP

On OMAP3+, the voltage controller (VC) and voltage processor (VP) are
inside the PRM. Add some PRM helper functions for register access to
these module registers.

Thanks to Nishanth Menon for finding/fixing a sparse problem.

Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>

show more ...

OMAP2+: add PRM VP functions for checking/clearing VP TX done status

Add SoC specific PRM VP helper functions for checking and clearing
the VP transaction done status.

Longer term, these events sho

OMAP2+: add PRM VP functions for checking/clearing VP TX done status

Add SoC specific PRM VP helper functions for checking and clearing
the VP transaction done status.

Longer term, these events should be handled by the forthcoming PRCM
interrupt handler.

Signed-off-by: Kevin Hilman <khilman@ti.com>

show more ...

OMAP4: prm: Remove deprecated functions

The new prminst_xxx accessors based on partition and offset
is now used, so removed all the previous prcm_xxx accessors.

Signed-off-by: Benoit Cousson <b-cou

OMAP4: prm: Remove deprecated functions

The new prminst_xxx accessors based on partition and offset
is now used, so removed all the previous prcm_xxx accessors.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: remove fn prototypes also]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

OMAP4: prm: Replace warm reset API with the offset based version

The warm reset function was still using the obsolete API.
Replace it by the new one and move the file to the proper c file.

Change t

OMAP4: prm: Replace warm reset API with the offset based version

The warm reset function was still using the obsolete API.
Replace it by the new one and move the file to the proper c file.

Change the function names to stick to the file convention as
suggested by Paul Walmsley <paul@pwsan.com>:
prm_xxx -> prminst_xxx

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros

The RSTCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physica

OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros

The RSTCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of an offset will allow future improvement like migration from
the current architecture code toward a module driver.

Update prm_xxx accessors, move definition to the proper header file and
update copyrights.
Change the s16 register offset parameter to u16.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: use '_prminst_' in function names that are part of the
prminst44xx.c file]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

OMAP4: prm: Remove wrong clockdomain offsets

The following commit introduced new macros to define an offset
per clock domain in an instance.

commit e4156ee52fe617c2c2d80b5db993ff4bf07d7c3c

OMA

OMAP4: prm: Remove wrong clockdomain offsets

The following commit introduced new macros to define an offset
per clock domain in an instance.

commit e4156ee52fe617c2c2d80b5db993ff4bf07d7c3c

OMAP4: CM instances: add clockdomain register offsets

The PRM contains only two clock controls management entities:
EMU and WKUP.
Remove the other ones.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

OMAP4: prcm: Fix errors in few defines name

A couple of macros were wrongly changed during the _MOD to _INST
rename done in the following commit:

OMAP4: PRCM: rename _MOD macros to _INST
cdb54c

OMAP4: prcm: Fix errors in few defines name

A couple of macros were wrongly changed during the _MOD to _INST
rename done in the following commit:

OMAP4: PRCM: rename _MOD macros to _INST
cdb54c4457d68994da7c2e16907adfbfc130060d

Fix them to their original name.

Some CM and PRM instances were not well aligned. Align them.

Remove one blank line in cm2_44xx.h to align the output with
the other (cm1_44xx.h, prm44xx.h) files.

Update header copyright date.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...

OMAP4: CM instances: add clockdomain register offsets

In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP,
CM_DYNAMICDEP, and the module-specific registers underneath) are
organized by

OMAP4: CM instances: add clockdomain register offsets

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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

show more ...

OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file

Move the OMAP4 global software reset function to the OMAP4-specific
prm44xx.c file, where it belongs. Part of the long-te

OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file

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: Paul Walmsley <paul@pwsan.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>

show more ...

OMAP4: PRCM: add OMAP4-specific accessor/mutator functions

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
reg

OMAP4: PRCM: add OMAP4-specific accessor/mutator functions

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: Paul 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>

show more ...

OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files

In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/

OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files

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: Paul 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: Omar Ramirez Luna <omar.ramirez@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

show more ...

OMAP4: PRCM: rename _MOD macros to _INST

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 w

OMAP4: PRCM: rename _MOD macros to _INST

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: Paul 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: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>

show more ...

OMAP4: PRCM: reorganize existing OMAP4 PRCM header files

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

OMAP4: PRCM: reorganize existing OMAP4 PRCM header files

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: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

show more ...

OMAP4: PM: Define additional registers for ES2

4430 ES2 has a few new registers added and a few modified
from ES1. This patch adds all the register changes in PRM
and CM for OMAP4430 ES2.

Signed-of

OMAP4: PM: Define additional registers for ES2

4430 ES2 has a few new registers added and a few modified
from ES1. This patch adds all the register changes in PRM
and CM for OMAP4430 ES2.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>

show more ...

OMAP4: PRCM: Add offset defines for all PRM registers

The prm44xx.h files only had absolute register address
defines for all PRM registers.
This patch adds additional register offset defines for all

OMAP4: PRCM: Add offset defines for all PRM registers

The prm44xx.h files only had absolute register address
defines for all PRM registers.
This patch adds additional register offset defines for all the
registers, so they can be used with apis like prm_read_mod_*

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

show more ...