aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/vc.c
Commit message (Collapse)AuthorAge
* Merge branch 'next/pm-samsung' of ↵Olof Johansson2012-11-30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/pm From Kukjin Kim: * 'next/pm-samsung' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: ARM: EXYNOS: Add flush_cache_all in suspend finisher ARM: EXYNOS: Remove scu_enable from cpuidle ARM: EXYNOS: Fix soft reboot hang after suspend/resume ARM: EXYNOS: Add support for rtc wakeup ARM: EXYNOS: fix the hotplug for Cortex-A15 + Linux 3.7-rc6
| * ARM: OMAP2+: PM: add missing newline to VC warning messageKevin Hilman2012-10-25
| | | | | | | | | | | | | | | | | | | | | | Add missing newline to warning message to avoid annoying wrapping problems during kernel boot like this one: omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).Power Management for TI OMAP4. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Kevin Hilman <khilman@ti.com>
* | ARM: OMAP2+: voltage: fixup oscillator handling when CONFIG_PM=nKevin Hilman2012-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 908b75e8 (ARM: OMAP: add support for oscillator setup) added a new API for oscillator setup, but is broken when CONFIG_PM=n. The new functions have dummy definitions when CONFIG_PM=n, but also have full implementations available, which conflict. To fix, wrap the PM implmentations in #ifdef CONFIG_PM. Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | ARM: OMAP4: VC: setup I2C parameters based on board dataTero Kristo2012-11-05
| | | | | | | | | | | | | | | | | | | | | | | | VC code now provides a table of pre-calculated I2C setup parameters, which will be used based on the capacitance value calculated for the I2C trace on the PCB. A default trace length of 6.3cm is used unless board defines its own value during init. The parameters set will be the I2C internal pull setup and the I2C timing parameters for high speed use mode. Full speed mode is not supported as of now. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* | ARM: OMAP4: vc: fix channel configurationTero Kristo2012-11-05
| | | | | | | | | | | | | | | | RACEN bit should only be set if the voltage and command register addresses are the same. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* | ARM: OMAP3+: voltage: use oscillator data to calculate setup timesTero Kristo2012-11-05
| | | | | | | | | | | | | | | | We now use the previously defined oscillator setup / shutdown times to calculate the register values for CLKSETUP. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* | ARM: OMAP4: VC: calculate ramp timesTero Kristo2012-11-05
| | | | | | | | | | | | | | | | | | | | OMAP4 VC code now uses voltage deltas + slew rates for calculating actual ramp times for voltage changes. Both retention / sleep + off mode voltage ramp times are setup at the same time during initialization. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* | ARM: OMAP3: VC: calculate ramp timesTero Kristo2012-11-05
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomainsTero Kristo2012-11-05
|/ | | | | | | | | | | 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>
* Merge tag 'omap-cleanup-b-for-3.7' of ↵Tony Lindgren2012-09-12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-makefile-sparse smatch and string-wrapping cleanups for the OMAP subarch code. These changes fix some of the more meaningful warnings that smatch returns for the OMAP subarch code, and unwraps strings that are wrapped at the 80-column boundary, to conform with the current practice. Basic build, boot, and PM logs are available here: http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/
| * ARM: OMAP: unwrap stringsPaul Walmsley2012-09-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Find and unwrap wrapped strings in the style: pr_debug("clockdomain: hardware cannot set/clear wake up of " "%s when %s wakes up\n", clkdm1->name, clkdm2->name); Keeping these strings contiguous seems to be the current Linux kernel policy. The offending lines were found with the following command: pcregrep -rnM '"\s*$\s*"' arch/arm/*omap* While here, some messages have been clarified, some pr_warning( ... calls have been converted to pr_warn( ..., and some printk(KERN_* ... have been converted to pr_*. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* | ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+Tony Lindgren2012-09-12
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: Fix build for omap4 only builds with missing include of linux/bug.hTony Lindgren2012-03-08
| | | | | | | | | | | | | | | | | | Found few more with randconfig generated .configs: In file included from arch/arm/mach-omap2/prm-regbits-34xx.h:17, from arch/arm/mach-omap2/vc.c:18: arch/arm/mach-omap2/prm2xxx_3xxx.h: In function ‘omap2_prm_read_mod_reg’: arch/arm/mach-omap2/prm2xxx_3xxx.h:239: error: implicit declaration of function ‘WARN’ In file included from arch/arm/mach-omap2/powerdomain44xx.c:22: arch/arm/mach-omap2/prm2xxx_3xxx.h: In function ‘omap2_prm_read_mod_reg’: arch/arm/mach-omap2/prm2xxx_3xxx.h:239: error: implicit declaration of function ‘WARN’ This is because omap2_prm functions are currently just stubs for omap4 only builds. Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: omap: fix uninformative vc/i2c configuration error messageRussell King2012-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | On my OMAP4 platform, I'm getting this error message repeated several times at boot: omap_vc_i2c_init: I2C config for all channels must match. omap_vc_i2c_init: I2C config for all channels must match. This doesn't help identify what the problem is. Fix this message to be more informative: omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0). This allows us to identify which voltage domains have a problem, and what the I2C configuration state (a boolean, i2c_high_speed) setting being used actually is. From this we find that omap4_core_pmic has i2c_high_speed false, but omap4_iva_pmic and omap4_mpu_pmic both have it set true. Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: omap: fix vc.c PMIC error messageRussell King2012-02-13
| | | | | | | | | | | | | | | | While testing on my OMAP3430 platform, this error message was emitted: omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise: omap_vc_init_channel: No PMIC info for vdd_core While we're here, fix a simple spelling error in a comment. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* OMAP2+: VC: more registers are per-channel starting with OMAP5Kevin Hilman2011-09-15
| | | | | | | | | | | | | | | 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>
* OMAP3+: voltage: update nominal voltage in voltdm_scale() not VC post-scaleKevin Hilman2011-09-15
| | | | | | | | | 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>
* OMAP3+: voltage: move/rename curr_volt from vdd_info into struct voltagedomainKevin Hilman2011-09-15
| | | | | | | | | | | 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>
* OMAP3+: VP: create VP helper function for updating error gainKevin Hilman2011-09-15
| | | | | | | | | | 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>
* OMAP3+: VP: struct omap_vp_common: replace shift with __ffs(mask)Kevin Hilman2011-09-15
| | | | | | | | | | | | | | 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>
* OMAP3+: VP: cleanup: move VP instance into voltdm, misc. renamesKevin Hilman2011-09-15
| | | | | | | | | | | | - 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>
* OMAP3+: VC: use last nominal voltage setting to get current_vselKevin Hilman2011-09-15
| | | | | | | | | 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>
* OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channelKevin Hilman2011-09-15
| | | | | | | | | | | | | | 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>
* OMAP3+: VC: make I2C config programmable with PMIC-specific settingsKevin Hilman2011-09-15
| | | | | | | | | | | | | 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>
* OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomainKevin Hilman2011-09-15
| | | | | | | | | | 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>
* OMAP3+: VC: abstract out channel configurationKevin Hilman2011-09-15
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAP3+: VC: move on/onlp/ret/off command configuration into common initKevin Hilman2011-09-15
| | | | | | | 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>
* OMAP3+: VC: cleanup voltage setup time configurationKevin Hilman2011-09-15
| | | | | | | | | | - 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>
* OMAP3+: VC bypass: use fields from VC struct instead of PMIC infoKevin Hilman2011-09-15
| | | | | | | | 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>
* OMAP3+: VC: cleanup PMIC register address configurationKevin Hilman2011-09-15
| | | | | | | | | | | | - 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>
* OMAP3+: VC: cleanup i2c slave address configurationKevin Hilman2011-09-15
| | | | | | | | | | | | - 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>
* OMAP3+: voltage: convert to PRM register access functionsKevin Hilman2011-09-15
| | | | | | | | | | | | | | 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>
* OMAP2+: VC: support PMICs with separate voltage and command registersKevin Hilman2011-09-15
| | | | | | | | | | | | | The VC layer can support PMICs with separate voltage and command registers by putting the different registers in the PRM_VC_SMPS_VOL_RA and PRCM_VC_SMPS_CMD_RA registers respectively. The PMIC data must supply at least a voltage register address (volt_reg_addr). The command register address (cmd_reg_addr) is optional. If the PMIC data does not supply a separate command register address, the VC will use the voltage register address for both. Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP2+: voltage: move VC into struct voltagedomain, misc. renamesKevin Hilman2011-09-15
| | | | | | | | | | | | | | | | | | | | | 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
* OMAP2+: voltage: split voltage controller (VC) code into dedicated layerKevin Hilman2011-09-15
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>