summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/vc.h
AgeCommit message (Collapse)AuthorFilesLines
2012-11-05ARM: OMAP3: VC: calculate ramp timesTero Kristo1-1/+0
OMAP3 VC code now uses voltage deltas + slew rates for calculating actual ramp times for voltage changes. Previously a static value was used. Two calculation methods are provided: i2c_timings and off_timings. I2C timings are used during retention or off mode transition which is initiated over I2C, and OFF timings are used if PMIC signal (nsleep) is used to control all the off mode voltages at the same time. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-11-05ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomainsTero Kristo1-0/+7
These new structs will hold the sleep voltage levels (omap_vc_params) and voltage processor min / max voltages (omap_vp_params.) Previously these were part of the PMIC struct, but they do not really belong there, as they are OMAP chip specific, not PMIC specific parameters. voltdm code is also changed to use the new structs. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP2+: VC: more registers are per-channel starting with OMAP5Kevin Hilman1-8/+8
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>
2011-09-15OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channelKevin Hilman1-0/+1
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>
2011-09-15OMAP3+: VC: make I2C config programmable with PMIC-specific settingsKevin Hilman1-0/+8
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>
2011-09-15OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomainKevin Hilman1-0/+4
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>
2011-09-15OMAP3+: VC: abstract out channel configurationKevin Hilman1-0/+8
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>
2011-09-15OMAP3+: VC: cleanup voltage setup time configurationKevin Hilman1-0/+2
- 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>
2011-09-15OMAP3+: VC: cleanup PMIC register address configurationKevin Hilman1-5/+9
- 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>
2011-09-15OMAP3+: VC: cleanup i2c slave address configurationKevin Hilman1-3/+6
- 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>
2011-09-15OMAP3+: voltage: convert to PRM register access functionsKevin Hilman1-2/+0
Convert VC/VP register access to use PRM VC/VP accessor functions. In the process, move the read/write function pointers from vdd_info into struct voltagedomain. No functional changes. Additional cleanup: - remove prm_mod field from VC/VP data structures, the PRM register access functions know which PRM module to use. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP2+: voltage: move VC into struct voltagedomain, misc. renamesKevin Hilman1-13/+13
Move the VC instance struct from omap_vdd_info into struct voltagedomain. While moving, perform some misc. renames for readability. No functional changes. Summary of renames: - rename omap_vc_instance to omap_vc_channel, since there is only one instance of the VC IP and this actually represents channels using TRM terminology. - rename 'vc_common' field of VC channel which led to: s/vc->vc_common/vc->common/ - remove redundant '_data' suffix - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale() Signed-off-by: Kevin Hilman <khilman@ti.com> merge
2011-09-15OMAP2+: voltage: split voltage controller (VC) code into dedicated layerKevin Hilman1-0/+12
As part of the voltage layer cleanup, split out VC specific code into a dedicated VC layer. This patch primarily just moves VC code from voltage.c into vc.c, and adds prototypes to vc.h. No functional changes. For readability, each function was given a local 'vc' pointer: struct omap_vc_instance_data *vc = voltdm->vdd->vc_data; and a global replace of s/vdd->vc_data/vc/ was done. Also vc_init was renamed to vc_init_channel to reflect that this is per-VC channel initializtion. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP2+: voltage: move PRCM mod offets into VC/VP structuresKevin Hilman1-0/+2
Eliminate need for global variables for the various PRM module offsets by making them part of the VP/VC common structures Eventually, these will likely be moved again, or more likely removed when VP/VC code is isolated, but for now just getting rid of them as global variabes so that the voltage domain initialization can be cleaned up. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-03-10OMAP2+: voltage: reorganize, split code from dataPaul Walmsley1-0/+83
This is a first pass at reorganizing mach-omap2/voltage.c: - Separate almost all of the data from the code of mach-omap2/voltage.c. The code remains in mach-omap2/voltage.c. The data goes into one of several places, depending on what type of data it is: - Silicon process/validation data: mach-omap2/opp*_data.c - VC (Voltage Controller) data: mach-omap2/vc*_data.c - VP (Voltage Processor) data: mach-omap2/vp*_data.c - Voltage domain data: mach-omap2/voltagedomains*_data.c The ultimate goal is for all this data to be autogenerated, the same way we autogenerate the rest of our data. - Separate VC and VP common data from VDD-specific VC and VP data. - Separate common voltage.c code from SoC-specific code; reuse common code. - Reorganize structures to avoid unnecessary memory loss due to unpacked fields. There is much left to be done. VC code and VP code should be separated out into vc*.c and vp*.c files. Many fields in the existing structures are superfluous, and should be removed. Some code in voltage.c seems to be duplicated; that code should be moved into functions of its own. Proper voltage domain code should be created, as was done with the powerdomain and clockdomains, and powerdomains should reference voltagedomains. Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments. Thanks to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs that prevented OMAP4 from booting: https://patchwork.kernel.org/patch/587311/ His patch has been folded into this one to avoid breaking OMAP4 between patches. Thanks also to Kevin Hilman <khilman@ti.com> for finding and fixing a compile problem when !CONFIG_PM: http://www.spinics.net/lists/arm-kernel/msg118067.html His patch has also been folded into this one to avoid breaking !CONFIG_PM builds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Shweta Gulati <shweta.gulati@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@ti.com>