The HW superwised smart idle for wdtimer in OMAP3 prevents
CORE power domain idle transitions. Disable it by swithing
to SW supervised transitions.
This could be a hardware bug in the OMAP3 wdtimer2 block.
Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
The omap_wdt should only be in full active state when the
registers are being accessed. Otherwise the device can be
on lower power mode.
This patch is based on a patch created by Kalle Jokiniemi:
https://patchwork.kernel.org/patch/618231/
which is itself based on a patch created by Atal
Shargorodsky: http://lkml.org/lkml/2009/3/10/266.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com>
Tested-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Acked-by: Wim Van Sebroeck <wim@iguana.be>
Acked-by: Kevin Hilman <khilman@ti.com>
This saves some power. OMAP4 version should check for GPT module ID, as
autoidle is only supported on a subset of these.
Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Add a new clockdomain flag, CLKDM_NO_AUTODEPS, which, when marked on a
clockdomain, will prevent "autodeps" from being associated with the
clockdomain. ("Autodeps" are sleep dependencies and wakeup
dependencies from/to processor modules that are automatically added to
a clockdomain when it is in hardware-supervised idle mode. They are
deprecated -- a relic from the old CDP trees -- but are still in use
for OMAP3.)
Also, prevent the hwmod code from adding or removing initiator
dependencies for clockdomains with this flag set.
This patch should allow others to test which clockdomains actually
still need autodeps.
Thanks to Kevin Hilman <khilman@ti.com> for noting that the original
version should also modify the hwmod code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Create a new API that forms a wrapper to _set_module_autoidle()
to modify the AUTOIDLE bit.
This API is intended to be used by drivers that requires direct
manipulation of the AUTOIDLE bits in SYSCONFIG register.
McBSP driver requires autoidle bit to be enabled/disabled while
using sidetone feature.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: restrict the hwmod states that the autoidle bit can be changed
in; changed function name; dropped "int" from "unsigned int long"]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some boards can't tolerate IP blocks being reset when they are initialized.
Michael Büsch cites a case with the Nokia N810:
http://www.spinics.net/lists/linux-omap/msg47277.html
To allow such boards to continue working normally, allow board file
maintainers to mark IP blocks to prevent them from being reset upon
init. This is done via a hwmod function, omap_hwmod_no_setup_reset().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Michael Buesch <mb@bu3sch.de>
On OMAP2 and OMAP3 the reset ctrl shift doesn't match the
status bit, as it does on OMAP4, when handling the reset lines.
This patch adds a new member in the reset info structure, so now it
can be added as part of hwmod data, and checked accordingly for
OMAP2 or 3; otherwise, there could be cases when the shift masks
doesn't match both of the registers, and a successful reset might
throw an error message or vice versa.
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
[paul@pwsan.com: added a warning if st_shift used on OMAP4; renamed 'r'
variable; improved some documentation]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
_init_clock always returns 0 and does
not propogate the error (in case of failure)
back to the caller, causing _init_clocks to
fail silently.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some of the omap2, omap3 peripherals support software reset. This
can be done through the softreset bit in sysconfig register.
The reset status can be checked through resetdone bit of
sysstatus register. syss_has_reset_status is added to the hwmod
database of peripherals which have resetdone bit in sysstatus register.
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Reviewed-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Avinash.H.M <avinashhm@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Autoidle is a single bit, TIOCP_CFG[0], setting on OMAP1/2/3/4 platforms.
In _set_module_autoidle() I am seeing 0x3 value where the mask is computed.
This should be 0x1.
v2:
(1) Modified the subject.
(2) Modified the description with further specific information.
Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tested Info:
Boot tested on OMAP 1/2/3/4.
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Master ports from interconnect are generating some annoying circular
references that become tricky to handle if we have to dynamically
remove some IP on some variant platforms.
Since they are not used for the moment, and since we can still build
that relation using the reverse relation (slave port from the IP
toward master port of the interconnect), let remove them for the
moment like it is done on OMAP4.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Commit d344272671 ("OMAP3: PM: Adding
smartreflex hwmod data") added data that claims that the L4 CORE has
two slave interfaces that originate from the SmartReflex modules,
omap3_l4_core__sr1 and omap3_l4_core__sr2. But as those two data
structure records show, it's L4 CORE that has a master port towards
SR1 and SR2.
Move the incorrect data from slaves list to master list.
Based on a path by Paul Walmsley <paul@pwsan.com>
https://patchwork.kernel.org/patch/623171/
That is based on a patch by Benoît Cousson <b-cousson@ti.com>:
https://patchwork.kernel.org/patch/590561/
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Add Rajendra Nayak and myself as maintainers for the OMAP
powerdomain/clockdomain per-SoC layer code.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
if building kernels without OMAP2 support, we
will see a warning such as:
arch/arm/mach-omap2/io.c: In function 'omap2_init_common_infrastructure':
arch/arm/mach-omap2/io.c:389:3: warning: statement with no effect
arch/arm/mach-omap2/io.c:391:3: warning: statement with no effect
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
According to the hwmod interface data, the DSS submodule "VENC" uses a
clock, "dss_54m_fck"/"dss_tv_fck", which the PRCM cannot autoidle. By
default, the hwmod code assumes that interface clocks can be autoidled
by the PRCM. When the interface clock can't be autoidled by the PRCM,
those interfaces must be marked with the OCPIF_SWSUP_IDLE flag.
Otherwise, the "interface clock" will always have a non-zero use
count, and the device won't enter idle. This problem was observed on
N8x0.
Fix the immediate problem by marking the VENC interface with the
OCPIF_SWSUP_IDLE flag. But it's not clear that
"dss_54m_fck"/"dss_tv_fck" is really the correct interface clock for
VENC. It may be that the VENC interface should use a
hardware-autoidling interface clock. This is the situation on OMAP4,
which uses "l3_div_ck" as the VENC interface clock, which can be
autoidled by the PRCM. Clarification from TI is needed.
Problem found and patch tested on N8x0 by Tony Lindgren
<tony@atomide.com>.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
Cc: Sumit Semwal <sumit.semwal@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The driver provides the information regarding the ocp errors
that gets logged in the interconnect. The error information
gives the detail regarding the target that was attempted
to be accessed and its corresponding address.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
The l3 interconnect device is build with all the data required
to handle the error logging. The data is extracted from the
hwmod data base.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: sricharan <r.sricharan@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Add the address spaces, irqs of the l3 interconnect to the
hwmod data. The hwmod change is aligned with Benoit Cousson.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: sricharan <r.sricharan@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
The driver provides the information regarding the ocp errors
that gets logged in the interconnect.The error info provides
the details regarding the master or the target that
generated the error, type of error and the corresponding address.
The stack dump is also provided.
Signed-off-by: sricharan <r.sricharan@ti.com>
[r.sricharan@ti.com: Enhacements, major cleanup and made it functional]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[santosh.shilimkar@ti.com: Driver design changes as per OMAP4 version]
Signed-off-by: Felipe Balbi <balbi@ti.com>
[balbi@ti.com: Initial version of the driver]
Acked-by: Benoit Cousson <b-cousson@ti.com>
The l3 interconnect device is build with all the data required
to handle the error logging. The data is extracted from the
hwmod database.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Add the address spaces, irqs of the l3 interconnect to the
hwmod data. The hwmod changes are aligned with Benoit Cousson.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
The i2c_board_info entry supporting AIC23 codec was added into
the i2c2 bus.
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit 3cf32bba8c ("OMAP: McBSP: Convert
McBSP to platform device model") breaks compilation with non-multi-OMAP1
configs:
CC arch/arm/mach-omap1/mcbsp.o
arch/arm/mach-omap1/mcbsp.c: In function 'omap1_mcbsp_init':
arch/arm/mach-omap1/mcbsp.c:384: warning: dereferencing 'void *' pointer
arch/arm/mach-omap1/mcbsp.c:387: error: invalid use of void expression
arch/arm/mach-omap1/mcbsp.c:390: warning: dereferencing 'void *' pointer
arch/arm/mach-omap1/mcbsp.c:393: error: invalid use of void expression
Fix by avoiding NULL dereferences.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
[tony@atomide.com: updated description not to remove unnecessary branch name]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add a clockdomain to the GPTIMER7 interface and 2430 HSMMC2 functional
clocks - both were previously missing them.
Also, the 2430 mmchs1_fck is in core_l3_clkdm, but should be in
core_l4_clkdm; fix this.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This patch fixes these warnings when building kernel for OMAP3EVM
only.
CC arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.o
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:95: warning:
'dsp_24xx_wkdeps' defined but not used
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:119: warning:
'mpu_24xx_wkdeps' defined but not used
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:147: warning:
'core_24xx_wkdeps' defined but not used
The problem should be noticed when building for other OMAP3
platforms (only) as well.
Signed-off-by: Sanjeev Premi <premi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
After commit 81b34fbecb ("OMAP2 clock:
split OMAP2420, OMAP2430 clock data into their own files"), it's
possible to remove dsp_irate_ick from the OMAP2420 and OMAP2430 clock
files. It was originally only needed due to a 2420/2430 clock tree difference,
and now that the data is in separate files, it's superfluous.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Remove the DPLL rate tolerance code that is called during rate
rounding. As far as I know, this code is never used, since it's been
more important for callers of the DPLL round_rate()/set_rate()
functions to obtain an exact rate than it is to save a relatively
small amount of power.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Bail out before we take the clockfw_lock spinlock if the corresponding
OMAP1 or OMAP2+ clock function is not defined. The intention is to
reduce and simplify the work that is done inside the spinlock.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The parent of the interface clocks for GPTIMER1, MPU_WDT,
SYNCTIMER_32K, SCM, WDT1, and the ICR (2430 only) were all listed as
being l4_ck. This isn't accurate; these modules exist inside the WKUP
domain, and the interface clock to these modules runs at the SYS_CLK
rate rather than the CORE L4 rate.
So, create a new clock "wu_l4_ick", similar to the OMAP3
"wkup_l4_ick", that serves as the parent for these clocks.
Also, these clocks were listed as existing inside core_l4_clkdm;
wkup_clkdm is probably more accurate.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The OMAP2420/2430 external 32-kHz low-frequency oscillator is a 32768
Hz oscillator, not a 32,000 Hz oscillator[1][2]. Fix this in the clock
tree.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
1. OMAP2420/22 Multimedia Processor Data Manual, Version P [SWPS019P],
section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to
a "32.768-kHz" clock; this presumably should be "32.768-KHz")
2. OMAP2430 Multimedia Processor ES2.1 Data Manual, Version V [SWPS023V],
section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to
a "32.768-kHz" clock; this presumably should be "32.768-KHz")
Several clocks are listed as having the core L4 clock as their parent,
when they are actually derived from the L3 clock. Fix these.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
These CM_AUTOIDLE bits are now set by the clock code via the common PM
code in mach-omap2/pm.c.
N.B.: The pm24xx.c code that this patch removes didn't ensure that the
CM_AUTOIDLE bits were set for several 2430-only modules, such as
GPIO5, MDM_INTC, MMCHS1/2, the modem oscillator clock, and USBHS.
Similarly, the pm34xx.c code that this patch removes didn't ensure
that the CM_AUTOIDLE bits were set for USIM and the AM3517 UART4.
Those cases should now be handled.
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>
Mark each interface clock with a corresponding CM_AUTOIDLE bit with
a clkops that has the allow_idle/deny_idle function pointers populated.
This allows the OMAP clock framework to enable and disable autoidle for
these clocks.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Mark each interface clock with a corresponding CM_AUTOIDLE bit with
a clkops that has the allow_idle/deny_idle function pointers populated.
This allows the OMAP clock framework to enable and disable autoidle for
these clocks.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
OMAP2430 and OMAP3xxx have modem autoidle bits that are actually
attached to clocks with CM_FCLKEN bits; add the code and data to
handle these.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Mark each interface clock with a corresponding CM_AUTOIDLE bit with
a clkops that has the allow_idle/deny_idle function pointers populated.
This allows the OMAP clock framework to enable and disable autoidle for
these clocks.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Add sdrc_ick to the OMAP2420 clock data so the clock code can control
the CM_AUTOIDLE bit associated with this clock.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Add interface clock type code with autoidle enable/disable support.
The clkops structures created in this file will be used for all
OMAP2/3 interface clocks with autoidle support. They will enable the
clock framework to control interface clock autoidle directly.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Place some comments in the OMAP oscillator clock control code to note that
its autoidle mode should eventually be controlled via the new OMAP clockfw
autoidle control interface.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.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>
Some drivers wish to know whether the device that they control can
ever lose context, for example, when the device's enclosing
powerdomain loses power. They can use this information to determine
whether it is necessary to save and restore device context, or whether
it can be skipped. Implement the powerdomain portion of this by
adding the function pwrdm_can_ever_lose_context(). This is not for
use directly from driver code, but instead is intended to be called
from driver-subarch integration code (i.e., arch/arm/*omap* code).
Currently, the result from this function should be passed into the
driver code via struct platform_data, but at some point this should
be part of some common or OMAP-specific device code.
While here, update file copyrights.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The bank power state bitfields in the powerdomain data are
encoded incorrectly. These fields are intended to be bitfields,
representing a set of power states that the memory banks support.
However, when only one power state was supported by a given bank,
the field was incorrectly set to the bit shift -- not the mask.
While here, update some file copyrights.
The OMAP4 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>
Mark the WKUP powerdomain as being always on -- at least, as long as the
chip has power. This will be used to enable the powerdomain code to
determine whether a given powerdomain is ever able to power off. While
here, update the file copyright.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The following commit: 38698be:
OMAP2+: clockevent: set up GPTIMER clockevent hwmod right before timer init
Fixed properly the issue with early init for the timer1
So reverts commit 3b03b58dab that is now
generated a warning at boot time.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Reviewed-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
