Jarkko Nikula [Tue, 21 Dec 2010 17:46:01 +0000 (17:46 +0000)]
omap: rx51: Remove tvout code that plays with gpio 40
Commit 60d24ee "Added video data to support tvout on rx51" added code that
tries to assign gpio 40 as OMAP DSS reset_gpio for tvout. This is wrong
since this gpio has nothing to do with OMAP DSS but it is used to control
one switch that selects is the audio jack connected to tvout or audio
circuitry.
This switch is already supported by the RX51 ASoC driver so there is no need
to control it elsewhere. Switch is contolled with ALSA control
'Jack Function' and tvout can be selected with following example:
amixer -D hw:0 set 'Jack Function' 'TV-OUT'
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Cc: Srikar <ext-srikar.1.bhavanarayana@nokia.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Jarkko Nikula [Tue, 21 Dec 2010 17:25:35 +0000 (17:25 +0000)]
omap: rx51: Add vdda_dac supply for tvout
Commmit 60d24ee "Added video data to support tvout on rx51" broke the DSS
on RX51/N900 since it added DSS VENC support but a patch adding needed
supply is missing from tree and no framebuffers are initialized.
This patch is basically cleaned up version of original one:
http://marc.info/?l=linux-omap&m=129070041402418&w=2
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Cc: Srikar <ext-srikar.1.bhavanarayana@nokia.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Jarkko Nikula [Tue, 21 Dec 2010 17:25:34 +0000 (17:25 +0000)]
omap: rx51: Cleanup vdds_sdi supply construction
It is much more cleaner to use REGULATOR_SUPPLY macro and a device name
instead of having a reference to rx51_display_device.dev with #if defined()
guards.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Jon Hunter [Thu, 9 Dec 2010 22:13:40 +0000 (23:13 +0100)]
OMAP4: clock data: Add missing fixed divisors
The following OMAP4 clocks have the following fixed divisors that
determine the frequency at which these clocks operate. These
dividers are defined by the PRCM specification and without these
dividers the rates of the below clocks are calculated incorrectly.
This may cause internal peripherals using these clocks to operate
at the wrong frequency.
OMAP4: clock data: Keep L3INSTR clock domain modulemode under HW control
L3INSTR clock domain is read only register and its reset value is
HW_AUTO. The modules withing this clock domain needs to be kept under
hardware control.
MODULEMODE:
- 0x0: Module is disable by software. Any INTRCONN access to module
results in an error, except if resulting from a module wakeup
(asynchronous wakeup).
- 0x1: Module is managed automatically by hardware according to
clock domain transition. A clock domain sleep transition put
module into idle. A wakeup domain transition put it back
into function. If CLKTRCTRL=3, any INTRCONN access to module
is always granted. Module clocks may be gated according to
the clock domain state.
This patch keeps CM_L3INSTR_L3_3_CLKCTRL, CM_L3INSTR_L3_INSTR_CLKCTRL
and CM_L3INSTR_INTRCONN_WP1_CLKCTRL module mode under hardware control
by using ENABLE_ON_INIT flag.
Without this the OMAP4 device OFF mode SAR restore phase aborts during
interconnect register restore phase. This can be also handled by doing
explicit a clock enable and disable in the low power code since there
is no direct module associated with it. But that seems not necessary
since the clock domain is under HW control.
On OMAP4, there is an issue when L3INIT transitions to OFF mode without
device OFF. The SAR restore mechanism will not get triggered without
wakeup from device OFF and hence the USB host and USB TLL context
will not be restored.
Hardware team recommended to remove the OFF state support for L3INIT_PD
since there is no power impact. It will be removed on next OMAP revision
(OMAP4440 and beyond).
Hence this patch removed the OFF state from L3INIT_PD. The deepest
state supported on L3INIT_PD is OSWR just like CORE_PD and PER_PD
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[b-cousson@ti.com: update the changelog with next OMAP info] Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Rajendra Nayak [Wed, 22 Dec 2010 05:37:28 +0000 (22:37 -0700)]
OMAP4: powerdomain: l4per pwrdm does not support OFF
The l4per power domain in ES2.0 does support only RET and ON states.
The previous ES1.0 HW database was wrong and thus fixed on ES2.
Change the pwrsts field to reflect that.
Rajendra Nayak [Wed, 22 Dec 2010 05:37:28 +0000 (22:37 -0700)]
OMAP4: PM: Do not assume clkdm supports hw transitions
omap_set_pwrdm_state today assumes a clkdm supports hw_auto
transitions and hence leaves some which do not support this
in sw wkup state preventing low power transitions.
Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Kevin Hilman [Wed, 22 Dec 2010 04:31:55 +0000 (21:31 -0700)]
OMAP: PM noop: implement context loss count for non-omap_devices
For devices which have not (yet) been converted to use omap_device,
implement the context loss counter using the "brutal method" as
originally proposed by Paul Walmsley[1].
The dummy context loss counter is incremented every time it is
checked, but only when off-mode is enabled. When off-mode is
disabled, the dummy counter stops incrementing.
Tested on 36xx/Zoom3 using MMC driver, which is currently the
only in-tree user of this API.
This patch should be reverted after all devices are converted to using
omap_device.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: fixed compile warning; fixed to compile on OMAP1] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Kevin Hilman [Wed, 22 Dec 2010 04:31:55 +0000 (21:31 -0700)]
OMAP: PM: implement context loss count APIs
Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to get the
context loss count.
The new APIs return an unsigned value that can wrap as the
context-loss count grows. However, the wrapping is not important as
the role of this function is to determine context loss by checking for
any difference in subsequent calls to this function.
Note that these APIs at each level can return zero when no context
loss is detected, or on errors. This is to avoid returning error
codes which could potentially be mistaken for large context loss
counters.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
for checking how many times the powerdomain has lost context. The
loss count is the sum of the powerdomain off-mode counter, the
logic off counter and the per-bank memory off counter.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
[paul@pwsan.com: removed bogus return value on error; improved kerneldoc;
tweaked commit message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Hari Kanigeri [Wed, 22 Dec 2010 04:18:56 +0000 (21:18 -0700)]
OMAP4: clocks: add dummy clock for mailbox
In omap4, there is no explicit configuration register to enable mailbox clocks.
Defining dummy clock for mailbox clock module to keep the mailbox driver
backward compatible with previous omaps.
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Jon Hunter [Wed, 22 Dec 2010 04:31:43 +0000 (21:31 -0700)]
OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4
J-Type DPLLs have additional configuration parameters that need to
be programmed when setting the multipler and divider for the DPLL.
These parameters being the sigma delta divider (SD_DIV) for the DPLL
and the digital controlled oscillator (DCO) to be used by the DPLL.
The current code is implemented specifically to configure the
OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL
and so this code needs to be updated to work for both OMAP3 and OMAP4
devices and any other future devices that have J-TYPE DPLLs.
For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are
used but for the OMAP4430 USB DPLL only the SD_DIV field is used.
The current implementation will only program the SD_DIV and DCO
fields if the DPLL has both and hence this does not work for
OMAP4430.
In order to make the code more generic add two new fields to the
dpll_data structure for the SD_DIV field and DCO field bit-masks
and only program these fields if the masks are defined for a specific
DPLL. This simplifies the code and allows us to remove the flag
DPLL_NO_DCO_SEL.
Tested on OMAP36xx Zoom3 and OMAP4 Blaze.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*()
functions; added testing info to commit message; added 35xx comments back in] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Benoit Cousson [Wed, 22 Dec 2010 04:31:28 +0000 (21:31 -0700)]
OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs
The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup.
This new idlemode replaces the enawakeup for the new IPs but seems to
coexist as well for some legacy IPs (UART, GPIO, MCSPI...)
Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this
capability.
The omap_hwmod_44xx_data.c will have to be updated to add this new flag.
Enable this new mode when applicable in _enable_wakeup, _enable_sysc and
_idle_sysc.
Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Sebastien Guiriec <s-guiriec@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
Rajendra Nayak [Wed, 22 Dec 2010 04:31:28 +0000 (21:31 -0700)]
OMAP2+: hwmod: Disable clocks when hwmod enable fails
In cases where a module (hwmod) does not become accesible on enabling
the main clocks (can happen if there are external clocks needed
for the module to become accesible), make sure the clocks are not
left enabled.
This ensures that when the requisite external dependencies are met
a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable
and disable clocks using clk framework. Leaving the clocks enabled in
the error case causes additional usecounting at the clock framework
level leaving the clock enabled forever.
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> Cc: Kevin Hilman <khilman@deeprootsystems.com>
Benoit Cousson [Wed, 22 Dec 2010 04:31:28 +0000 (21:31 -0700)]
OMAP2+: hwmod: Remove omap_hwmod_mutex
The hwmod list will be built are init time and never
be modified at runtime. There is no need anymore to protect
the list from concurrent accesses using a mutex.
Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
Benoit Cousson [Wed, 22 Dec 2010 04:31:28 +0000 (21:31 -0700)]
OMAP2+: hwmod: Mark functions used only during initialization with __init
_register, _find_mpu_port_index and _find_mpu_rt_base are static APIs
that will be used only during the omap_hwmod initialization phase.
There is no need to keep them for runtime.
Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
Benoit Cousson [Wed, 22 Dec 2010 04:31:27 +0000 (21:31 -0700)]
OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister
Do not allow omap_hwmod_register to be used outside the core
hwmod code. An omap_hwmod should be registered only at init time.
Remove the omap_hwmod_unregister that is not used today since the
hwmod list will be built once at init time and never be modified
at runtime.
Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
Kevin Hilman [Wed, 22 Dec 2010 04:08:34 +0000 (21:08 -0700)]
OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Benoit Cousson [Wed, 22 Dec 2010 04:08:34 +0000 (21:08 -0700)]
OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW
The DMM is a piece of interconnect that need to be configured properly
for the tiler functionnality. It thus exposes some configuration registers
that were missing previously.
Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Benoit Cousson [Wed, 22 Dec 2010 04:08:33 +0000 (21:08 -0700)]
OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag
Update the data for GPIO, UART, WD_TIMER and I2C in order to
support the new reset status flag introduce in the following
commit:
commit 2cb068149c365f1c2b10f2ece6786139527dcc16
OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs
Without this flag properly set, the reset is done, but the hwmod
core code will not wait for the reset completion to continue its
excecution.
Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Charulatha V <charu@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Govindraj.R <govindraj.raja@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
Benoit Cousson [Wed, 22 Dec 2010 04:08:33 +0000 (21:08 -0700)]
OMAP4: hwmod data: Fix hwmod entries order
The original OMAP4 hwmod data files is fully generated from HW
database. But since the file is introduced incrementaly along
with driver that uses the data, it has to be splitted by the driver
owner and then re-merged by the maintainer.
Because of the similarity of the data, git is completely lost
during such merge and thus the data does not look like the original one
at the end.
Re-order properly the structures to stay in sync with original data set.
This makes it much easier to diff the autogenerated script output with
what's in mainline, see differences, and generate patches for those
diffs. The goal is to stay in sync with the autogenerated data from now
on.
Add a comment that does contain all the IPs that can have a hwmod, but
do not have it in the file for the moment. It gives a good indication
of the progress.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: updated to apply against current core integration branch,
commit message slightly amplified; fixed opt_clks_cnt whitespace] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Govindraj.R <govindraj.raja@ti.com> Cc: Charulatha V <charu@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
Paul Walmsley [Wed, 22 Dec 2010 04:08:14 +0000 (21:08 -0700)]
OMAP2/3: SRAM: add comment about crashes during a TLB miss
Some users were observing crashes during the execution of CORE DVFS
code from OCM RAM -- a locally-modified copy of the linux-omap code.
Richard Woodruff tracked this down to a DTLB miss which had been
inadvertently and intermittently caused by the local modifications.
(The TLB miss caused the ARM MMU to attempt to walk the page tables
stored in SDRAM, which was not possible since SDRAM is off-line for a
portion of the CORE DVFS OCM RAM code.)
Add a note to the OMAP2 & OMAP3 CORE DVFS SRAM code to warn others that
changes may result in crashes here if they are not carefully tested.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Nishanth Menon <nm@ti.com>
Paul Walmsley [Wed, 22 Dec 2010 04:08:14 +0000 (21:08 -0700)]
OMAP3: clock: fix incorrect rate display when switching MPU rate at boot
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: Paul Walmsley <paul@pwsan.com> Cc: Bruno Guerin <br.guerin@free.fr> Cc: Richard Woodruff <r-woodruff2@ti.com>
Paul Walmsley [Wed, 22 Dec 2010 04:08:14 +0000 (21:08 -0700)]
OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu
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.
Paul Walmsley [Wed, 22 Dec 2010 04:08:14 +0000 (21:08 -0700)]
OMAP2xxx clock: fix dss2_fck recalc to use clksel
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.
Rajendra Nayak [Wed, 22 Dec 2010 04:08:14 +0000 (21:08 -0700)]
OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocks
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.
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: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Thara 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: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
Benoit Cousson [Wed, 22 Dec 2010 04:08:13 +0000 (21:08 -0700)]
OMAP3: clock data: Add "wkup_clkdm" in sr1_fck and sr2_fck
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: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
Benoit Cousson [Wed, 22 Dec 2010 04:08:13 +0000 (21:08 -0700)]
OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk
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.
Paul Walmsley [Wed, 22 Dec 2010 04:05:16 +0000 (21:05 -0700)]
OMAP3: control/PM: move padconf save code to mach-omap2/control.c
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].
Paul Walmsley [Wed, 22 Dec 2010 04:05:16 +0000 (21:05 -0700)]
OMAP2+: powerdomain: move header file from plat-omap to mach-omap2
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: Paul 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>
Paul Walmsley [Wed, 22 Dec 2010 04:05:15 +0000 (21:05 -0700)]
OMAP2+: clockdomain: move header file from plat-omap to mach-omap2
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: Paul 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: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Paul Walmsley [Wed, 22 Dec 2010 04:05:15 +0000 (21:05 -0700)]
OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct CM register accesses
Reverse some of the effects of commit 84c0c39aec31a09571fc08a752a2f4da0fe9fcf2 ("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.)
Paul Walmsley [Wed, 22 Dec 2010 04:05:15 +0000 (21:05 -0700)]
OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support
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.
Paul Walmsley [Wed, 22 Dec 2010 04:05:15 +0000 (21:05 -0700)]
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.
Paul Walmsley [Wed, 22 Dec 2010 04:05:15 +0000 (21:05 -0700)]
OMAP2+: clockdomains: split the clkdm hwsup enable/disable function
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: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
Paul Walmsley [Wed, 22 Dec 2010 04:05:14 +0000 (21:05 -0700)]
OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functions
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.
Paul Walmsley [Wed, 22 Dec 2010 04:05:14 +0000 (21:05 -0700)]
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.
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.
Paul Walmsley [Tue, 21 Dec 2010 22:30:56 +0000 (15:30 -0700)]
OMAP3: PRM/CM: separate CM context save/restore; remove PRM context save/restore
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>
Paul Walmsley [Tue, 21 Dec 2010 22:30:55 +0000 (15:30 -0700)]
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>
Paul Walmsley [Tue, 21 Dec 2010 22:30:55 +0000 (15:30 -0700)]
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.
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>
Paul Walmsley [Tue, 21 Dec 2010 22:30:53 +0000 (15:30 -0700)]
OMAP3: control/PRCM: move CONTROL_PADCONF_SYS_NIRQ save/restore to SCM code
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: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.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>
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: Paul Walmsley <paul@pwsan.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Paul Walmsley [Wed, 22 Dec 2010 03:01:20 +0000 (20:01 -0700)]
OMAP2+: clockdomains: move clockdomain static data to .c files
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: Paul Walmsley <paul@pwsan.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>
Paul Walmsley [Wed, 22 Dec 2010 03:01:20 +0000 (20:01 -0700)]
OMAP2+: powerdomains: move powerdomain static data to .c files
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: Paul Walmsley <paul@pwsan.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>
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: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: clarified commit message] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.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>
Rajendra Nayak [Wed, 22 Dec 2010 03:01:19 +0000 (20:01 -0700)]
OMAP: powerdomain: Arch specific funcs for mem control
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: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: rearranged Makefile changes] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Rajendra Nayak [Wed, 22 Dec 2010 03:01:18 +0000 (20:01 -0700)]
OMAP: powerdomain: Arch specific funcs for logic control
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: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.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>
Rajendra Nayak [Wed, 22 Dec 2010 03:01:18 +0000 (20:01 -0700)]
OMAP: powerdomain: Arch specific funcs for state control
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: Rajendra 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: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.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>
Rajendra Nayak [Wed, 22 Dec 2010 03:01:18 +0000 (20:01 -0700)]
OMAP: powerdomain: Infrastructure to put arch specific code
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: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.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>
Rajendra Nayak [Wed, 22 Dec 2010 03:01:17 +0000 (20:01 -0700)]
OMAP: powerdomain: Move static allocations from powerdomains.h to a .c file
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.
Paul Walmsley [Tue, 21 Dec 2010 22:39:15 +0000 (15:39 -0700)]
OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism
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.
Rajendra Nayak [Tue, 14 Dec 2010 19:42:36 +0000 (12:42 -0700)]
OMAP2+: hwmod: Update the sysc_cache in case module context is lost
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: Rajendra Nayak <rnayak@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Paul Walmsley [Tue, 14 Dec 2010 19:42:35 +0000 (12:42 -0700)]
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
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 848240223c35fcc71c424ad51a8e8aef42d3879c - 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: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Tue, 14 Dec 2010 19:42:35 +0000 (12:42 -0700)]
OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA and I2C, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Paul Hunt <hunt@ti.com> Cc: Stanley Liu <stanley_liu@ti.com>
Paul Walmsley [Tue, 14 Dec 2010 19:42:35 +0000 (12:42 -0700)]
OMAP2+: hwmod: add postsetup state
Allow board files and OMAP core code to control the state that some or
all of the hwmods end up in at the end of _setup() (called by
omap_hwmod_late_init() ). Reimplement the old skip_setup_idle code in
terms of this new postsetup state code.
There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case,
in which all IP blocks should stay enabled after _setup() finishes;
and the MPU watchdog case, in which the watchdog IP block should enter
idle if watchdog coverage of kernel initialization is desired, and
should be disabled otherwise.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Charulatha Varadarajan <charu@ti.com>
Some OMAP IP blocks, such as the watchdog timers, cannot be completely
shut down via the standard hwmod shutdown mechanism. This patch
enables the hwmod data files to supply a pointer to a custom
pre-shutdown function via the struct omap_hwmod_class.pre_shutdown
function pointer. If the struct omap_hwmod_class.pre_shutdown
function pointer is non-null, the function will be executed before the
existing hwmod shutdown code runs.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Tue, 21 Dec 2010 22:25:10 +0000 (15:25 -0700)]
OMAP2+: io: split omap2_init_common_hw()
Split omap2_init_common_hw() into two functions. The first,
omap2_init_common_infrastructure(), initializes the hwmod code and
data, the OMAP PM code, and the clock code and data. The second,
omap2_init_common_devices(), handles any other early device
initialization that, for whatever reason, has not been or cannot be
moved to initcalls or early platform devices.
This patch is required for the hwmod postsetup patch, which allows
board files to change the state that hwmods should be placed into at
the conclusion of the hwmod _setup() function. For example, for a
board whose creators wish to ensure watchdog coverage across the
entire kernel boot process, code to change the watchdog's postsetup
state will be added in the board-*.c file between the
omap2_init_common_infrastructure() and omap2_init_common_devices() function
calls.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
Raghuveer Murthy [Tue, 21 Dec 2010 14:14:34 +0000 (14:14 +0000)]
OMAP4: Pandaboard: Fix MMC card detect gpio line
commit bf56f0a6668cd (2.6.37-rc1), from Nishanth Menon attempted
to fix card detection for PandaBoard, unfortunately, the fix missed
to initialize .gpio_cd member of omap2_hsmmc_info. This results
in a default value of '0', which is a valid GPIO line.
On PandaBoard, the side effect of this is that GPIO line 0 controls
the powering TFP410 DVI chip, and without the fix DVI chip is
inadvertently powered.
Tested-by: David Anders <x0132446@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Raghuveer Murthy <raghuveer.murthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Daniel Morsing [Tue, 21 Dec 2010 10:23:13 +0000 (10:23 +0000)]
OMAP2: Devkit8000: Use _cansleep GPIO functions for displayreset lines
The display reset lines are connected to a TPS65930 which may sleep
when changing GPIO values. Use the appropriate function to silence
a nasty warning from gpiolib.
Signed-off-by: Daniel Morsing <daniel.morsing@gmail.com> Acked-by: Thomas Weber <weber@corscience.de> Signed-off-by: Tony Lindgren <tony@atomide.com>
Jean Pihet [Sat, 18 Dec 2010 15:44:45 +0000 (16:44 +0100)]
OMAP3: rework of the ASM sleep code execution paths
- Reworked and simplified the execution paths for better
readability and to avoid duplication of code,
- Added comments on the entry and exit points and the interaction
with the ROM code for OFF mode restore,
- Reworked the existing comments for better readability.
Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.
Signed-off-by: Jean Pihet <j-pihet@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Eduardo Valentin [Mon, 20 Dec 2010 20:05:09 +0000 (14:05 -0600)]
OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 < ES1.2 is impacted as follows depending on the platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable, while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon erratum:
Avoid core power domain transitioning to OFF mode. Power consumption
impact is expected in this case.
To do this, we route core OFF requests to RET request on the impacted
revisions of silicon.
Acked-by: Jean Pihet <j-pihet@ti.com>
[nm@ti.com: rebased the code to 2.6.37-rc2- short circuit code changed a bit] Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Nishanth Menon [Mon, 20 Dec 2010 20:05:08 +0000 (14:05 -0600)]
OMAP3: PM: make omap3_cpuidle_update_states independent of enable_off_mode
Currently omap3_cpuidle_update_states makes whole sale decision
on which C states to update based on enable_off_mode variable
Instead, achieve the same functionality by independently providing
mpu and core deepest states the system is allowed to achieve and
update the idle states accordingly.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
[khilman: fixed additional user of this API in OMAP CPUidle driver] Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
OMAP3630: PM: Disable L2 cache while invalidating L2 cache
While coming out of MPU OSWR/OFF states, L2 controller is reseted.
The reset behavior is implementation specific as per ARMv7 TRM and
hence $L2 needs to be invalidated before it's use. Since the
AUXCTRL register is also reconfigured, disable L2 cache before
invalidating it and re-enables it afterwards. This is as per
Cortex-A8 ARM documentation.
Currently this is identified as being needed on OMAP3630 as the
disable/enable is done from "public side" while, on OMAP3430, this
is done in the "secure side".
Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Jean Pihet <j-pihet@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm@ti.com: ported to 2.6.37-rc2, added hooks to enable the logic only on 3630] Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com> Signed-off-by: Peter 'p2' De Schrijver <peter.de-schrijver@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Nishanth Menon [Mon, 20 Dec 2010 20:05:06 +0000 (14:05 -0600)]
OMAP3630: PM: Erratum i608: disable RTA
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling RTA coming out of off mode, we do this by overriding the
restore pointer for 3630 as the first point of entry before caches are
touched and is common for GP and HS devices. To disable earlier than
this could be possible by modifying the PPA for HS devices, but not for
GP devices.
Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Jean Pihet <j-pihet@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[ambresh@ti.com: co-developer] Signed-off-by: Ambresh K <ambresh@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Erratum i581 impacts OMAP3 platforms.
PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing
the DPLL not to be locked at times.
IMPORTANT:
*) This is not a complete workaround implementation as recommended
by the silicon erratum. This is a support logic for detecting lockups and
attempting to recover where possible and is known to provide stability
in multiple platforms.
*) This code is mostly important for inactive and retention. The ROM code
waits for the maximum DLL lock time when resuming from off mode. So for
off mode this code isn't really needed.
*) counters are introduced here for eventual export to userspace once the
cleanups are completed.
This should eventually get refactored as part of cleanups to sleep34xx.S
Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Peter 'p2' De Schrijver <peter.de-schrijver@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Richard Woodruff [Mon, 20 Dec 2010 20:05:03 +0000 (14:05 -0600)]
OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all
Analysis in TI kernel with ETM showed that using cache mapped flush
in kernel instead of SO mapped flush cost drops by 65% (3.39mS down
to 1.17mS) for clean_l2 which is used during sleep sequences.
Overall:
- speed up
- unfortunately there isn't a good alternative flush method today
- code reduction and less maintenance and potential bug in
unmaintained code
This also fixes the bug with the clean_l2 function usage.
Reported-by: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com>
[nm@ti.com: ported rkw's proposal to 2.6.37-rc2] Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
projects / linux-beck.git / log