we save the l2x0 registers at the first initialization, and platform codes
can get them to restore l2x0 status after wakeup.
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Following the discussion here:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-August/007301.html
The L2x0 L2 Cache Controllers support a combined interrupt line
which can be used for several events (e.g. read/write/parity errors on
tag/data RAM, event counter increment/overflow). Unfortunately the
OF binding added in c519ecf2 ("ARM: 7009/1: l2x0: Add OF based
initialization") does not represent the interrupt.
This patch adds an "interrupts" property to the L2x0 OF binding,
representing the combined interrupt line.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Barry Song <21cnbao@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
this patch fixes the error in Rob Herring's
ARM: 7009/1: l2x0: Add OF based initialization
http://www.spinics.net/lists/arm-kernel/msg131123.html
it has been in rmk/for-next with commit 41c86ff5b
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Acked-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
using cpu_relax in busy loops is a well-known idiom in the kernel.
It's more for documentation purposes than technically needed here.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This adds probing for ARM L2x0 cache controllers via device tree. Support
includes the L210, L220, and PL310 controllers. The binding allows setting
up cache RAM latencies and filter addresses (PL310 only).
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Even when CONFIG_PM=n, we try to scale the boot voltage to a sane,
known value using OPP table to find matching voltage based on boot
frequency. This should be done, even when CONFIG_PM=n to avoid
mis-configured bootloaders and/or boot voltage assumptions made by
boot loaders.
Also fixes various compile problems due to depenencies between voltage
domain and powerdomain code (also present when CONFIG_PM=n).
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch adds suspend-to-mem support for prima2. It will make prima2
enter DEEPSLEEP mode while accepting PM_SUSPEND_MEM command.
Signed-off-by: Rongjun Ying <rongjun.ying@csr.com>
Signed-off-by: Barry Song <baohua.song@csr.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
SiRFprimaII will lose power in deepsleep mode except rtc, pmu and sdram
self-refresh. So IRQ controller will lose status in suspend cyle.
This patch saves irq mask/level registers while suspending and restore
them while resuming.
Signed-off-by: Barry Song <baohua.song@csr.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
SiRFprimaII will lose power in deepsleep mode except rtc, pmu and sdram
self-refresh.
This patch saves timer-related registers while suspending and restore
them while resuming.
Signed-off-by: Barry Song <baohua.song@csr.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
According to latest OMAP4430 Data Manual v0.4 dated March 2011:
- Retention voltage shall be set to 0.83V. See tables 2.2, 2.4 and 2.6 in DM.
This allows saving a little more power in retention states.
- OPP100 IVA nominal voltage is 1.188V. See table 2.4 in DM.
This allows saving a little power when CPU wakes up until Smart-Reflex is
not yet resumed.
[nm@ti.com: ported to voltdm_c]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Patrick Titiano <p-titiano@ti.com>
using 1.35V as a check is not correct, we know that beyond 0x39,
voltages are non linear - hence use the conversion iff uV greater
than that for 0x39. For example, with 709mV as the smps offset,
the max linear is actually 1.41V(0x39vsel)!
Signed-off-by: Nishanth Menon <nm@ti.com>
omap_twl_vsel_to_uv() and omap_twl_uv_to_vsel() functions used to convert
voltages to TWL6030 SMPS commands (a.k.a "vsel") implement incorrect conversion
formula.
It uses legacy OMAP3 formula, but OMAP4 Power IC has different offset and
voltage step:
- Voltage Step is now 12.66mV (instead of 12.5mV)
- Offset is either 607.7mV or 709mV depending on TWL6030 chip revision
(instead of 600mV)
This leads to setting voltages potentially higher than expected, and so
potentially some (limited) power overconsumption.
For reference, see formula and tables in section 8.5.2.3
"Output Voltage Selection (Standard Mode / Extended Mode with or without offset)"
in TWL6030 functional specifications document.
[nm@ti.com: ported to voltdm_c]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Patrick Titiano <p-titiano@ti.com>
Needed as some of the voltage layer functionality is accessed from the
SMPS regulator driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Starting with OMAP5, the following registers are per-channel and not
common to a all VC channels:
- SMPS I2C slave address
- SMPS voltage register address offset
- SMPS cmd/value register address offset
- VC channel configuration register
Move these from the channel-common struct into the per-channel struct
to support OMAP5.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Currently, the nominal voltage is updated in the VC post-scale function
which is common to both scaling methods. However, this has readabiliy
problems as this update is not where it might be expected. Instead, move
the updated into voltdm_scale() upon a successful return of voltdm->scale()
Signed-off-by: Kevin Hilman <khilman@ti.com>
Remove last remaining member (volt_data) from omap_vdd_info into
struct voltagedomain and removal remaining usage and reference to
omap_vdd_info.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Track current nominal voltage as part of struct voltagedomain instead
of omap_vdd_info, which will soon be removed.
Also renames field from curr_volt to nominal_volt.
No functional changes.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Rename voltage scaling related functions to use voltdm_ prefix intead
of omap_voltage_, and cleanup kerneldoc comments in the process.
s/omap_voltage_scale_vdd/voltdm_scale/
s/omap_voltage_reset/voltdm_reset/
Also, in voltdm_reset() s/target_uvdc/target_volt/ to be consistent with
naming throughout the file.
No functional changes.
Signed-off-by: Kevin Hilman <khilman@ti.com>
combine VPCONFIG init voltage setup into common function and use from
both vp_enable and from vp_forceupdate_scale().
NOTE: this patch changes the sequence of when the initVDD bit is
cleared. The bit is now cleared immediately after it was written.
Since only the rising edge of this bit has any affect according to the
TRM, the exact timing of clearing of this bit should not have any
effect.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently
relies on a u32 -> u8 conversion to mask off the FORCEUPDATEWAIT field
in the upper bits. Make this explicit using the mask symbol
already defined, added as a new field in struct omap_vp_common.
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Function pointer used for actual voltage scaling (e.g. VP force update
or VC bypass) is moved from omap_vdd_info into struct voltagedomain,
resulting in renames s/vdd->volt_scale/voltdm->scale/
No functional changes.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Remove the "runtime" VP data in favor of direct programming of VP registers.
The VP is in the PRM, which is in the wakeup powerdomain, so there is no
need to keep the state dynamically.
Fixes to original version from Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Create new helper function in VP layer for updating VP error gain.
Currently used during pre-scale for VP force update and VC bypass.
TODO: determine if this can be removed from the pre-scale path and
moved to VP enable path.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Add sys clock name and rate to struct voltage domain. SoC specific
voltagedomain init code initializes sys clock name. After clock
framework is initialized, voltage late init will then use use the
sys_clk rate to calculate the various timing that depend on that rate.
Signed-off-by: Kevin Hilman <khilman@ti.com>
In struct omap_vp_common, the shift value can be derived from the mask
value by using __ffs(), so remove the shift value for the various
VPCONFIG bitfields, and use __ffs() in the code for the shift value.
While here, rename field names in kerneldoc comment to match actual
field names in structure. Also, cleanup indendentaion for other VP
register accesses in omap_vp_init().
No functional changes.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Remove read-only debugfs interface to VP values. Most of the values
are init-time only and never change. Current voltage value should be
retreived from the (eventual) regulator framework interface to the
voltage domain.
Fixes to original version provided by Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
- move VP instance struct from vdd_info into struct voltage domain
- remove _data suffix from structure name
- rename vp_ prefix from vp_common field: accesses are now vp->common
- move vp_enabled bool from vdd_info into VP instance
- remove remaining references to omap_vdd_info
No functional changes.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Instead of reading current vsel value from the VP's voltage register,
just use current nominal voltage translated into vsel via the PMIC.
Doing this allows VC bypass scaling to work even without a VP configured.
Signed-off-by: Kevin Hilman <khilman@ti.com>
On OMAP3+, all VC channels have the the same bitfield ordering for all
VC channels, except the OMAP4 MPU channel. This appears to be a freak
accident as all other VC channel (including OMAP5) have the standard
configuration. Handle the mutant case by adding a per-channel flag
to signal the deformity and handle it during VC init.
Special thanks to Nishanth Menon <nm@ti.com> for finding this problem
and for proposing the initial solution.
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Remove hard-coded I2C configuration in favor of settings that can be
configured from PMIC-specific values. Currently only high-speed mode
and the master-code value are supported, since they were the only
fields currently used, but extending this is now trivial.
Thanks to Nishanth Menon <nm@ti.com> for reporting/fixing a sparse
problem and making omap_vc_i2c_init() static, as well as finding and
fixing a problem with the shift/mask of mcode.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Move structure containing PMIC configurable settings into struct
voltagedomain. In the process, rename from omap_volt_pmic_info to
omap_voltdm_pmic (_info suffix is not helpful.)
No functional changes.
Signed-off-by: Kevin Hilman <khilman@ti.com>
VC channel configuration is programmed based on settings coming from
the PMIC configuration.
Currently, the VC channel to PMIC mapping is a simple one-to-one
mapping. Whenever a VC channel parameter is configured (i2c slave
addres, PMIC register address, on/ret/off command), the corresponding
bits are enabled in the VC channel configuration register.
If necessary, the programmability of channel configuration settings
could be extended to board/PMIC files, however, because this patch
changes the channel configuration to be programmed based on existing
values from the PMIC settings, it may not be required.
Also note that starting with OMAP4, where there are more than 2
channels, one channel is identified as the "default" channel. When
any of the bits in the channel config for the other channels are zero,
it means to use the default channel. The OMAP4 TRM (at least through
NDA version Q) is wrong in describing which is the default channel.
The default channel on OMAP4 is MPU, not CORE as decribed in the TRM.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Configuring the on/onlp/ret/off command values is common to OMAP3 & 4.
Move from OMAP3-only init into common VC init.
Signed-off-by: Kevin Hilman <khilman@ti.com>
- add setup_time field to struct omap_vc_channel (init'd from PMIC data)
- use VC/VP register access helper for read/modify/write
- move VFSM structure from omap_vdd_info into struct voltagedomain
- remove redunant _data suffix from VFSM structures and variables
- remove voltsetup_shift, use ffs() on the mask value to find the shift
Signed-off-by: Kevin Hilman <khilman@ti.com>
The PMIC configurable variables should be isolated to VC initialization.
The rest of the VC functions (like VC bypass) should use the i2c slave address
and voltage register address fields from struct omap_vc_channel.
Signed-off-by: Kevin Hilman <khilman@ti.com>
- support both voltage register address and command register address
for each VC channel
- add fields for voltage register address (volra) and command register
address (cmdra) to struct omap_vc_channel
- use VC/VP register access read/modify/write helper
- remove volra_shift field (use __ffs(mask) for shift value)
- I2C addresses 10-bit, change size to u16
Signed-off-by: Kevin Hilman <khilman@ti.com>
- Add an i2c_slave_address field to the omap_vc_channel
- use VC/VP read/modify/write helper instead of open-coding
- remove smps_sa_shift, use __ffs(mask) for shift value
- I2C addresses 10-bit, change size to u16
Special thanks to Shweta Gulati <shweta.gulati@ti.com> for suggesting
the use of __ffs(x) instead of ffs(x) - 1.
Signed-off-by: Kevin Hilman <khilman@ti.com>
