Commit 9890ce44 (ARM: get rid of asm/irq.h in asm/prom.h)
removed include of asm/irq.h in asm/prom.h. This commit
together with recent omap cleanup to remove io.h causes
build breakage:
arrch/arm/mach-omap2/control.c: In function 'omap3_ctrl_write_boot_mode':
arch/arm/mach-omap2/control.c:238: error:
'OMAP343X_CTRL_BASE' undeclared (first use in this function)
...
Fix this by including hardware.h directly where needed
instead of relying on asm/irq.h in asm/prom.h.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
There's no need to have these defines in plat/io.h.
Note that we now need to ifdef omap_read/write calls
as they will be available for omap1 only.
While at it, clean up the includes to group them like
they typically are grouped.
Signed-off-by: Tony Lindgren <tony@atomide.com>
As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>,
there's no need to keep local prototypes in non-local headers.
Add mach-omap1/common.h and mach-omap2/common.h and move the
local prototypes there from plat/common.h and mach/omap4-common.h.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As per OMAP3 erratum (i671), ROM code adds extra latencies while
restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1.
This patch stores 0's in scratchpad content area corresponding to
AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since
it won't respect proper programing scheme.
This register is then stored in prcm context. The saving and restore
is now done by kernel side.
Here follow the erratum description
DESCRIPTION
After OFF mode transition, among many restorations, the ROM Code restores the
CM_AUTOIDLE_PLL register, and after that, it tries to relock the PER DPLL.
In case the restoration data stored in scratchpad memory contains a field
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM Code restores and
locks the PER DPLL does not respect the PER DPLL programming scheme.
In that case, the DPLL might not lock. Meanwhile, when trying to lock the PER
DPLL, the ROM Code does not hang. Only extra latencies are introduced at
wake-up.
WORKAROUND
When saving the context-restore structure in scratchpad memory, in order to
respect the PER DPLL programming scheme, it is advised to store 0 in the
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL field of the saved structure.
After wake-up, the application should store in CM_AUTOIDLE_PLL register the
right desired value.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
OMAP2xxx devices have two on-chip APLLs. These APLLs can
automatically enter idle when not in use. Connect the APLL autoidle
code to the clock code, so that the clock framework can handle this
process. As part of this patch, remove the code in mach-omap2/pm24xx.c
that previously handled APLL autoidle control.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Add the necessary code and data to allow the clock framework to enable
and disable the OMAP2 DPLL autoidle state. This is so the direct
register access can be moved out of the mach-omap2/pm24xx.c code, and other
code that needs to control this (e.g., CPUIdle) can do so via an API.
As part of this patch, remove the pm24xx.c code that formerly wrote
directly to the autoidle bits.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reverse some of the effects of commit
84c0c39aec ("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: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@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: Paul 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: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Rajendra Nayak <rnayak@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: Paul 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: 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>
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>
