summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* cpufreq: exynos: Remove unwanted EXPORT_SYMBOLSachin Kamat2013-11-203-3/+0
| | | | | | | | | | The init functions are linked statically (no support for dynamic loading) and have no other users. Hence remove EXPORT_SYMBOL for these functions. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: tegra: don't error target() when suspendedStephen Warren2013-11-201-3/+1
| | | | | | | | | | | | | | | | | | | | d4019f0a92ab "cpufreq: move freq change notifications to cpufreq core" added code to the cpufreq core to print an error if a cpufreq driver's .target() function returned an error. This exposed the fact that Tegra's cpufreq driver returns an error when it is ignoring requests due to the system being suspended. Modify Tegra's .target() function not to return an error in this case; this prevents the error prints. The argument is that since the suspend hook can't and doesn't inform the cpufreq core when its requests will be ignored, there's no way for the cpufreq core to squelch them, so it's not an error for the requests to keep coming. This change make the Tegra driver consistent with how the Exynos handles the same situation. Note that s5pv210-cpufreq.c probably suffers from this same issue though. Fixes: d4019f0a92ab (cpufreq: move freq change notifications to cpufreq core) Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: governor: Remove fossil comment in the cpufreq_governor_dbs()lan,Tianyu2013-11-161-4/+0
| | | | | | | | | The related code has been changed and the comment is out of date. So remove it. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: OMAP: Fix compilation error 'r & ret undeclared'viresh kumar2013-11-141-0/+1
| | | | | | | | | | | | | | | | | | With a recent change "d4019f0 cpufreq: move freq change notifications to cpufreq core" few variables (r & ret) are removed by mistake and hence these warnings: drivers/cpufreq/omap-cpufreq.c: In function omap_target: drivers/cpufreq/omap-cpufreq.c:64:2: error: ret undeclared (first use in this function) drivers/cpufreq/omap-cpufreq.c:64:2: note: each undeclared identifier is reported only once for each function it appears in drivers/cpufreq/omap-cpufreq.c:94:3: error: r undeclared (first use in this function) drivers/cpufreq/omap-cpufreq.c:116:1: warning: control reaches end of non-void function [-Wreturn-type] Lets fix them by declaring those variables again. Fixes: d4019f0a92ab (cpufreq: move freq change notifications to cpufreq core) Reported-by: Sebastian Capella <sebastian.capella@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: conservative: set requested_freq to policy max when it is over ↵Xiaoguang Chen2013-11-121-0/+3
| | | | | | | | | | | policy max When requested_freq is over policy->max, set it to policy->max. This can help to speed up decreasing frequency. Signed-off-by: Xiaoguang Chen <chenxg@marvell.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: conservative: fix requested_freq reduction issueXiaoguang Chen2013-11-071-1/+6
| | | | | | | | | | | | | | | When decreasing frequency, requested_freq may be less than freq_target, So requested_freq minus freq_target may be negative, But reqested_freq's unit is unsigned int, then the negative result will be one larger interger which may be even higher than requested_freq. This patch is to fix such issue. when result becomes negative, set requested_freq as the min value of policy. Signed-off-by: Xiaoguang Chen <chenxg@marvell.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* intel_pstate: skip the driver if ACPI has power mgmt optionAdrian Huang2013-11-071-0/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do not load the Intel pstate driver if the platform firmware (ACPI BIOS) supports the power management alternatives. The ACPI BIOS indicates that the OS control mode can be used if the _PSS (Performance Supported States) is defined in ACPI table. For the OS control mode, the Intel pstate driver will be loaded. HP BIOS has several power management modes (firmware, OS-control and so on). For the OS control mode in HP BIOS, the Intel p-state driver will be loaded. When the customer chooses the firmware power management in HP BIOS, the Intel p-state driver will be ignored. I put hw_vendor_info vendor_info in case other vendors (Dell, Lenovo...) have their firmware power management. Vendors should make sure their firmware power management works properly, and they can go for adding their vendor info to the variable. I have verified the patch on HP ProLiant servers. The patch worked correctly. Signed-off-by: Adrian Huang <adrianhuang0701@gmail.com> [rjw: Fixed up !CONFIG_ACPI build] [Linda Knippers: As Adrian has recently left HP, I retested the updated patch on an HP ProLiant server and verified that it is behaving correctly. When the BIOS is configured for OS control for power management, the intel_pstate driver loads as expected. When the BIOS is configured to provide the power management, the intel_pstate driver does not load and we get the pcc_cpufreq driver instead.] Signed-off-by: Linda Knippers <linda.knippers@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: ondemand: Remove redundant return statementStratos Karafotis2013-11-011-1/+0
| | | | | | | | | | After commit dfa5bb622555 (cpufreq: ondemand: Change the calculation of target frequency), this return statement is no longer needed. Reported-by: Henrik Nilsson <Karl.Henrik.Nilsson@gmail.com> 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: move freq change notifications to cpufreq coreViresh Kumar2013-10-3140-624/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code as flag: CPUFREQ_ASYNC_NOTIFICATION is already set for them. All drivers are also modified in this patch to avoid breaking 'git bisect', as double notification would happen otherwise. Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Russell King <linux@arm.linux.org.uk> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Nicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: distinguish drivers that do asynchronous notificationsViresh Kumar2013-10-313-1/+9
| | | | | | | | | | | | | | | | | | | There are few special cases like exynos5440 which doesn't send POSTCHANGE notification from their ->target() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. From which they finally send POSTCHANGE notification. Its better if we distinguish them from other cpufreq drivers in some way so that core can handle them specially. So this patch introduces another flag: CPUFREQ_ASYNC_NOTIFICATION, which will be set by such drivers. This also changes exynos5440-cpufreq.c and powernow-k8 in order to set this flag. Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq/intel_pstate: Add static declarations to internal functionsDirk Brandewie2013-10-311-2/+2
| | | | | | | | | | | | Fixes warnings reported by kbuild test robot sparse warnings: (new ones prefixed by >>) drivers/cpufreq/intel_pstate.c:729:6: sparse: symbol 'copy_pid_params' was not declared. Should it be static? drivers/cpufreq/intel_pstate.c:739:6: sparse: symbol 'copy_cpu_funcs' was not declared. Should it be static? Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: arm_big_little: reconfigure switcher behavior at run timeNicolas Pitre2013-10-311-3/+51
| | | | | | | | | | | | | The b.L switcher can be turned on/off at run time. It is therefore necessary to change the cpufreq driver behavior accordingly. The driver must be unregistered/registered with the cpufreq core to reconfigure freq tables for the virtual or actual CPUs. This is accomplished via the b.L switcher notifier callback. Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: arm_big_little: add in-kernel switching (IKS) supportViresh Kumar2013-10-312-31/+337
| | | | | | | | | | | | | | | | | This patch adds IKS (In Kernel Switcher) support to cpufreq driver. This creates a combined freq table for A7-A15 CPU pairs. A7 frequencies are virtualized and scaled down to half the actual frequencies to approximate a linear scale across the combined A7+A15 range. When the requested frequency change crosses the A7-A15 boundary a cluster switch is invoked. Based on earlier work from Sudeep KarkadaNagesha. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ARM: vexpress/TC2: register vexpress-spc cpufreq deviceSudeep KarkadaNagesha2013-10-301-0/+2
| | | | | | | | | | This patch adds vexpress-spc platform device to enables the vexpress SPC cpufreq interface driver. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Acked-by: Pawel Moll <Pawel.Moll@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: arm_big_little: add vexpress SPC interface driverSudeep KarkadaNagesha2013-10-303-0/+79
| | | | | | | | | | | | | | | The TC2(i.e. CA15_A7) Versatile Express has external Cortex M3 based power controller which is responsible for CPU DVFS and SPC provides the interface for the same. This patch adds a tiny interface driver to check if OPPs are initialised by SPC platform code and register the arm_big_little cpufreq driver. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ARM: vexpress/TC2: add cpu clock supportSudeep KarkadaNagesha2013-10-301-0/+102
| | | | | | | | | | | | | | | On TC2, the cpu clocks are controlled by the external M3 microcontroller and SPC provides the interface between the CPU and the power controller. The generic cpufreq drivers use the clock APIs to get the cpu clocks. This patch add virtual spc clocks for all the cpus to control the cpu operating frequency via the clock framework. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Pawel Moll <Pawel.Moll@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ARM: vexpress/TC2: add support for CPU DVFSSudeep KarkadaNagesha2013-10-305-5/+281
| | | | | | | | | | | | | | | | | | | SPC(Serial Power Controller) on TC2 also controls the CPU performance operating points which is essential to provide CPU DVFS. The M3 microcontroller provides two sets of eight performance values, one set for each cluster (CA15 or CA7). Each of this value contains the frequency(kHz) and voltage(mV) at that performance level. It expects these performance level to be passed through the SPC PERF_LVL registers. This patch adds support to populate these performance levels from M3, build the mapping to CPU OPPs at the boot and then use it to get and set the CPU performance level runtime. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Pawel Moll <Pawel.Moll@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: create per policy rwsem instead of per CPU cpu_policy_rwsemviresh kumar2013-10-252-79/+45
| | | | | | | | | | | | | | | | We have per-CPU cpu_policy_rwsem for cpufreq core, but we never use all of them. We always use rwsem of policy->cpu and so we can actually make this rwsem per policy instead. This patch does this change. With this change other tricky situations are also avoided now, like which lock to take while we are changing policy->cpu, etc. Suggested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* intel_pstate: Add Baytrail supportDirk Brandewie2013-10-251-0/+35
| | | | | | | Add support for the Baytrail processor. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* intel_pstate: Refactor driver to support CPUs with different MSR layoutsDirk Brandewie2013-10-251-46/+98
| | | | | | | | | Non-core processors have a different MSR layout to commumicate P state information. Refactor the driver to use CPU dependent accessors to P state information. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Implement light weight ->target_index() routineViresh Kumar2013-10-2550-759/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Russell King <linux@arm.linux.org.uk> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
* Merge back earlier 'pm-cpufreq' material.Rafael J. Wysocki2013-10-2574-1513/+464
|\ | | | | | | | | Conflicts: drivers/cpufreq/omap-cpufreq.c
| * cpufreq / governor: Remove fossil commentLan Tianyu2013-10-171-11/+0
| | | | | | | | | | | | | | | | | | | | cpufreq_set_policy() has been changed to origin __cpufreq_set_policy() and policy->lock has been converted to rewrite lock by commit 5a01f2. So remove the comment. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: exynos4210: Use the common clock framework to set APLL clock rateLukasz Majewski2013-10-171-59/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the exynos4210_set_apll() function, the APLL frequency is set with direct register manipulation. Such approach is not allowed in the common clock framework. The frequency is changed, but the corresponding clock value is not updated. This causes wrong frequency read from cpufreq's cpuinfo_cur_freq sysfs attribute. Also direct manipulation with PLL's S parameter has been removed. It is already done at PLL35xx code. Tested at: - Exynos4210 - Trats board (linux 3.12-rc4) Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: exynos4x12: Use the common clock framework to set APLL clock rateLukasz Majewski2013-10-171-61/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the exynos4x12_set_apll() function, the APLL frequency is set with direct register manipulation. Such approach is not allowed in the common clock framework. The frequency is changed, but the corresponding clock value is not updated. This causes wrong frequency read from cpufreq's cpuinfo_cur_freq sysfs attribute. Also direct manipulation with PLL's S parameter has been removed. It is already done at PLL35xx code. Tested at: - Exynos4412 - Trats2 board (linux 3.12-rc4) Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: Detect spurious invocations of update_policy_cpu()Srivatsa S. Bhat2013-10-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The function update_policy_cpu() is expected to be called when the policy->cpu of a cpufreq policy is to be changed: ie., the new CPU nominated to become the policy->cpu is different from the old one. Print a warning if it is invoked with new_cpu == old_cpu, since such an invocation might hint at a faulty logic in the caller. Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> 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>
| * cpufreq: pmac64: enable cpufreq on iMac G5 (iSight) modelAaro Koskinen2013-10-171-1/+2
| | | | | | | | | | | | | | | | | | Enable cpufreq on iMac G5 (iSight) model. Tested with the 2.1 GHz version. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: pmac64: provide cpufreq transition latency for older G5 modelsAaro Koskinen2013-10-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | Currently cpufreq ondemand governor cannot used on older G5 models, because the transition latency is set to CPUFREQ_ETERNAL. Provide a value based on a measurement on Xserve G5, which happens to be also the highest allowed latency. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: pmac64: speed up frequency switchAaro Koskinen2013-10-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some functions on switch path use msleep() which is inaccurate, and depends on HZ. With HZ=100 msleep(1) takes actually over ten times longer. Using usleep_range() we get more accurate sleeps. I measured the "pfunc_slewing_done" polling to take 300us at max (on 2.3GHz dual-processor Xserve G5), so using 500us sleep there should be fine. With the patch, g5_switch_freq() duration drops from ~50ms to ~10ms on Xserve with HZ=100. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: highbank-cpufreq: Enable Midway/ECX-2000Mark Langsdorf2013-10-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Calxeda's new ECX-2000 part uses the same cpufreq interface as highbank, so add it to the driver's compatibility list. This is a minor change that can safely be applied to the 3.10 and 3.11 stable trees. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * exynos-cpufreq: fix false return check from "regulator_set_voltage"Manish Badarkhe2013-10-171-1/+1
| | | | | | | | | | | | | | | | | | | | Currently, code checks false return value from "regulator_set_voltage" to show failure message. Modify the code to check proper return value from "regulator_set_voltage". Signed-off-by: Manish Badarkhe <badarkhe.manish@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * speedstep-centrino: Remove unnecessary bracesEvgeny Kapaev2013-10-171-2/+1
| | | | | | | | | | | | | | | | As per coding style, braces {} are not necessary for single statement block Signed-off-by: Evgeny Kapaev <orener300@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * acpi-cpufreq: Add comment under ACPI_ADR_SPACE_SYSTEM_IO caseViresh Kumar2013-10-161-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | policy->cur is now set by cpufreq core when cpufreq_driver->get() is defined and so drivers aren't required to set it. When space_id is ACPI_ADR_SPACE_SYSTEM_IO for acpi cpufreq driver it doesn't set ->get to a valid function pointer and so policy->cur is required to be set by driver. This is already followed in acpi-cpufreq driver. This patch adds a comment describing why we need to set policy->cur from driver. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: arm-big-little: use clk_get instead of clk_get_sysSudeep KarkadaNagesha2013-10-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently clk_get_sys is used with cpu-cluster.<n> as the device id which is incorrect. It should be connection/consumer ID instead. It is possible to specify input clock in the cpu device node along with the optional clock-name. clk_get_sys can't handle that. This patch replaces clk_get_sys with clk_get to extend support for clocks specified in the device tree cpu node. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: exynos: Show a list of available frequenciesJungseok Lee2013-10-161-0/+1
| | | | | | | | | | | | | | | | | | This patch adds freq_attr to show a list of exynos5440 scaling available frequencies through sysfs. Common exynos driver already supports this attribute. Signed-off-by: Jungseok Lee <jays.lee@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: sa11x0: Fix build breakage after "Expose frequency table"Viresh Kumar2013-10-161-2/+1
| | | | | | | | | | | | | | | | | | Fix build breakage introduced by commit 22c8b4f (cpufreq: sa11x0: Expose frequency table). [rjw: Changelog] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: tegra: use cpufreq_generic_init()Viresh Kumar2013-10-161-4/+9
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: spear: use cpufreq_generic_init()Viresh Kumar2013-10-161-12/+2
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: sa11x0: use cpufreq_generic_init()Viresh Kumar2013-10-162-10/+2
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: s5pv210: use cpufreq_generic_init()Viresh Kumar2013-10-161-3/+1
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: s3c: use cpufreq_generic_init()Viresh Kumar2013-10-163-19/+5
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: pmac64: use cpufreq_generic_init()Viresh Kumar2013-10-161-8/+1
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: pmac32: use cpufreq_generic_init()Viresh Kumar2013-10-161-6/+1
| | | | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: pasemi: use cpufreq_generic_init()Viresh Kumar2013-10-161-8/+1
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: omap: use cpufreq_generic_init()Viresh Kumar2013-10-161-30/+11
| | | | | | | | | | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. This also rearranges the code a bit to make it more sensible. Also removes some unnecessary checks. Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: maple: use cpufreq_generic_init()Viresh Kumar2013-10-161-8/+1
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: loongson2: use cpufreq_generic_init()Viresh Kumar2013-10-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. This driver wasn't setting transition_latency and so is getting set to 0 by default. Lets mark it explicitly by calling the generic routine with transition_latency as 0. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: kirkwood: use cpufreq_generic_init()Viresh Kumar2013-10-161-4/+1
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: imx6q: use cpufreq_generic_init()Viresh Kumar2013-10-161-12/+1
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * cpufreq: exynos: use cpufreq_generic_init()Viresh Kumar2013-10-162-18/+3
| | | | | | | | | | | | | | | | Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
OpenPOWER on IntegriCloud