summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/omap-cpufreq.c
Commit message (Collapse)AuthorAgeFilesLines
* PM / OPP: Update OPP users to put referenceViresh Kumar2017-01-301-3/+1Star
| | | | | | | | | | | | | | | | | | | | | | | This patch updates dev_pm_opp_find_freq_*() routines to get a reference to the OPPs returned by them. Also updates the users of dev_pm_opp_find_freq_*() routines to call dev_pm_opp_put() after they are done using the OPPs. As it is guaranteed the that OPPs wouldn't get freed while being used, the RCU read side locking present with the users isn't required anymore. Drop it as well. This patch also updates all users of devfreq_recommended_opp() which was returning an OPP received from the OPP core. Note that some of the OPP core routines have gained rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs within them. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> [Devfreq] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* remove lots of IS_ERR_VALUE abusesArnd Bergmann2016-05-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* cpufreq: Use consistent prefixing via pr_fmtJoe Perches2016-04-091-1/+4
| | | | | | | | | | | | Use the more common kernel style adding a define for pr_fmt. Miscellanea: o Remove now unused PFX defines Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Convert printk(KERN_<LEVEL> to pr_<level>Joe Perches2016-04-091-2/+2
| | | | | | | | | | | | | | Use the more common logging style. Miscellanea: o Coalesce formats o Realign arguments o Add a missing space between a coalesced format Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: drop owner assignment from platform_driversWolfram Sang2014-10-201-1/+0Star
| | | | | | | A 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>
* cpufreq: add 'freq_table' in struct cpufreq_policyViresh Kumar2014-03-121-1/+0Star
| | | | | | | | | | | freq table is not per CPU but per policy, so it makes more sense to keep it within struct cpufreq_policy instead of a per-cpu variable. This patch does it. Over that, there is no need to set policy->freq_table to NULL in ->exit(), as policy structure is going to be freed soon. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: introduce cpufreq_generic_get() routineViresh Kumar2014-01-171-22/+10Star
| | | | | | | | | | | | | | | | | CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), to get CPUs clk rate, have similar sort of code used in most of them. This patch adds a generic ->get() which will do the same thing for them. All those drivers are required to now is to set .get to cpufreq_generic_get() and set their clk pointer in policy->clk during ->init(). Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Mark ARM drivers with CPUFREQ_NEED_INITIAL_FREQ_CHECK flagViresh Kumar2014-01-061-1/+1
| | | | | | | | | | | | | | | | | | | Sometimes boot loaders set CPU frequency to a value outside of frequency table present with cpufreq core. In such cases CPU might be unstable if it has to run on that frequency for long duration of time and so its better to set it to a frequency which is specified in frequency table. On some systems we can't really say what frequency we're running at the moment and so for these we shouldn't check if we are running at a frequency present in frequency table. And so we really can't force this for all the cpufreq drivers. Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that will be marked by platforms which want to go for this check at boot time. Initially this is done for all ARM platforms but others may follow if required. Signed-off-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: move freq change notifications to cpufreq coreViresh Kumar2013-10-311-25/+13Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Implement light weight ->target_index() routineViresh Kumar2013-10-251-28/+3Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-251-50/+14Star
|\ | | | | | | | | Conflicts: drivers/cpufreq/omap-cpufreq.c
| * cpufreq: omap: use cpufreq_generic_init()Viresh Kumar2013-10-161-30/+11Star
| | | | | | | | | | | | | | | | | | | | | | | | 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: omap: don't initialize part of policy set by coreViresh Kumar2013-10-161-4/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). 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: omap: Use generic cpufreq routinesViresh Kumar2013-10-161-14/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the OMAP driver. 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: omap: call cpufreq_frequency_table_put_attr()Viresh Kumar2013-09-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if they have called cpufreq_frequency_table_get_attr() in their init path. This driver was missing this part and is fixed with this patch. 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: omap: use cpufreq_table_validate_and_show()Viresh Kumar2013-09-301-3/+1Star
| | | | | | | | | | | | | | | | | | Lets use cpufreq_table_validate_and_show() instead of calling cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr(). Acked-by: 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>
* | PM / OPP: rename header to linux/pm_opp.hNishanth Menon2013-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | Since Operating Performance Points (OPP) functions are specific to device specific power management, be specific and rename opp.h to pm_opp.h Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | PM / OPP: rename data structures to dev_pm equivalentsNishanth Menon2013-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Operating Performance Points (OPP) data structures are specific to device specific power management, be specific and rename opp_* data structures in OPP library with dev_pm_opp_* equivalent. Affected structures are: struct opp enum opp_event Minor checkpatch warning resulting of this change was fixed as well. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | PM / OPP: rename functions to dev_pm_opp*Nishanth Menon2013-10-251-4/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | Since Operating Performance Points (OPP) functions are specific to device specific power management, be specific and rename opp_* accessors in OPP library with dev_pm_opp_* equivalent. Affected functions are: opp_get_voltage opp_get_freq opp_get_opp_count opp_find_freq_exact opp_find_freq_floor opp_find_freq_ceil opp_add opp_enable opp_disable opp_get_notifier opp_init_cpufreq_table opp_free_cpufreq_table Reported-by: Randy Dunlap <rdunlap@infradead.org> 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: delete __cpuinit usage from all cpufreq filesPaul Gortmaker2013-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/cpufreq uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 [v2: leave 2nd lines of args misaligned as requested by Viresh] Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: cpufreq@vger.kernel.org Cc: linux-pm@vger.kernel.org Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error casesViresh Kumar2013-06-241-3/+3
| | | | | | | | | | | | | | | | | PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both should be called or both shouldn't be. In case we have started PRECHANGE notifier and found an error, we must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of calling notifiers is complete. Omap driver was taking care of it well, but wasn't restoring freqs.new to freqs.old in some cases. I wasn't required to add code for it as moving PRECHANGE notifier down was a better option, so that we call it just before starting frequency transition. Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
* cpufreq: OMAP: instantiate omap-cpufreq as a platform_driverNishanth Menon2013-04-101-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As multi-platform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init() will be called on all the platforms to initialize omap-cpufreq driver. Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device tree entries. To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist for OMAP in a single image, we need to ensure the following: 1. With device tree boot, we use cpufreq-cpu0 2. With non device tree boot, we use omap-cpufreq In the case of (1), we will have cpu OPPs and regulator registered as part of the device tree nodes, to ensure that omap-cpufreq and cpufreq-cpu0 don't conflict in managing the frequency of the same CPU, we should not permit omap-cpufreq to be probed. In the case of (2), we will not have the cpufreq-cpu0 device, hence only omap-cpufreq will be active. To eliminate this undesired these effects, we change omap-cpufreq driver to have it instantiated as a platform_driver and register "omap-cpufreq" device only when booted without device tree nodes on OMAP platforms. This allows the following: a) Will only run on platforms that create the platform_device "omap-cpufreq". b) Since the platform_device is registered only when device tree nodes are *not* populated, omap-cpufreq driver does not conflict with the usage of cpufreq-cpu0 driver which is used on OMAP platforms when device tree nodes are present. Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35 (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) [robherring2@gmail.com: reported conflict of omap-cpufreq vs other driver in an non-device tree supported boot] Reported-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: drivers: Remove unnecessary assignments of policy-> membersViresh Kumar2013-04-021-3/+1Star
| | | | | | | | | | | | | Some assignments of policy-> min/max/cur/cpuinfo.min_freq/cpuinfo.max_freq aren't required as part of it is done by cpufreq driver or cpufreq core. Remove them. At some places we merge multiple lines together too. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Notify all policy->cpus in cpufreq_notify_transition()Viresh Kumar2013-04-021-9/+2Star
| | | | | | | | | | | | | | | | policy->cpus contains all online cpus that have single shared clock line. And their frequencies are always updated together. Many SMP system's cpufreq drivers take care of this in individual drivers but the best place for this code is in cpufreq core. This patch modifies cpufreq_notify_transition() to notify frequency change for all cpus in policy->cpus and hence updates all users of this API. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Remove unnecessary use of policy->shared_typeViresh Kumar2013-02-021-3/+1Star
| | | | | | | | | | | | | | | | | | | policy->shared_type field was added only for SoCs with ACPI support: commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36 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: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: OMAP: use RCU locks around usage of OPPNishanth Menon2013-01-221-0/+3
| | | | | | | | | | | | OPP pointer is RCU protected, hence after finding it, de-reference also should be protected with the same RCU context else the OPP pointer may become invalid. Reported-by: Alexander Holler <holler@ahsoftware.de> Tested-by: Alexander Holler <holler@ahsoftware.de> Acked-by: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: OMAP: use get_cpu_device() instead of omap_device APIKevin Hilman2012-10-081-5/+3Star
| | | | | | | | | | | | OMAP PM core code has moved to using the existing, generic CPU devices for attaching OPPs, so the CPUfreq driver can now use the generic get_cpu_device() API instead of the OMAP-specific omap_device API. This allows us to remove the last <plat/*> include from this driver. Cc: Paul Walmsley <paul@pwsan.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includesPaul Walmsley2012-10-081-18/+1Star
| | | | | | | | | | | | | | | | OMAP core code now has SoC-independent clock alias for the scalable CPU clock. Using it means driver is SoC independent and will work for AM3xxx SoCs as well as OMAP1/3/4. While here, remove some unnecessary plat/ includes that are interfering with multi-subarch ARM kernels. Signed-off-by: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: updated already changed clock aliases] Signed-off-by: Tony Lindgren <tony@atomide.com> [khilman@ti.com: minor shortlog/changelog updates] Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: remove unused <plat/omap-pm.h>Kevin Hilman2012-10-081-1/+0Star
| | | | | | | The <plat/*.h> headers are going away, and this one is not used. remove it. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: ensure valid clock rate before scalingKevin Hilman2012-10-081-0/+8
| | | | | | | | | | | | | | | | | | | Ensure the clock rate that will be used is a valid one before attempting to scale the voltage. Currently the driver assumes it has a valid frequency from the OPP table, but boards using different system oscillators might not have exact matches with the OPP table, and result in a failing call to clk_set_rate(). This is particularily bad because the voltage may be scaled even though the frequency is not. This will obviously lead to some unpredictable behavior, especially if the frequency is high and the voltage is dropped. Thanks to Joni Lapilainen for reporting crashes seen on 3430/n900. Reported-by: Joni Lapilainen <joni.lapilainen@gmail.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: Check IS_ERR() instead of NULL for omap_device_get_by_hwmod_nameAxel Lin2012-09-191-2/+2
| | | | | | | | omap_device_get_by_hwmod_name() returns ERR_PTR on error. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* cpufreq: OMAP: remove loops_per_jiffy recalculate for smpRichard Zhao2012-09-141-35/+0Star
| | | | | | | | | | | | With ARM smp common code recalculating loops_per_jiffy in a cpufreq transiton notifier call, the loops_per_jiffy recalculate in omap-cpufreq driver becomes redundant. Remove it. Signed-off-by: Richard Zhao <richard.zhao@freescale.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* cpufreq: OMAP: Handle missing frequency table on SMP systemsRajendra Nayak2012-08-091-1/+3
| | | | | | | | | | | | | | | | On OMAP4, if the first CPU fails to get a valid frequency table (this could happen if the platform does not register any OPP table), the subsequent CPU instances end up dealing with a NULL freq_table and crash. Check for an already existing freq_table, before trying to create one, and increment the freq_table_users only if the table is sucessfully created. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: <linux-pm@vger.kernel.org> Signed-off-by: Kevin Hilman <khilman@ti.com>
* Merge tag 'split-asm_system_h-for-linus-20120328' of ↵Linus Torvalds2012-03-291-1/+0Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system Pull "Disintegrate and delete asm/system.h" from David Howells: "Here are a bunch of patches to disintegrate asm/system.h into a set of separate bits to relieve the problem of circular inclusion dependencies. I've built all the working defconfigs from all the arches that I can and made sure that they don't break. The reason for these patches is that I recently encountered a circular dependency problem that came about when I produced some patches to optimise get_order() by rewriting it to use ilog2(). This uses bitops - and on the SH arch asm/bitops.h drags in asm-generic/get_order.h by a circuituous route involving asm/system.h. The main difficulty seems to be asm/system.h. It holds a number of low level bits with no/few dependencies that are commonly used (eg. memory barriers) and a number of bits with more dependencies that aren't used in many places (eg. switch_to()). These patches break asm/system.h up into the following core pieces: (1) asm/barrier.h Move memory barriers here. This already done for MIPS and Alpha. (2) asm/switch_to.h Move switch_to() and related stuff here. (3) asm/exec.h Move arch_align_stack() here. Other process execution related bits could perhaps go here from asm/processor.h. (4) asm/cmpxchg.h Move xchg() and cmpxchg() here as they're full word atomic ops and frequently used by atomic_xchg() and atomic_cmpxchg(). (5) asm/bug.h Move die() and related bits. (6) asm/auxvec.h Move AT_VECTOR_SIZE_ARCH here. Other arch headers are created as needed on a per-arch basis." Fixed up some conflicts from other header file cleanups and moving code around that has happened in the meantime, so David's testing is somewhat weakened by that. We'll find out anything that got broken and fix it.. * tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system: (38 commits) Delete all instances of asm/system.h Remove all #inclusions of asm/system.h Add #includes needed to permit the removal of asm/system.h Move all declarations of free_initmem() to linux/mm.h Disintegrate asm/system.h for OpenRISC Split arch_align_stack() out from asm-generic/system.h Split the switch_to() wrapper out of asm-generic/system.h Move the asm-generic/system.h xchg() implementation to asm-generic/cmpxchg.h Create asm-generic/barrier.h Make asm-generic/cmpxchg.h #include asm-generic/cmpxchg-local.h Disintegrate asm/system.h for Xtensa Disintegrate asm/system.h for Unicore32 [based on ver #3, changed by gxt] Disintegrate asm/system.h for Tile Disintegrate asm/system.h for Sparc Disintegrate asm/system.h for SH Disintegrate asm/system.h for Score Disintegrate asm/system.h for S390 Disintegrate asm/system.h for PowerPC Disintegrate asm/system.h for PA-RISC Disintegrate asm/system.h for MN10300 ...
| * Remove all #inclusions of asm/system.hDavid Howells2012-03-281-1/+0Star
| | | | | | | | | | | | | | | | | | Remove all #inclusions of asm/system.h preparatory to splitting and killing it. Performed with the following command: perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *` Signed-off-by: David Howells <dhowells@redhat.com>
* | cpufreq: OMAP: specify range for voltage scalingAfzal Mohammed2012-03-021-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | Specify voltage in ranges for regulator. Range used is tolerance specified for OPP. This helps to achieve DVFS with a wider range of regulators. Cc: Kevin Hilman <khilman@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com>
* | cpufreq: OMAP: scale voltage along with frequencyKevin Hilman2012-02-221-5/+63
|/ | | | | | | | | | | | | | | Use the regulator framework to get the voltage regulator associated with the MPU voltage domain and use it to scale voltage along with frequency. While here, CONFIG_CPU_FREQ_DEBUG doesn't exist anymore, so move debug prints to use dev_dbg(). Special thanks to Afzal Mohammed for suggestions on more robust error checking. Cc: Afzal Mohammed <afzal@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: fixup for omap_device changes, include <linux/module.h>Kevin Hilman2011-11-101-1/+3
| | | | | | | | Minor fixups to work starting with v3.2: - use the new omap_device API for getting a device by name. - need to include <linux/module.h> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: fix freq_table leakNishanth Menon2011-11-081-5/+17
| | | | | | | | | | | | | We use a single frequency table for multiple CPUs. But, with OMAP4, since we have multiple CPUs, the cpu_init call for CPU1 causes freq_table previously allocated for CPU0 to be overwritten. In addition, we dont free the table on exit path. We solve this by maintaining an atomic type counter to ensure just a single table exists at a given time. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: put clk if cpu_init failedNishanth Menon2011-11-081-3/+11
| | | | | | | | Release the mpu_clk in fail paths. Reported-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: only supports OPP libraryNishanth Menon2011-11-081-2/+1Star
| | | | | | | | | | | | | | | OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however, the cpufreq code does not currently use clk_init_cpufreq_table. As a result, it is unusuable for OMAP2 and only usable only on platforms using OPP library. Remove the unbalanced clk_exit_cpufreq_table(). Any platforms where OPPs are not availble will fail on init because a freq table will not be properly initialized. Signed-off-by: Nishanth Menon <nm@ti.com> [khilman@ti.com: changelog edits, and graceful failure mode changes] Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: dont support !freq_tableNishanth Menon2011-11-081-34/+33Star
| | | | | | | | | | OMAP2+ all have frequency tables, hence the hacks we had for older silicon do not need to be carried forward. As part of this change, use cpufreq_frequency_table_target to find the best match for frequency requested. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: deny initialization if no mpudevNishanth Menon2011-11-081-7/+8
| | | | | | | | if we do not have mpu_dev we normally fail in cpu_init. It is better to fail driver registration if the devices are not available. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: move clk name decision to initNishanth Menon2011-11-081-7/+13
| | | | | | | | | | Clk name does'nt need to dynamically detected during clk init. move them off to driver initialization, if we dont have a clk name, there is no point in registering the driver anyways. The actual clk get and put is left at cpu_init and exit functions. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: notify even with bad boot frequencyColin Cross2011-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, bootloaders starts up with a frequency which is not in the OPP table. At cpu_init, policy->cur contains the frequency we pick at boot. It is possible that system might have fixed it's boot frequency later on as part of power initialization. After this condition, the first call to omap_target results in the following: omap_getspeed(actual device frequency) != policy->cur(frequency that cpufreq thinks that the system is at), and it is possible that freqs.old == freqs.new (because the governor requested a scale down). We exit without triggering the notifiers in the current code, which does'nt let code which depends on cpufreq_notify_transition to have accurate information as to what the system frequency is. Instead, we do a normal transition if policy->cur is wrong, then, freqs.old will be the actual cpu frequency, freqs.new will be the actual new cpu frequency and all required notifiers have the accurate information. Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Colin Cross <ccross@google.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: Enable all CPUs in shared policy maskTodd Poynor2011-11-081-3/+1Star
| | | | | | | | | | | Enable all CPUs in the shared policy in the CPU init callback. Otherwise, the governor CPUFREQ_GOV_START event is invoked with a policy that only includes the first CPU, leaving other CPUs uninitialized by the governor. Signed-off-by: Todd Poynor <toddpoynor@google.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: Add SMP support for OMAP4+Russell King2011-11-081-10/+71
| | | | | | | | | | | | | | | | | | | | | | | On OMAP SMP configuartion, both processors share the voltage and clock. So both CPUs needs to be scaled together and hence needs software co-ordination. Also, update lpj with reference value to avoid progressive error. Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate them with with reference to the initial values to avoid a progressively bigger and bigger error in the value over time. While at this, re-use the notifiers for UP/SMP since on UP machine or UP_ON_SMP policy->cpus mask would contain only the boot CPU. Based on initial SMP support by Santosh Shilimkar. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [khilman@ti.com: due to overlap/rework, combined original Santosh patch and Russell's rework] Signed-off-by: Kevin Hilman <khilman@ti.com>
* cpufreq: OMAP: cleanup for multi-SoC support, move into drivers/cpufreqSantosh Shilimkar2011-11-081-0/+188
Move OMAP cpufreq driver from arch/arm/mach-omap2 into drivers/cpufreq, along with a few cleanups: - generalize support for better handling of different SoCs in the OMAP - use OPP layer instead of OMAP clock internals for frequency table init Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [khilman@ti.com: move to drivers] Signed-off-by: Kevin Hilman <khilman@ti.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-11-04 05:58:55 +0100