- 05 Sep, 2015 1 commit
-
-
Guenter Roeck authored
If ARM_MT8173_CPUFREQ is configured, and THERMAL is configured as module, the following build error is seen for arm:allmodconfig and arm64:allmodconfig. drivers/built-in.o: In function `mtk_cpufreq_ready': :(.text+0x32a20c): undefined reference to `of_cpufreq_cooling_register' drivers/built-in.o: In function `mtk_cpufreq_exit': :(.text+0x32a420): undefined reference to `cpufreq_cooling_unregister' The fix is similar to CPUFREQ_DT, but more restrictive since ARM_MT8173_CPUFREQ can not be built as module. Fixes: 1453863f ("cpufreq: mediatek: Add MT8173 cpufreq driver") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 03 Sep, 2015 4 commits
-
-
Viresh Kumar authored
Tolerance applies on both sides of the target voltage, i.e. both min and max sides. But while checking if a voltage is supported by the regulator or not, we haven't taken care of tolerance on the lower side. Fix that. Cc: Lucas Stach <l.stach@pengutronix.de> Fixes: 045ee45c ("cpufreq: cpufreq-dt: disable unsupported OPPs") Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Viresh Kumar authored
We need to explicitly mark OPPs as shared, when they are not defined with OPP-v2 bindings. This operation can potentially fail, and in that case we should at least print an error message. Fixes: 2e02d872 ("cpufreq: dt: Add support for operating-points-v2 bindings") Signed-off-by:
-
Viresh Kumar authored
We need to explicitly mark OPPs as shared, when they are not defined with OPP-v2 bindings. But this isn't required to be done if we failed to initialize OPP table. Reorder code to verify OPP count before marking them shared. Fixes: 2e02d872 ("cpufreq: dt: Add support for operating-points-v2 bindings") Signed-off-by:
-
Rafael J. Wysocki authored
-
- 01 Sep, 2015 12 commits
-
-
Abhilash Jindal authored
Wall time obtained from do_gettimeofday is susceptible to sudden jumps due to user setting the time or due to NTP. Monotonic time is constantly increasing time better suited for comparing two timestamps. Signed-off-by:
Abhilash Jindal <klock.android@gmail.com> Signed-off-by:
-
Shilpasri G Bhat authored
Modify the OCC reset/load/active event message to make it clearer for the user to understand the event and effect of the event. Suggested-by:
Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by:
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Acked-by:
-
Andrzej Hajda authored
The patch was generated using fixed coccinelle semantic patch scripts/coccinelle/api/memdup.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Acked-by:
-
Viresh Kumar authored
Driver is guaranteed to be present on a call to cpufreq_parse_governor() and there is no need to check for !cpufreq_driver. Drop it. Signed-off-by:
-
Viresh Kumar authored
Its all about caching min/max freq requested by userspace, and the name 'cpufreq_real_policy' doesn't fit that well. Rename it to cpufreq_user_policy. Signed-off-by:
-
Viresh Kumar authored
Its always same as policy->policy, and there is no need to keep another copy of it. Remove it. Signed-off-by:
-
Viresh Kumar authored
Its always same as policy->governor, and there is no need to keep another copy of it. Remove it. Signed-off-by:
-
Viresh Kumar authored
'user_policy' caches properties of a policy that are set by userspace. And these must be updated only if cpufreq core was successful in updating them based on request from user space. In store_scaling_governor(), we are updating user_policy.policy and user_policy.governor even if cpufreq_set_policy() failed. That's incorrect. Fix this by updating user_policy.* only if we were successful in updating the properties. Signed-off-by:
-
Viresh Kumar authored
cpufreq_get_policy() is useful if the pointer to policy isn't available in advance. But if it is available, then there is no need to call cpufreq_get_policy(). Directly use memcpy() to copy the policy. Signed-off-by:
-
Viresh Kumar authored
What's being done from CPUFREQ_INCOMPATIBLE, can also be done with CPUFREQ_ADJUST. There is nothing special with CPUFREQ_INCOMPATIBLE notifier. Kill CPUFREQ_INCOMPATIBLE and fix its usage sites. This also updates the numbering of notifier events to remove holes. Signed-off-by:
-
Pi-Cheng Chen authored
Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation: 100mV < Vsram - Vproc < 200mV which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC. Signed-off-by:
Pi-Cheng Chen <pi-cheng.chen@linaro.org> Acked-by:
-
Pi-Cheng Chen authored
This patch adds the clock and regulator consumer properties part of document for CPU DVFS clocks on Mediatek MT8173 SoC. Signed-off-by:
Michael Turquette <mturquette@baylibre.com> Acked-by:
-
- 28 Aug, 2015 3 commits
-
-
Viresh Kumar authored
IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Viresh Kumar authored
Dan Carpenter reported (generated with static checker): drivers/base/power/opp.c:949 _opp_add_static_v2() warn: passing casted pointer '&new_opp->clock_latency_ns' to 'of_property_read_u32()' 64 vs 32. This code will break on 64 bit, big endian machines. Fix this by reading the value in a u32 type variable first and then assigning it to the unsigned long variable. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Suggested-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Viresh Kumar authored
_of_init_opp_table_v2() isn't freeing up resources on some errors and the error values returned are also not correct always. This fixes following problems: - Return -ENOENT, if no entries are found in the table. - Use IS_ERR() to properly check return value of _find_device_opp(). - Return error value with PTR_ERR() in above case. - Free table if _find_device_opp() fails. Reported-by:
-
- 08 Aug, 2015 1 commit
-
-
Bartlomiej Zolnierkiewicz authored
Make scaling_boost_freqs sysfs attribute is available when cpufreq-dt driver is used and boost support is enabled. Suggested-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
- 07 Aug, 2015 19 commits
-
-
Ethan Zhao authored
Append more Oracle X86 servers that have their own power management, SUN FIRE X4275 M3 SUN FIRE X4170 M3 and SUN FIRE X6-2 Signed-off-by:
Ethan Zhao <ethan.zhao@oracle.com> Acked-by:
Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by:
-
Kristen Carlson Accardi authored
Whitelist the SKL-S processor Signed-off-by:
-
Viresh Kumar authored
With opp-v2 DT bindings, few OPPs can be used only for the boost mode. But using such OPPs require the boost mode to be supported by cpufreq driver. We will parse DT bindings only during ->init() and so can enable boost support only after registering cpufreq driver. This enables boost support as soon as any policy has boost/turbo OPPs for its CPUs. We don't need to disable boost support as that is done by the core, when the driver is unregistered. Signed-off-by:
-
Viresh Kumar authored
Support for parsing operating-points-v2 bindings is in place now, lets modify cpufreq-dt driver to use them. For backward compatibility we will continue to support earlier bindings. Special handling for that is required, to make sure OPPs are initialized for all the CPUs. Reviewed-by:
-
Viresh Kumar authored
In some cases it wouldn't be known at time of driver registration, if the driver needs to support boost frequencies. For example, while getting boost information from DT with opp-v2 bindings, we need to parse the bindings for all the CPUs to know if turbo/boost OPPs are supported or not. One way out to do that efficiently is to delay supporting boost mode (i.e. creating /sys/devices/system/cpu/cpufreq/boost file), until the time OPP bindings are parsed. At that point, the driver can enable boost support. This can be done at ->init(), where the frequency table is created. To do that, the driver requires few APIs from cpufreq core that let him do this. This patch provides these APIs. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
cpufreq table entries for OPPs with turbo modes enabled, should be marked with CPUFREQ_BOOST_FREQ flag. This ensures that these states are only used while operating in boost or turbo mode. Signed-off-by:
-
Rafael J. Wysocki authored
-
Bartlomiej Zolnierkiewicz authored
Add dev_pm_opp_is_turbo() helper to verify if an opp is to be used only for turbo mode or not. Reviewed-by:
-
Viresh Kumar authored
With "operating-points-v2" its possible to tell which devices share OPPs. We already have infrastructure to decode that information. This patch adds following APIs: - of_get_cpus_sharing_opps: Returns cpumask of CPUs sharing OPPs (only valid with v2 bindings). - of_cpumask_init_opp_table: Initializes OPPs for all CPUs present in cpumask. - of_cpumask_free_opp_table: Frees OPPs for all CPUs present in cpumask. - set_cpus_sharing_opps: Sets which CPUs share OPPs (only valid with old OPP bindings, as this information isn't present in DT). Reviewed-by:
-
Viresh Kumar authored
With "operating-points-v2" bindings, it's possible to specify the OPP to which the device must be switched, before suspending. This patch adds support for getting that information. Reviewed-by:
-
Viresh Kumar authored
An opp can be shared by multiple devices, for example its very common for CPUs to share the OPPs, i.e. when they share clock/voltage rails. This patch adds support of shared OPPs to the OPP library. Instead of a single device, dev_opp will now contain a list of devices that use it. It also senses if the device (we are trying to initialize OPPs for) shares OPPs with a device added earlier and in that case we update the list of devices managed by OPPs instead of duplicating OPPs again. The same infrastructure will be used for the old OPP bindings, with later patches. Reviewed-by:
-
Viresh Kumar authored
With "operating-points-v2" bindings, clock-latency is defined per OPP. Users of this value expect a single value which defines the latency to switch to any clock rate. Find maximum clock-latency-ns from the OPP table to service requests from such users. Reviewed-by:
-
Viresh Kumar authored
This adds support in OPP library to parse and create list of OPPs from operating-points-v2 bindings. It takes care of most of the properties of new bindings (except shared-opp, which will be handled separately). For backward compatibility, we keep supporting earlier bindings. We try to search for the new bindings first, in case they aren't present we look for the old deprecated ones. There are few things marked as TODO: - Support for multiple OPP tables - Support for multiple regulators They should be fixed separately. Reviewed-by:
-
Viresh Kumar authored
Later commits would add support for new OPP bindings and this would be required then. So, lets do it in a separate patch to make it easily reviewable. Another change worth noticing is INIT_LIST_HEAD(&opp->node). We weren't doing it earlier as we never tried to delete a list node before it is added to list. But this wouldn't be the case anymore. We might try to delete a node (just to reuse the same code paths), without it being getting added to the list. Reviewed-by:
-
Viresh Kumar authored
There is no need to complicate _opp_add_dynamic() with allocation of dev_opp as well. Allocate it from _add_device_opp() instead. Reviewed-by:
-
Viresh Kumar authored
This will be used from multiple places later. Lets create a separate routine for that. Reviewed-by:
-
Viresh Kumar authored
In order to prepare for the later commits, this relocates few routines towards the top as they will be used earlier in the code. Reviewed-by:
-
Viresh Kumar authored
More platform specific extended opp bindings will follow and it would be easy to manage them with a directory for opp. Lets create that and move the existing opp bindings into it. Signed-off-by:
-
Viresh Kumar authored
With a 32 bit value, the maximum frequency that the bindings can support is ~ 4 GHz. And that might fall short of what newer systems may have. Allow opp-hz to be a 64 bit big-endian value. Suggested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
