30 Nov, 2011
28 commits
-
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
-
PRUSS driver has specific requriement for clock naming
convention, due to legacy platform support.
So create an alias for the clock "icss_uart_gclk" --> "pruss".Signed-off-by: Vaibhav Hiremath
29 Nov, 2011
7 commits
-
Irrespective of cpu-type, aren't ee supposed to do
same thing for any bypass cases (LPBYPASS/FRBYPASS/MNBYPASS),- dpll clock reparenting
- get dpll rateThis patch cleans up the code and removes the
unneccessary cpu check. -
Due to cleanup in clock tree, hwmod data also needs some cleanup.
-
The automated clock tree was completely messed up, so
this patch cleans up whole clock tree and follows the TRM. -
There were some custom API's being introduced for GFX and PRUSS
module clk_enable/disable, in order to bring the module out-of-reset.
Although there are HWMOD hooks available for doing same thing, so
now using generic omap2 clock API's, replacing these custom API's.This will mean, deleting prcm33xx.h and clock33xx.c
28 Nov, 2011
5 commits
-
SPL and U-boot partition provided with write permission in order to
update SPL and U-boot from kernel.Signed-off-by: Philip, Avinash
Signed-off-by: Hebbar, Gururaja -
14 bytes of ECC is provided for every 512 byte even though 13 byte is the
actual requirement. This is to synchronize the ECC layout with U-boot.
Extra byte is cleared to 0.Signed-off-by: Philip, Avinash
Signed-off-by: Hebbar, Gururaja -
1. BCH8 ECC support is enabled.
2. Support for BCH8 error correction using ELM module is added.
3. ECC positions updated for BCH8 in synchronized with U-boot.
4. Corrected GPMC settings for BCH8 ECC scheme.Signed-off-by: Philip, Avinash
Signed-off-by: Hebbar, Gururaja -
Module support for ELM is added.
Signed-off-by: Philip, Avinash
Signed-off-by: Hebbar, Gururaja -
Clock details are corrected
Signed-off-by: Philip, Avinash
Signed-off-by: Hebbar, Gururaja