- 30 Jan, 2015 4 commits
-
-
Srinivas Pandruvada authored
When thermal or other subsystem requests to change the policy, use that irrepective of whether cpufreq policy is PERFORMANCE or not. Without this change, when thermal subsystem passive policy wants to reduce performance, it still runs at 100%. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Kristen Carlson Accardi authored
Add a sysfs interface to display the total number of supported pstates. This value is independent of whether turbo has been enabled or disabled. Signed-off-by:
-
Kristen Carlson Accardi authored
This patch adds "turbo_pct" to the intel_pstate sysfs interface. turbo_pct will display the percentage of the total supported pstates that are in the turbo range. This value is independent of whether turbo has been disabled or not. Signed-off-by:
-
Kristen Carlson Accardi authored
Add SKL cpuid. Signed-off-by:
-
- 23 Jan, 2015 33 commits
-
-
Viresh Kumar authored
There is no possibility of any race on updating last_index, trans_table or total_trans as these are updated only by cpufreq_stat_notifier_trans() which will be called sequentially. The only place where locking is still relevant is: cpufreq_stats_update(), which updates time_in_state and last_time. This can be called by two thread in parallel, that may result in races. The two threads being: - sysfs read of time_in_state - and frequency transition that calls cpufreq_stat_notifier_trans(). Remove locking from the first case mentioned above. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Viresh Kumar authored
We need to call cpufreq_stats_update() to update 'time_in_state' for the last frequency. This is achieved by calling it from cpufreq_stat_notifier_trans(), which is called after frequency transition. But if we detect that the cpu's frequency haven't really changed and its a false POSTCHANGE notification, we don't really need to update time_in_state. It wouldn't cause any harm in calling cpufreq_stats_update() but we can avoid calling it here and call it when the frequency really changes. The result will be the same but more efficient. Reviewed-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
-
Viresh Kumar authored
cpufreq_stats_update() updates time_in_state and nothing else. It should ideally be updated only in two cases: - User requested for the current value of time_in_state. - We have switched states and so need to update time for the last state. Currently, we are also doing this while user asks for the transition table of frequencies. It wouldn't do any harm, but no good as well. Its useless here. Remove it. Reviewed-by:
-
Viresh Kumar authored
'time_in_state' can't be NULL if 'stats' is valid. These are allocated together and only if time_in_state is allocated successfully, we update policy->stats. Signed-off-by:
-
Viresh Kumar authored
Userspace is free to read value of any file from cpufreq/stats directory once they are created. __cpufreq_stats_create_table() is creating the sysfs files first and then allocating resources for them. Though it would be quite difficult to trigger the racy situation here, but for the sake of keeping sensible code lets create sysfs entries only after we are ready to go. This also does some makeup to the routine to make it look better. Reviewed-by:
-
Viresh Kumar authored
CPUFREQ_UPDATE_POLICY_CPU notifications were used only from cpufreq-stats which doesn't use it anymore. Remove them. This also decrements values of other notification macros defined after CPUFREQ_UPDATE_POLICY_CPU by 1 to remove gaps. Hopefully all users are using macro's instead of direct numbers and so they wouldn't break as macro values are changed now. Reviewed-by:
-
Viresh Kumar authored
'cpu' field of struct cpufreq_stats isn't used anymore and so can be dropped. This change makes cpufreq_stats_update_policy_cpu() empty and so that is removed as well. Reviewed-by:
-
Viresh Kumar authored
'last_cpu' was used only from cpufreq-stats and isn't used anymore. Get rid of it. Reviewed-by:
-
Viresh Kumar authored
Currently we name objects of 'struct cpufreq_stats' as 'stat' and 'stats'. Use 'stats' to make it consistent. Signed-off-by:
-
Viresh Kumar authored
All CPUs sharing a cpufreq policy share stats too. For this reason, add a stats pointer to struct cpufreq_policy and drop per-CPU variable cpufreq_stats_table used for accessing cpufreq stats so as to reduce code complexity. Reviewed-by:
-
Viresh Kumar authored
It is better to pass a struct cpufreq_stats pointer to cpufreq_stats_update() instead of a CPU number, because that's all it needs. Even if we pass a cpu number to cpufreq_stats_update(), it reads the per-cpu variable to get 'stats' out of it. So we are doing these operations unnecessarily: - First getting the cpu number to pass to cpufreq_stats_update(), stat->cpu. - And then getting stats from the cpu, per_cpu(cpufreq_stats_table, cpu). Reviewed-by:
-
Viresh Kumar authored
While we allocate stats, we do need to check if freq-table is present or not as we need to use it then. But while freeing stats, all we need to know is if stats holds a valid pointer value. There is no use of testing if cpufreq table is present or not. Don't check it. Reviewed-by:
-
Viresh Kumar authored
'cur_time' is defined in the first line and is then assigned a value in the next line. Initialize it while defining it. Signed-off-by:
-
Viresh Kumar authored
It was never used, but is there since the first commit. Remove it. Signed-off-by:
-
Viresh Kumar authored
__cpufreq_stats_create_table() is called from: - cpufreq notifier on creation of a new policy. Stats will always be NULL here. - cpufreq_stats_init() for all CPUs as cpufreq-stats might have been initialized after cpufreq driver. For any policy, 'stats' will be NULL for the first CPU only and will be valid for all other CPUs managed by the same policy. While we return for other CPUs, we don't return the right error value. It's not that we would fail with -EBUSY. But generally, this is what these return values mean: - EBUSY: we are busy right now, try again. And the retry attempt might be immediate. - EEXIST: We already have what you are trying to create and there is no need to create it again, and so no more tries are required. Reviewed-by:
-
Viresh Kumar authored
The MODULE_DESCRIPTION() string is just too long and then is broken into multiple lines just to make checkpatch happy. Rewrite it to make it more precise. Reviewed-by:
-
Viresh Kumar authored
We need to initialize completion and work only on policy allocation and not really on the policy restore side and so we better move this piece of code to cpufreq_policy_alloc(). Signed-off-by:
-
Viresh Kumar authored
CPUFREQ_STICKY flag is set by drivers which don't want to get unregistered even if cpufreq-core isn't able to initialize policy for any CPU. When this flag isn't set, we try to unregister the driver. To find out which CPUs are registered and which are not, we try to check per_cpu cpufreq_cpu_data for all CPUs. Because we have a list of valid policies available now, we better check if the list is empty or not instead of the 'for' loop. That will be much more efficient. Signed-off-by:
-
Viresh Kumar authored
These variables are just used within adjust_jiffies() and so must be local to it. Also there is no need of a dummy routine for CONFIG_SMP case as we can take care of all that with help of macros in the same routine. It doesn't look that ugly. Signed-off-by:
-
Viresh Kumar authored
We just need to check if a 'policy' is already present for the cpu we are adding. We don't need to take all the locks and do kobject usage updates. Use the light-weight cpufreq_cpu_get_raw() routine instead. Signed-off-by:
-
Viresh Kumar authored
There is no need of this separate variable, use 'policy' instead. Signed-off-by:
-
Viresh Kumar authored
These are messing up more than the benefit they provide. It isn't a lot of code anyway, that we will compile without them. Kill them. Signed-off-by:
-
Viresh Kumar authored
We should first check if a cpufreq driver is already registered or not before updating driver_data->flags. Signed-off-by:
-
Viresh Kumar authored
There is no point finding out the 'policy' again within __cpufreq_get() when all the callers already have it. Just make them pass policy instead. Signed-off-by:
-
Viresh Kumar authored
There is no point finding out the 'policy' again within cpufreq_out_of_sync() when all the callers already have it. Just make them pass policy instead. Signed-off-by:
-
Viresh Kumar authored
Either we can be setpolicy or target type, nothing else. And so the else part of setpolicy will automatically be of has_target() type. And so we don't need to check it again. Signed-off-by:
-
Viresh Kumar authored
Remove unnecessary from find_governor's name. Signed-off-by:
-
Viresh Kumar authored
There are two 'if' blocks here, checking for !cpufreq_driver->setpolicy and has_target(). Both are actually doing the same thing, merge them. Signed-off-by:
-
Viresh Kumar authored
No need of an unnecessary line break. Signed-off-by:
-
Viresh Kumar authored
We can live without it and so we should. Signed-off-by:
-
Viresh Kumar authored
It doesn't make any sense at all and is a leftover of some earlier commit. Remove it. Signed-off-by:
-
Doug Anderson authored
We should stop cpufreq governors when we shut down the system. If we don't do this, we can end up with this deadlock: 1. cpufreq governor may be running on a CPU other than CPU0. 2. In machine_restart() we call smp_send_stop() which stops CPUs. If one of these CPUs was actively running a cpufreq governor then it may have the mutex / spinlock needed to access the main PMIC in the system (perhaps over I2C) 3. If a machine needs access to the main PMIC in order to shutdown then it will never get it since the mutex was lost when the other CPU stopped. 4. We'll hang (possibly eventually hitting the hard lockup detector). Let's avoid the problem by stopping the cpufreq governor at shutdown, which is a sensible thing to do anyway. Signed-off-by:
Doug Anderson <dianders@chromium.org> Acked-by:
-
Wolfram Sang authored
This platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
-
- 18 Jan, 2015 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "We've been sitting on our fixes branch for a while, so this batch is unfortunately on the large side. A lot of these are tweaks and fixes to device trees, fixing various bugs around clocks, reg ranges, etc. There's also a few defconfig updates (which are on the late side, no more of those). All in all the diffstat is bigger than ideal at this time, but nothing in here seems particularly risky" * tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits) reset: sunxi: fix spinlock initialization ARM: dts: disable CCI on exynos5420 based arndale-octa drivers: bus: check cci device tree node status ARM: rockchip: disable jtag/sdmmc autoswitching on rk3288 ARM: nomadik: fix up leftover device tree pins ARM: at91: board-dt-sama5: add phy_fixup to override NAND_Tree ARM: at91/dt: sam9263: Add missing clocks to lcdc node ARM: at91: sama5d3: dt: correct the sound route ARM: at91/dt: sama5d4: fix the timer reg length ARM: exynos_defconfig: Enable LM90 driver ARM: exynos_defconfig: Enable options for display panel support arm: dts: Use pmu_system_controller phandle for dp phy ARM: shmobile: sh73a0 legacy: Set .control_parent for all irqpin instances ARM: dts: berlin: correct BG2Q's SM GPIO location. ARM: dts: berlin: add broken-cd and set bus width for eMMC in Marvell DMP DT ARM: dts: berlin: fix io clk and add missing core clk for BG2Q sdhci2 host ARM: dts: Revert disabling of smc91x for n900 ARM: dts: imx51-babbage: Fix ULPI PHY reset modelling ARM: dts: dra7-evm: fix qspi device tree partition size ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT ...
-
git://git.linaro.org/people/mike.turquette/linuxLinus Torvalds authored
Pull clock driver fixes from Mike Turquette: "Small number of fixes for clock drivers and a single null pointer dereference fix in the framework core code. The driver fixes vary from fixing section mismatch warnings to preventing machines from hanging (and preventing developers from crying)" * tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux: clk: fix possible null pointer dereference Revert "clk: ppc-corenet: Fix Section mismatch warning" clk: rockchip: fix deadlock possibility in cpuclk clk: berlin: bg2q: remove non-exist "smemc" gate clock clk: at91: keep slow clk enabled to prevent system hang clk: rockchip: fix rk3288 cpuclk core dividers clk: rockchip: fix rk3066 pll lock bit location clk: rockchip: Fix clock gate for rk3188 hclk_emem_peri clk: rockchip: add CLK_IGNORE_UNUSED flag to fix rk3066/rk3188 USB Host
-
