- Feb 06, 2013
-
-
Viresh Kumar authored
"cpufreq" directory in policy->cpu is never created using sysfs_create_link(), but using kobject_init_and_add(). And so we shouldn't call sysfs_remove_link() for policy->cpu(). sysfs stuff for policy->cpu is automatically removed when we call kobject_put() for dying policy. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Tested-by:
Dirk Brandewie <dirk.brandewie@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Feb 02, 2013
-
-
Viresh Kumar authored
policy->shared_type field was added only for SoCs with ACPI support: commit 3b2d9942 Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Date: Wed Dec 14 15:05:00 2005 -0500 P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Many non-ACPI systems are filling this field by mistake, which makes its usage confusing. Lets clean it. Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
-
Viresh Kumar authored
With following patch, we need to set policy->cpus with mask of all possible cpus and policy->related_cpus would be filled automatically by the core. commit 4948b355e90080cd5ec1e91189f65a01e4186ef2 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Tue Jan 29 14:39:08 2013 +0000 cpufreq: Simplify cpufreq_add_dev() Lets fix it for all single cluster SoCs. Signed-off-by:
-
Viresh Kumar authored
For multicore SoC's, with cores sharing clock line, we are required to set policy->cpus and policy->related_cpus with mask of cpus. With following patch, we need to set policy->cpus with mask of all possible cpus and policy->related_cpus would be filled automatically by the cpufreq core. commit 4948b355e90080cd5ec1e91189f65a01e4186ef2 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Tue Jan 29 14:39:08 2013 +0000 cpufreq: Simplify cpufreq_add_dev() Current Tegra driver fills only ->related_cpus and not ->cpus, which looks to be incorrect. Lets fix it. Signed-off-by: -
Viresh Kumar authored
Currently, whenever governor->governor() is called for CPUFRREQ_GOV_START event we reset few tunables of governor. Which isn't correct, as this routine is called for every cpu hot-[un]plugging event. We should actually be resetting these only when the governor module is removed and re-installed. Signed-off-by:
-
Viresh Kumar authored
With the inclusion of following patches: 9f4eb10 cpufreq: conservative: call dbs_check_cpu only when necessary 772b4b1 cpufreq: ondemand: call dbs_check_cpu only when necessary code redundancy between the conservative and ondemand governors is introduced again, so get rid of it. [rjw: Changelog] Signed-off-by:
Fabio Baltieri <fabio.baltieri@linaro.org> Signed-off-by:
-
Viresh Kumar authored
CPUFREQ_GOV_START/STOP are called only once for all policy->cpus and hence we don't need to adapt cpufreq_governor_dbs() routine for multiple calls. So, this patch removes dbs_data->enable field entirely. And rearrange code a bit. Signed-off-by:
-
Fabio Baltieri authored
Fix governors code to set all cpu's cdbs->cpu to the the actual cpu id and use cur_policy->cpu istead of cdbs->cpu to track current governor's leader cpu. Reported-by:
-
Fabio Baltieri authored
Implement a generic helper function policy_is_shared() to replace the current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be used by code other than cpufreq governors. Suggested-by:
-
Viresh Kumar authored
SPEAr cpufreq driver supports dual core Cortex-A9 SoC's, where cpus share policy structure. Whenever we update frequency of a cpu, we must notify all policy->cpus. Signed-off-by:
-
Viresh Kumar authored
Documentation related to cpus and related_cpus is confusing and not very clear. Over that CPUFreq core has seen much changes recently. Lets update documentation and comments for cpus and related_cpus. Signed-off-by:
-
Shawn Guo authored
As multiplatform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() will be called on all the platforms to initialize cpufreq-cpu0 driver. To eliminate this undesired the effect, the patch changes cpufreq-cpu0 driver to have it instantiated as a platform_driver. Then it will only run on platforms that create the platform_device "cpufreq-cpu0". Along with the change, it also changes cpu_dev to be &pdev->dev, so that managed functions can start working, and module build gets supported too. The highbank-cpufreq driver is also updated accordingly to adapt the changes on cpufreq-cpu0. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Reviewed-by:
Mark Langsdorf <mark.langsdorf@calxeda.com> Signed-off-by:
-
Fabio Baltieri authored
Drop unused arguments from dbs_timer_init and clean dbs_timer_exit and cpufreq_governor_dbs to remove non necessary special cases. Reported-by:
-
Viresh Kumar authored
Currently cpufreq_add_dev() firsts allocates policy, calls driver->init() and then checks if this CPU is already managed or not. And if it is already managed, its policy is freed. We can save all this if we somehow know that CPU is managed or not in advance. policy->related_cpus contains the list of all valid sibling CPUs of policy->cpu. We can check this to see if the current CPU is already managed. From now on, platforms don't really need to set related_cpus from their init() routines, as the same work is done by core too. If a platform driver needs to set the related_cpus mask with some additional CPUs, other than CPUs present in policy->cpus, they are free to do it, though, as we don't override anything. [rjw: Changelog] Signed-off-by:
-
Viresh Kumar authored
This reverts commit 956f339 "cpufreq: Don't use cpu removed during cpufreq_driver_unregister". With the addition of the following commit, this change/variable is not required any more: commit b9ba2725343ae57add3f324dfa5074167f48de96 Author: Viresh Kumar <viresh.kumar@linaro.org> Date: Mon Jan 14 13:23:03 2013 +0000 cpufreq: Simplify __cpufreq_remove_dev() [rjw: Subject and changelog] Signed-off-by: -
Mark Langsdorf authored
Export cpufreq helpers in OPP to make the cpufreq-core0 and highbank-cpufreq drivers loadable as modules. Signed-off-by:
Nishanth Menon <nm@ti.com> Acked-by:
-
Nishanth Menon authored
We are GPLV2 library, so be clear in the symbols exported as well. Signed-off-by:
-
Mark Langsdorf authored
Highbank processors depend on the external ECME to perform voltage management based on a requested frequency. Communication between the A9 cores and the ECME happens over the pl320 IPC channel. Signed-off-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Rob Herring authored
The pl320 IPC allows for interprocessor communication between the highbank A9 and the EnergyCore Management Engine. The pl320 implements a straightforward mailbox protocol. Signed-off-by:
Rob Herring <rob.herring@calxeda.com> Signed-off-by:
-
Mark Langsdorf authored
The highbank clock will glitch with the current code if the clock rate is reset without relocking the PLL. Program the PLL correctly to prevent glitches. Signed-off-by:
-
Rob Herring authored
Move clk setup to twd_local_timer_common_register and rely on twd_timer_rate being 0 to force calibration if there is no clock. Remove common_setup_called as it is no longer needed. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Borislav Petkov authored
Move function prototypes to a place where they logically fit better. Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
-
Borislav Petkov authored
Make it hotplug-safe and cleanup formatting. Signed-off-by:
-
Borislav Petkov authored
Check whether we've actually already loaded acpi-cpufreq before requesting it. Signed-off-by:
-
Borislav Petkov authored
Add a helper function to return cpufreq_driver->name. Signed-off-by:
-
Borislav Petkov authored
Now that the majority of x86 CPUs out there are supported by acpi-cpufreq, we want it to load first and, in the AMD case, drop to powernow-k8 only on K8s. If, however, both powernow-k8 and acpi-cpufreq are built-in, the link order matters. Correct that. Signed-off-by:
-
Matthew Garrett authored
de3ed81d ("[CPUFREQ] Change link order of x86 cpufreq modules") changed cpufreq drivers link order so that powernow-k8 gets loaded first due to earlier K8s having BIOS bugs. However, now that acpi-cpufreq supports both AMD and Intel CPUs with HW P-states, we want to load it first, so that cases where acpi-cpufreq and powernow-k8 are both built-in and powernow-k8 initializing first, can be addressed. So, make sure that even if acpi-cpufreq gets loaded first, it errors out on K8s and powernow-k8 can be loaded then successfully. Signed-off-by:
Matthew Garrett <mjg59@srcf.ucam.org> References: http://lkml.kernel.org/r/20130118162347.GA31499@srcf.ucam.org Signed-off-by:
-
Dirk Brandewie authored
When disable_cpufreq() is called some exported functions are still being used that do not have a check for cpufreq being disabled. Add a disabled check into cpufreq_cpu_get() to return NULL if cpufreq is disabled this covers most of the exported functions. For the exported functions that do not call cpufreq_cpu_get() add an explicit check. Signed-off-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by:
-
Viresh Kumar authored
__cpufreq_remove_dev() is called on multiple occasions: cpufreq_driver unregister and cpu removals. Current implementation of this routine is overly complex without much need. If the cpu to be removed is the policy->cpu, we remove the policy first and add all other cpus again from policy->cpus and then finally call __cpufreq_remove_dev() again to remove the cpu to be deleted. Haahhhh.. There exist a simple solution to removal of a cpu: - Simply use the old policy structure - update its fields like: policy->cpu, etc. - notify any users of cpufreq, which depend on changing policy->cpu Hence this patch, which tries to implement the above theory. It is tested well by myself on ARM big.LITTLE TC2 SoC, which has 5 cores (2 A15 and 3 A7). Both A15's share same struct policy and all A7's share same policy structure. Signed-off-by:
-
Viresh Kumar authored
This patch fixes following sparse warning: drivers/cpufreq/spear-cpufreq.c:33:5: warning: symbol 'spear_cpufreq_verify' was not declared. Should it be static? Signed-off-by:
-
Viresh Kumar authored
This is how the core works: cpufreq_driver_unregister() - subsys_interface_unregister() - for_each_cpu() call cpufreq_remove_dev(), i.e. 0,1,2,3,4 when we unregister. cpufreq_remove_dev(): - Remove policy node - Call cpufreq_add_dev() for next cpu, sharing mask with removed cpu. i.e. When cpu 0 is removed, we call it for cpu 1. And when called for cpu 2, we call it for cpu 3. - cpufreq_add_dev() would call cpufreq_driver->init() - init would return mask as AND of 2, 3 and 4 for cluster A7. - cpufreq core would do online_cpu && policy->cpus Here is the BUG(). Because cpu hasn't died but we have just unregistered the cpufreq driver, online cpu would still have cpu 2 in it. And so thing go bad again. Solution: Keep cpumask of cpus that are registered with cpufreq core and clear cpus when we get a call from subsys_interface_unregister() via cpufreq_remove_dev(). Signed-off-by: -
Viresh Kumar authored
Because cpufreq core and governors worry only about the online cpus, if a cpu is hot [un]plugged, we must notify governors about it, otherwise be ready to expect something unexpected. We already have notifiers in the form of CPUFREQ_GOV_START/CPUFREQ_GOV_STOP, we just need to call them now. Signed-off-by:
-
Viresh Kumar authored
cpufreq core doesn't manage offline cpus and if driver->init() has returned mask including offline cpus, it may result in unwanted behavior by cpufreq core or governors. We need to get only online cpus in this mask. There are two places to fix this mask, cpufreq core and cpufreq driver. It makes sense to do this at common place and hence is done in core. Signed-off-by:
-
Fabio Baltieri authored
Modify update_sampling_rate() to check, and eventually immediately schedule, all CPU's do_dbs_timer delayed work. This is required in case of software coordinated CPUs, as we now have a separate delayed work for each CPU. Signed-off-by:
-
Fabio Baltieri authored
Modify conservative timer to not resample CPU utilization if recently sampled from another SW coordinated core. Signed-off-by:
-
Fabio Baltieri authored
Modify ondemand timer to not resample CPU utilization if recently sampled from another SW coordinated core. Signed-off-by:
-
Rickard Andersson authored
This patch fixes a bug that occurred when we had load on a secondary CPU and the primary CPU was sleeping. Only one sampling timer was spawned and it was spawned as a deferred timer on the primary CPU, so when a secondary CPU had a change in load this was not detected by the cpufreq governor (both ondemand and conservative). This patch make sure that deferred timers are run on all CPUs in the case of software controlled CPUs that run on the same frequency. Signed-off-by:
Rickard Andersson <rickard.andersson@stericsson.com> Signed-off-by:
-
- Feb 01, 2013
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dmLinus Torvalds authored
Pull more device-mapper fixes from Alasdair G Kergon: "A fix for stacked dm thin devices and a fix for the new dm WRITE SAME support." * tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm: dm: fix write same requests counting dm thin: fix queue limits stacking
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
PullHID fixes from Jiri Kosina: - fix i2c-hid and hidraw interaction, by Benjamin Tissoires - a quirk to make a particular device (Formosa IR receiver) work properly, by Nicholas Santos * 'for-3.8/upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: i2c-hid: fix i2c_hid_output_raw_report HID: usbhid: quirk for Formosa IR receiver HID: remove x bit from sensor doc
-
