summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* cpufreq: add support for intermediate (stable) frequenciesViresh Kumar2014-06-053-9/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Douglas Anderson, recently pointed out an interesting problem due to which udelay() was expiring earlier than it should. While transitioning between frequencies few platforms may temporarily switch to a stable frequency, waiting for the main PLL to stabilize. For example: When we transition between very low frequencies on exynos, like between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz. No CPUFREQ notification is sent for that. That means there's a period of time when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz and 300MHz. And so udelay behaves badly. To get this fixed in a generic way, introduce another set of callbacks get_intermediate() and target_intermediate(), only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION unset. get_intermediate() should return a stable intermediate frequency platform wants to switch to, and target_intermediate() should set CPU to that frequency, before jumping to the frequency corresponding to 'index'. Core will take care of sending notifications and driver doesn't have to handle them in target_intermediate() or target_index(). NOTE: ->target_index() should restore to policy->restore_freq in case of failures as core would send notifications for that. Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge back earlier cpufreq material.Rafael J. Wysocki2014-06-0346-556/+576
|\ | | | | | | | | | | Conflicts: arch/mips/loongson/lemote-2f/clock.c drivers/cpufreq/intel_pstate.c
| * cpufreq: handle calls to ->target_index() in separate routineViresh Kumar2014-05-291-23/+33
| | | | | | | | | | | | | | | | | | | | | | | | Handling calls to ->target_index() has got complex over time and might become more complex. So, its better to take target_index() bits out in another routine __target_index() for better code readability. Shouldn't have any functional impact. Tested-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: s5pv210: drop check for CONFIG_PM_VERBOSEPaul Bolle2014-05-271-4/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | A pr_err() was added in v3.1. It was guarded by a check for CONFIG_PM_VERBOSE. The Kconfig symbol PM_VERBOSE was removed in v3.0. So this pr_err() has never been used. Drop that check and clean up the message a bit. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: intel_pstate: Remove unused member name of cpudataStratos Karafotis2014-05-271-4/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | Although, a value is assigned to member name of struct cpudata, it is never used. We can safely remove it. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: Break out early when frequency equals target_freqStratos Karafotis2014-05-201-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many drivers keep frequencies in frequency table in ascending or descending order. When governor tries to change to policy->min or policy->max respectively then the cpufreq_frequency_table_target could return on first iteration. This will save some iteration cycles. So, break out early when a frequency in cpufreq_frequency_table equals to target one. Testing this during kernel compilation using ondemand governor with a frequency table in ascending order, the cpufreq_frequency_table_target returned early on the first iteration at about 30% of times called. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: Tegra: drop wrapper around tegra_update_cpu_speed()Viresh Kumar2014-05-171-7/+2Star
| | | | | | | | | | | | | | | | | | | | Tegra has implemented an unnecessary wrapper over tegra_update_cpu_speed(), i.e. tegra_target(), which wasn't doing anything apart of calling tegra_update_cpu_speed(). Get rid of that and use tegra_target() directly. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: imx6q: Remove unused includePhilipp Zabel2014-05-171-1/+0Star
| | | | | | | | | | | | | | | | | | There is no need to include delay.h. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Shawn Guo <shawn.guo@freescale.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: imx6q: Drop devm_clk/regulator_get usagePhilipp Zabel2014-05-171-14/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver is using devres managed calls incorrectly, giving the cpu0 device as first parameter instead of the cpufreq platform device. This results in resources not being freed if the cpufreq platform device is unbound, for example if probing has to be deferred for a missing regulator. Supporting probe deferral properly is a prerequisite to enabling the internal LDO bypass on i.MX6 and regulating the CPU voltage with an external regulator. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Shawn Guo <shawn.guo@freescale.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: powernow-k8: Suppress checkpatch warningsStratos Karafotis2014-05-172-108/+74Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Suppress the following checkpatch.pl warnings: - WARNING: Prefer pr_err(... to printk(KERN_ERR ... - WARNING: Prefer pr_info(... to printk(KERN_INFO ... - WARNING: Prefer pr_warn(... to printk(KERN_WARNING ... - WARNING: quoted string split across lines - WARNING: please, no spaces at the start of a line Also, define the pr_fmt macro instead of PFX for the module name. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: powernv: make local function staticBrian Norris2014-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | powernv_cpufreq_get() is only referenced in this file. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> on V2. Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: Enable big.LITTLE cpufreq driver on arm64Mark Brown2014-05-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are arm64 big.LITTLE systems so enable the big.LITTLE cpufreq driver. While IKS is not available for these systems the driver is still useful since it manages clusters with shared frequencies which is the common case for these systems. Long term combining the cpufreq-cpu0 and big.LITTLE drivers may be a more sensible option but that is substantially more complex especially in the case of IKS. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: nforce2: remove DEFINE_PCI_DEVICE_TABLE macroJingoo Han2014-05-171-1/+1
| | | | | | | | | | | | | | | | | | Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro is deprecated. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * intel_pstate: Add CPU IDs for Broadwell processorsDirk Brandewie2014-05-131-0/+3
| | | | | | | | | | | | | | Add support for Broadwell processors. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: Fix build error on some platforms that use cpufreq_for_each_*Stratos Karafotis2014-05-082-13/+9Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On platforms that use cpufreq_for_each_* macros, build fails if CONFIG_CPU_FREQ=n, e.g. ARM/shmobile/koelsch/non-multiplatform: drivers/built-in.o: In function `clk_round_parent': clkdev.c:(.text+0xcf168): undefined reference to `cpufreq_next_valid' drivers/built-in.o: In function `clk_rate_table_find': clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid' make[3]: *** [vmlinux] Error 1 Fix this making cpufreq_next_valid function inline and move it to cpufreq.h. Fixes: 27e289dce297 (cpufreq: Introduce macros for cpufreq_frequency_table iteration) Reported-and-tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * Merge back earlier 'pm-cpufreq' material.Rafael J. Wysocki2014-05-0839-391/+418
| |\
| | * PM / OPP: Move cpufreq specific OPP functions out of generic OPP libraryNishanth Menon2014-05-077-147/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CPUFreq specific helper functions for OPP (Operating Performance Points) now use generic OPP functions that allow CPUFreq to be be moved back into CPUFreq framework. This allows for independent modifications or future enhancements as needed isolated to just CPUFreq framework alone. Here, we just move relevant code and documentation to make this part of CPUFreq infrastructure. Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * PM / OPP: Remove cpufreq wrapper dependency on internal data organizationNishanth Menon2014-05-071-27/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CPUFREQ custom functions for OPP (Operating Performance Points) currently exist inside the OPP library. These custom functions currently depend on internal data structures to pick up OPP information to create the cpufreq table. For example, the cpufreq table is created precisely in the same order of how OPP entries are stored inside the list implementation. This kind of tight interdependency is purely artificial since the same functionality can be achieved using the generic OPP functions meant to do the same. This interdependency also limits the independent modification of cpufreq and OPP library. So use the generic dev_pm_opp_find_freq_ceil function that achieves the table organization as we currently use. As a result of this, we dont need to use the internal device_opp structure anymore, and we hence we can switch over to rcu lock instead of the mutex holding the internal list lock. This breaking of dependency on internal data structure imposes no change to usage of these. NOTE: This change is a precursor to moving this cpufreq specific logic out of the generic library into cpufreq. Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * cpufreq: Catch double invocations of cpufreq_freq_transition_begin/endSrivatsa S. Bhat2014-05-072-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some cpufreq drivers were redundantly invoking the _begin() and _end() APIs around frequency transitions, and this double invocation (one from the cpufreq core and the other from the cpufreq driver) used to result in a self-deadlock, leading to system hangs during boot. (The _begin() API makes contending callers wait until the previous invocation is complete. Hence, the cpufreq driver would end up waiting on itself!). Now all such drivers have been fixed, but debugging this issue was not very straight-forward (even lockdep didn't catch this). So let us add a debug infrastructure to the cpufreq core to catch such issues more easily in the future. We add a new field called 'transition_task' to the policy structure, to keep track of the task which is performing the frequency transition. Using this field, we make note of this task during _begin() and print a warning if we find a case where the same task is calling _begin() again, before completing the previous frequency transition using the corresponding _end(). We have left out ASYNC_NOTIFICATION drivers from this debug infrastructure for 2 reasons: 1. At the moment, we have no way to avoid a particular scenario where this debug infrastructure can emit false-positive warnings for such drivers. The scenario is depicted below: Task A Task B /* 1st freq transition */ Invoke _begin() { ... ... } Change the frequency /* 2nd freq transition */ Invoke _begin() { ... //waiting for B to ... //finish _end() for ... //the 1st transition ... | Got interrupt for successful ... | change of frequency (1st one). ... | ... | /* 1st freq transition */ ... | Invoke _end() { ... | ... ... V } ... ... } This scenario is actually deadlock-free because, once Task A changes the frequency, it is Task B's responsibility to invoke the corresponding _end() for the 1st frequency transition. Hence it is perfectly legal for Task A to go ahead and attempt another frequency transition in the meantime. (Of course it won't be able to proceed until Task B finishes the 1st _end(), but this doesn't cause a deadlock or a hang). The debug infrastructure cannot handle this scenario and will treat it as a deadlock and print a warning. To avoid this, we exclude such drivers from the purview of this code. 2. Luckily, we don't _need_ this infrastructure for ASYNC_NOTIFICATION drivers at all! The cpufreq core does not automatically invoke the _begin() and _end() APIs during frequency transitions in such drivers. Thus, the driver alone is responsible for invoking _begin()/_end() and hence there shouldn't be any conflicts which lead to double invocations. So, we can skip these drivers, since the probability that such drivers will hit this problem is extremely low, as outlined above. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * intel_pstate: Remove sample parameter in intel_pstate_calc_busyStratos Karafotis2014-05-071-7/+4Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit d37e2b7644 ("intel_pstate: remove unneeded sample buffers") we use only one sample. So, there is no need to pass the sample pointer to intel_pstate_calc_busy. Instead, get the pointer from cpudata. Also, remove the unused SAMPLE_COUNT macro. While at it, reformat the first line in this function. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * cpufreq: Kconfig: Fix spelling errorsStratos Karafotis2014-05-012-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Fix 4 spelling errors in help sections. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * cpufreq: Make linux-pm@vger.kernel.org official mailing listViresh Kumar2014-05-016-9/+7Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There has been confusion all the time about which mailing list to follow for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org. Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork which is a maintenance workflow problem, make linux-pm@vger.kernel.org the official mailing list for cpufreq stuff and remove all references of cpufreq@vger.kernel.org from kernel source. Later, we can request that the list be dropped entirely. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * cpufreq: exynos: Use dev_err/info function instead of pr_err/infoChanwoo Choi2014-05-012-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch uses dev_err/info function to show accurate log message with device name instead of pr_err/info function. Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * Merge branch 'cpufreq-macros' into pm-cpufreqRafael J. Wysocki2014-05-0123-216/+208Star
| | |\
| | | * sh: clk: Use cpufreq_for_each_valid_entry macro for iterationStratos Karafotis2014-04-301-15/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq core now supports the cpufreq_for_each_valid_entry macro helper for iteration over the cpufreq_frequency_table, so use it. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iterationStratos Karafotis2014-04-301-9/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq core supports the cpufreq_for_each_valid_entry macro helper for iteration over the cpufreq_frequency_table, so use it. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * thermal: cpu_cooling: Use cpufreq_for_each_valid_entry macro for iterationStratos Karafotis2014-04-301-20/+13Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq core now supports the cpufreq_for_each_valid_entry macro helper for iteration over the cpufreq_frequency_table, so use it. Also remove the redundant !! operator. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * mips: lemote 2f: Use cpufreq_for_each_entry macro for iterationStratos Karafotis2014-04-301-11/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq core now supports the cpufreq_for_each_entry macro helper for iteration over the cpufreq_frequency_table, so use it. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * mfd: db8500-prcmu: Use cpufreq_for_each_entry macro for iterationStratos Karafotis2014-04-301-11/+8Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq core now supports the cpufreq_for_each_entry macro helper for iteration over the cpufreq_frequency_table, so use it. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * ARM: davinci: da850: Use cpufreq_for_each_entry macro for iterationStratos Karafotis2014-04-301-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq core now supports the cpufreq_for_each_entry macro helper for iteration over the cpufreq_frequency_table, so use it. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-and-tested-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * cpufreq: Use cpufreq_for_each_* macros for frequency table iterationStratos Karafotis2014-04-3014-146/+116Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpufreq core now supports the cpufreq_for_each_entry and cpufreq_for_each_valid_entry macros helpers for iteration over the cpufreq_frequency_table, so use them. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * cpufreq: Introduce macros for cpufreq_frequency_table iterationStratos Karafotis2014-04-303-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many cpufreq drivers need to iterate over the cpufreq_frequency_table for various tasks. This patch introduces two macros which can be used for iteration over cpufreq_frequency_table keeping a common coding style across drivers: - cpufreq_for_each_entry: iterate over each entry of the table - cpufreq_for_each_valid_entry: iterate over each entry that contains a valid frequency. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | intel_pstate: Improve initial busy calculationDoug Smythies2014-06-021-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change makes the busy calculation using 64 bit math which prevents overflow for large values of aperf/mperf. Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | intel_pstate: add sample time scalingDirk Brandewie2014-06-021-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PID assumes that samples are of equal time, which for a deferable timers this is not true when the system goes idle. This causes the PID to take a long time to converge to the min P state and depending on the pattern of the idle load can make the P state appear stuck. The hold-off value of three sample times before using the scaling is to give a grace period for applications that have high performance requirements and spend a lot of time idle, The poster child for this behavior is the ffmpeg benchmark in the Phoronix test suite. Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | intel_pstate: Correct rounding in busy calculationDirk Brandewie2014-06-021-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changing to fixed point math throughout the busy calculation in commit e66c1768 (Change busy calculation to use fixed point math.) Introduced some inaccuracies by rounding the busy value at two points in the calculation. This change removes roundings and moves the rounding to the output of the PID where the calculations are complete and the value returned as an integer. Fixes: e66c17683746 (intel_pstate: Change busy calculation to use fixed point math.) Reported-by: Doug Smythies <dsmythies@telus.net> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | intel_pstate: Remove C0 trackingDirk Brandewie2014-06-021-12/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation) introduced a regression referenced below. The issue with "lockup" after suspend that this commit was addressing is now dealt with in the suspend path. Fixes: fcb6a15c2e7e (intel_pstate: Take core C0 time into account for core busy calculation) Link: https://bugzilla.kernel.org/show_bug.cgi?id=66581 Link: https://bugzilla.kernel.org/show_bug.cgi?id=75121 Reported-by: Doug Smythies <dsmythies@telus.net> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | Linux 3.15-rc8Linus Torvalds2014-06-021-1/+1
| | | |
* | | | Merge branch 'merge' of ↵Linus Torvalds2014-06-023-1/+3
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull powerpc fix from Ben Herrenschmidt: "Here's just one trivial patch to wire up sys_renameat2 which I seem to have completely missed so far. (My test build scripts fwd me warnings but miss the ones generated for missing syscalls)" * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc: Wire renameat2() syscall
| * | | | powerpc: Wire renameat2() syscallBenjamin Herrenschmidt2014-06-023-1/+3
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* | | | | Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds2014-06-0211-30/+28Star
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull MIPS fixes from Ralf Baechle: "A fair number of fixes across the field. Nothing terribly complicated; the one liners in below changelog should be fairly descriptive. Noteworthy is the SB1 change which the result of changes to binutils resulting in one big gas warning for most files being assembled as well as the asid_cache and branch emulation fixes which fix corruption or possible uninteded behaviour of kernel or application code. The remainder of fixes are more platforms or subsystem specific" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: R46000: Fix Micro-assembler field overflow for R4600 V2 MIPS: ptrace: Avoid smp_processor_id() in preemptible code MIPS: Lemote 2F: cs5536: mfgpt: use raw locks MIPS: SB1: Fix excessive kernel warnings. MIPS: RC32434: fix broken PCI resource initialization MIPS: malta: memory.c: Initialize the 'memsize' variable MIPS: Fix typo when reporting cache and ftlb errors for ImgTec cores MIPS: Fix inconsistancy of __NR_Linux_syscalls value MIPS: Fix branch emulation of branch likely instructions. MIPS: Fix a typo error in AUDIT_ARCH definition MIPS: Change type of asid_cache to unsigned long
| * | | | | MIPS: R46000: Fix Micro-assembler field overflow for R4600 V2Thomas Bogendoerfer2014-05-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix uasm warning, which triggered because of workaround for R4600 V2 CPUs. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6716/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: ptrace: Avoid smp_processor_id() in preemptible codeAlex Smith2014-05-281-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ptrace_{get,set}_watch_regs access current_cpu_data to get the watch register count/masks, which calls smp_processor_id(). However they are run in preemptible context and therefore trigger warnings like so: [ 6340.092000] BUG: using smp_processor_id() in preemptible [00000000] code: gdb/367 [ 6340.092000] caller is ptrace_get_watch_regs+0x44/0x220 Since the watch register count/masks should be the same across all CPUs, use boot_cpu_data instead. Note that this may need to change in future should a heterogenous system be supported where the count/masks are not the same across all CPUs (the current code is also incorrect for this scenario - current_cpu_data here would not necessarily be correct for the CPU that the target task will execute on). Signed-off-by: Alex Smith <alex.smith@imgtec.com> Reviewed-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6879/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: Lemote 2F: cs5536: mfgpt: use raw locksSebastian Andrzej Siewior2014-05-281-6/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lock is taken in the raw irq path and therefore a rawlock should be used instead of a normal spinlock. While here I drop the export symbol on that variable since there are no other users. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: linux-mips@linux-mips.org Cc: Hua Yan <yanh@lemote.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: Alex Smith <alex.smith@imgtec.com> Cc: Hongliang Tao <taohl@lemote.com> Cc: Wu Zhangjin <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/6936/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: SB1: Fix excessive kernel warnings.Ralf Baechle2014-05-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A kernel build with binutils 2.24 is going to emit warnings like CC kernel/sys.o {standard input}: Assembler messages: {standard input}:701: Warning: the 32-bit MIPS architecture does not support the `mdmx' extension {standard input}:701: Warning: the `mdmx' extension requires 64-bit FPRs {standard input}:701: Warning: the `mips3d' extension requires MIPS32 revision 2 or greater {standard input}:701: Warning: the `mips3d' extension requires 64-bit FPRs for almost every file. This is caused by changes to gas' interpretation of .set semantics. Fixed by explicitly disabling MIPS3D and MDMX for Sibyte builds. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: RC32434: fix broken PCI resource initializationGabor Juhos2014-05-261-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The parent field of the 'rc32434_res_pci_mem1' resource points to the resource itself which is obviously wrong. Due to the broken initialitazion, the PCI devices on the Mikrotik RB532 boards are not working since commit 22283178 (MIPS: avoid possible resource conflict in register_pci_controller). Remove the field initialization to fix the issue. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Reported-by: Waldemar Brodkorb <wbx@openadk.org> Cc: linux-mips@linux-mips.org Cc: Gabor Juhos <juhosg@openwrt.org> Patchwork: https://patchwork.linux-mips.org/patch/6940/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: malta: memory.c: Initialize the 'memsize' variableMarkos Chandras2014-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the 'memsize' environmental variable is not set by the bootloader the 'memsize' variable is not initialized, leading to potential memory problems. This patch fixes the problem by setting the initial value to '0' to force the kernel to set a good default memory size. Cc: <stable@vger.kernel.org> # v3.15+ Reported-by: Matheus Almeida <Matheus.Almeida@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/6984/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: Fix typo when reporting cache and ftlb errors for ImgTec coresMarkos Chandras2014-05-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduced by the following two commits: 75b5b5e0a262790fa11043fe45700499c7e3d818 "MIPS: Add support for FTLBs" 6de20451857ed14a4eecc28d08f6de5925d1cf96 "MIPS: Add printing of ES bit for Imgtec cores when cache error occurs" Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Reported-by: Matheus Almeida <Matheus.Almeida@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: stable@vger.kernel.org # v3.14+ Patchwork: https://patchwork.linux-mips.org/patch/6980/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: Fix inconsistancy of __NR_Linux_syscalls valueHuacai Chen2014-05-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, __NR_O32_Linux_syscalls, __NR_N32_Linux_syscalls and __NR_64_Linux_syscalls have the same values as __NR_Linux_syscalls in corresponding ABIs. But after commit 367f0b50e502d (MIPS: Wire up renameat2 syscall) they are not the same. I think this is incorrect and need a fix. Signed-off-by: Huacai Chen <chenhc@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/6987/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | | MIPS: Fix branch emulation of branch likely instructions.Ralf Baechle2014-05-231-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two issues: o For beql_op, beql_op, bne_op, bnel_op, blez_op, blezl_op, bgtz_op and bgtzl_op the wrong field was being checked for the instruction opcode. o For blez_op / blezl_op and bgtz_op / bgtzl_op the test was testing for the wrong opcode. This bug got introduced by d8d4e3ae0b5c179c0bfd3f0af5b352d13bea9cfa [MIPS Kprobes: Refactor branch emulation]. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Acked-by: Victor Kamensky <kamensky@cisco.com>
| * | | | | MIPS: Fix a typo error in AUDIT_ARCH definitionHuacai Chen2014-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Missing a "|" in AUDIT_ARCH_MIPSEL64N32 macro definition. Signed-off-by: Huacai Chen <chenhc@lemote.com> Reviewed-by: Markos Chandras <markos.chandras@imgtec.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/6978/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-03 12:41:11 +0200