01 Dec, 2011
3 commits
-
Enable the following features in the defconfig
- CPU_IDLE support
- A few essential features like DEBUG_LL,
DYNAMIC_DEBUG and EARLYPRINTKSigned-off-by: Vaibhav Bedia
-
Add board specific cpuidle hookup for AM335x EVM
Signed-off-by: Vaibhav Bedia
-
Add basic cpuidle support for AM33XX family of SoC.
Right now only two idle states (WFI and WFI+SR) are
supported. The latency/residency numbers chosen will
be fine-tuned based on power measurements on actual
hardware.Signed-off-by: Vaibhav Bedia
30 Nov, 2011
37 commits
-
TPS65910 VDD1 SMPS is connected to MPU.
Add dummy entries for other regulators.TODO: Replace dummy regulator entries
with proper ones as required.Signed-off-by: Afzal Mohammed
-
MPU voltage domain data added. Also added
OPP table for MPU voltage domain.OPP table for CORE voltage domain has not been
added as there were issues upon reducing CORE
voltage, hence no dependency has been defined
for MPU.Signed-off-by: Afzal Mohammed
-
Jitter correction for AM33XX is not present.
Handle revelant clock API's properly.Signed-off-by: Afzal Mohammed
-
Signed-off-by: Vaibhav Bedia
-
Initialize voltage to be as per OPP
Signed-off-by: Vaibhav Bedia
Signed-off-by: Afzal Mohammed -
Replace clk_set_rate with omap_device_scale
in target function. This provides the ability
to change voltage as well as frequency as per
OPP tablesSigned-off-by: Afzal Mohammed
-
TI processors in TI81x and AM33x family work with PMICs like
TPS65910/1 which are not part of the TWL series. These processors
also do not have a voltage controller/processor module.In order to invoke the normal regulator calls from the voltage
layer the following changes are done to struct voltagedomain
- Add a flag use_regulator for the SoC voltagedomain
code to indicate its intention of using a PMIC which
is not controlled by VC/VP
- Add a regulator_init callback which the platform code
can utilise for any custom init sequence before making
use of the regulator. Platform code is also expected
to set the voltdm->scale function in the init callbackSigned-off-by: Ravikumar Kattekola
Signed-off-by: Vaibhav Bedia -
Most clock rates can vary to some extent based on the exact
M/N values used to lock a dpll.
Do a round_rate before updating the rates into the OPP table
so that the 'exact' rates appear and a subsequent clk_set_rate
works without issues.Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia
Signed-off-by: Afzal Mohammed -
Ensure that PM initializations are all ready before we proceed.
This allows drivers such as gfx, cpufreq which are ready earlier
than pm to not not attempt to use the scaling infrastructure before
it is ready.Signed-off-by: Nishanth Menon
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Make DVFS to try the next available frequency if the higher match
is not available. This will probably be the max available for the device.If we cannot match any thing at all, fail. This modifies the behavior
of device scale to guarenteeing _atleast_ the frequency requested into
_if possible_, the frequency requested.Signed-off-by: Girish S G
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Provide mechanism to know if DVFS is scaling on a specific domain.
This API will allow us to detect transition and take appropriate
measures in idle pathAcked-by: Todd Poynor
Acked-by: Santosh Shilimkar
Signed-off-by: Nishanth Menon
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Ability to show the dependency table helps debug some of the quirky
issues associated with dvfs when multiple device requests are present[nm@ti.com: log beautification, few fixes]
Signed-off-by: Nishanth Menon
Signed-off-by: Todd Poynor
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Let omap_init_opp_table run through all the OPP's instead of
returning on seeing the first invalid one. Skip the invalid ones
and give a fair chance to the rest to get registered,
if they are found to be valid.
For every invalid entry in the OPP table, instead of a pr_warn,
do a WARN so it gets the attention it needs.Signed-off-by: Rajendra Nayak
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Allocating dvfs_info for every device instead of doing it
for every voltage domain causes devices registered using
omap_dvfs_register_device() to disappear.Signed-off-by: Rajendra Nayak
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
dvfs.h is required by omap cpufreq driver that
lives in drivers folder, so move it to plat/
directory. Also move voltage.h, vc.h & vp.h
similarly to have clean header file inclusionsSigned-off-by: Afzal Mohammed
-
Register DVFS entries per opp entry to capture all
scalable domain devices.Signed-off-by: Nishanth Menon
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
With hwmods, ideally, we should have been able to do:
pdm = omap_hwmod_get_pwrdm(oh);
voltdm = pwrdm_get_voltdm(pdm);
clk = clk_get(oh->main_clk);Unfortunately hwmod database is'nt mature enough yet to handle
silicon variance within the same family, e.g. 4430 Vs 4460.
So we explicitly map the domain and clk names within the OPP
entries. This allows us to scale by having a central location for
the registration.IMPORTANT NOTE: we probably will need to fix core and iva clk
setting.Signed-off-by: Nishanth Menon
Signed-off-by: Vishwanath BS
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
This patch introduces helper functions for Device Voltage and Frequency
Scaling (DVFS).
Data structures added:
1. omap_dev_user_list: This structure maintains list of frequency requests per
device basis. When a device needs to be scaled to a particular frequency,
This list is searched to find the maximum request for a given device.
If noone has placed any request, device frequency is obtained from device
opp table.
2. omap_vdd_dev_list: This strcucture stores device list per vdd basis.
Whenever a device is registered with a vdd, it is added to this list.
3. omap_vdd_user_list: User list of devices associated with each voltage domain
instance. The user list is implemented using plist structure with priority
node populated with the voltage values.
4. omap_vdd_dvfs_info: This structure is used to abstract DVFS related
information per VDD basis. It holds pointer to corresponding vdd's
voltagedomain instance and pointer to user list.Following helper functions have been added to operate on above data structures:
1. omap_dvfs_add_vdd_user - function to add a user into omap_vdd_user_list
2. omap_vdd_user_list - function to remove a user from omap_vdd_user_list
3. omap_dvfs_register_device - function to register a device with vdd
4. omap_dvfs_add_freq_request - function to add a frequency request into
omap_dev_user_list
5. omap_dvfs_remove_freq_request - function to remove a frequency request from
omap_dev_user_list
6. omap_dvfs_find_voltage - function to find the opp corresponding to given
voltage
7. omap_device_scale - this is the function that is to be used for scaling
a specific domain. This is exported for drivers such as syslink, dspbridge
to use it while being a module.DVFS layer is initialized and basic data structures are allocated and
initialized as part of this.This patch is based on Vishwa and Thara's previous DVFS implementation, but with
major rework.note: generates "warning: 'omap_dvfs_remove_vdd_user' defined but not used"
this function will be used in future patches[nm@ti.com: misc cleanups including use voltage files from mach-omap2 dir]
[axelhaslam@ti.com: fixed issue with ondemand - required mutex unlock]
[toddpoynor@google.com: Add spinlocking of plists, GFP_ATOMIC]
Signed-off-by: Nishanth Menon
Signed-off-by: Axel Haslam
Signed-off-by: Todd Poynor
Signed-off-by: Vishwanath BS
Cc: Thara Gopinath
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia
[afzal@ti.com: fix warning]
Signed-off-by: Afzal Mohammed -
There could be dependencies between various voltage domains for
maintaining system performance or hardware limitation reasons
like VDD should be at voltage v1 when VDD is at voltage v2.
This patch introduce dependent vdd information structures in the
voltage layer which can be used to populate these dependencies
for a voltage domain.Based on original patch from Thara.
NOTE: OMAP4460 dependency table is not frozen yet, hence not added.
[nm@ti.com: cleanups and squash for OMAP3,4 data]
Signed-off-by: Vishwanath BS
Cc: Thara Gopinath
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Bootloaders should in theory setup a frequency which is enabled in
OPP table. However, there can be mismatches, and we should try
both going lower in addition to the going higher to find
a match if bootloader boots up at a OPP than the kernel thinks it
should be allowed. We also sequence the frequency and voltage settings
properly.Reported-by: Colin Cross
Signed-off-by: Nishanth Menon
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
OPP functions as described in Documentation/power/opp.txt
should be accessed under rcu_locks.Signed-off-by: Nishanth Menon
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
We use a single frequency table for multiple CPUs. But, with
OMAP4, since we have multiple CPUs, the cpu_init call for CPU1
causes freq_table previously allocated for CPU0 to be overwritten.
In addition, we dont free the table on exit path.We solve this by maintaining an atomic type counter to ensure
just a single table exists at a given time.Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Release the mpu_clk in fail paths.
Reported-by: Todd Poynor
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code does not currently use clk_init_cpufreq_table. As a
result, it is unusuable for OMAP2 and only usable only on platforms
using OPP library.Remove the unbalanced clk_exit_cpufreq_table(). Any platforms where
OPPs are not availble will fail on init because a freq table will not
be properly initialized.Signed-off-by: Nishanth Menon
[khilman@ti.com: changelog edits, and graceful failure mode changes]
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia
[afzal@ti.com: use 'omap_device_get_by_hwmod_name' for 'mpu_dev']
Signed-off-by: Afzal Mohammed -
Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Sometimes, bootloaders starts up with a frequency which is not
in the OPP table. At cpu_init, policy->cur contains the frequency
we pick at boot. It is possible that system might have fixed
it's boot frequency later on as part of power initialization.
After this condition, the first call to omap_target results in the
following:omap_getspeed(actual device frequency) != policy->cur(frequency that
cpufreq thinks that the system is at), and it is possible that
freqs.old == freqs.new (because the governor requested a scale down).We exit without triggering the notifiers in the current code, which
does'nt let code which depends on cpufreq_notify_transition to have
accurate information as to what the system frequency is.Instead, we do a normal transition if policy->cur is wrong, then,
freqs.old will be the actual cpu frequency, freqs.new will be the
actual new cpu frequency and all required notifiers have the accurate
information.Acked-by: Nishanth Menon
Signed-off-by: Colin Cross
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.Signed-off-by: Todd Poynor
Acked-by: Santosh Shilimkar
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.Also, update lpj with reference value to avoid progressive error.
Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate
them with with reference to the initial values to avoid a
progressively bigger and bigger error in the value over time.While at this, re-use the notifiers for UP/SMP since on UP machine or
UP_ON_SMP policy->cpus mask would contain only the boot CPU.Based on initial SMP support by Santosh Shilimkar.
Signed-off-by: Russell King
Signed-off-by: Santosh Shilimkar
[khilman@ti.com: due to overlap/rework, combined original Santosh patch
and Russell's rework]
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Move OMAP cpufreq driver from arch/arm/mach-omap2 into
drivers/cpufreq, along with a few cleanups:- generalize support for better handling of different SoCs in the OMAP
- use OPP layer instead of OMAP clock internals for frequency table initSigned-off-by: Santosh Shilimkar
[khilman@ti.com: move to drivers]
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
This reverts commit 23409519e1de496d7d09db37b6dc90937874b5a3.
-
DMA support for MCSPI transfer enabled and removed unwanted flag
dma_not_enabled as DMA feature is enabled in omap2_mcspi.Signed-off-by: Philip, Avinash
-
Support for DMA transmission on MCSPI added.
1. MCSPI TX and RX registers are not 256-bit aligned address, as
required for Constant address mode in DAM and SAM in EDMA, causing EDMA
error generation condition. With this commit SAM and DAM are set to
Increment address mode.
2. SPI uses EDMA AB synchronized mode for transmission and EDMA A
synchronized mode for reception, which can be used to handle large chunk
of data above 64KB with single EDMA completion interrupt.Signed-off-by: Philip, Avinash
-
Updated the size of the kernel partition on SPI flash to 3.5 MB.
Previously used size of 2.5 MB was not sufficient to hold uImage.Signed-off-by: Philip, Avinash
-
SPI clock is switching to 24 MHz on SPI bus 0 from 12 MHZ. 12 MHz done for
unifying the clock frequency between General purpose EVM and Industrial
automation EVM.Signed-off-by: Philip, Avinash
-
GFX/SGX driver has specific requriement for clock naming
convention, due to legacy platform support.
So create an alias for the clock "gfx_fclk" --> "sgx_ck".Signed-off-by: Vaibhav Hiremath
