- Apr 08, 2016
-
-
Rafael J. Wysocki authored
Merge two switch entries that do the same thing in cpufreq_cpu_callback(). No functional changes. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org>
-
Joe Perches authored
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:
-
Joe Perches authored
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 authored
Prefix the output using the more common kernel style. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by:
-
Geliang Tang authored
Use list_for_each_entry*() instead of list_for_each*() to simplify the code. Signed-off-by:
Geliang Tang <geliangtang@163.com> Acked-by:
-
Rafael J. Wysocki authored
There are multiple places in intel_pstate where int_tofp() is applied to both arguments of div_fp(), but this is pointless, because int_tofp() simply shifts its argument to the left by FRAC_BITS which mathematically is equivalent to multuplication by 2^FRAC_BITS, so if this is done to both arguments of a division, the extra factors will cancel each other during that operation anyway. Drop the pointless int_tofp() applied to div_fp() arguments throughout the driver. Signed-off-by: -
Viresh Kumar authored
The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform device now, reuse that and remove similar code from platform code. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Viresh Kumar authored
Multiple platforms are using the generic cpufreq-dt driver now, and all of them are required to create a platform device with name "cpufreq-dt", in order to get the cpufreq-dt probed. Many of them do it from platform code, others have special drivers just to do that. It would be more sensible to do this at a generic place, where all such platform can mark their entries. This patch adds a separate file to get this device created. Currently the compat list of platforms that we support is empty, and will be filled in as and when we move platforms to use it. It always compiles as part of the kernel and so doesn't need a module-exit operation. Signed-off-by:
-
Viresh Kumar authored
All CPUs on Tegra platform share clock/voltage lines and there is absolutely no need of setting platform data for 'cpufreq-dt' platform device, as that's the default case. Stop setting platform data for cpufreq-dt device. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Paul Gortmaker authored
The Kconfig for this driver is currently: config CPU_FREQ_CBE_PMI bool "CBE frequency scaling using PMI interface" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular and unused code here, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Signed-off-by:Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
-
Rafael J. Wysocki authored
Due to differences in the cpufreq core's handling of runtime CPU offline and nonboot CPUs disabling during system suspend-to-RAM, fast frequency switching gets disabled after a suspend-to-RAM and resume cycle on all of the nonboot CPUs. To prevent that from happening, move the invocation of cpufreq_disable_fast_switch() from cpufreq_exit_governor() to sugov_exit(), as the schedutil governor is the only user of fast frequency switching today anyway. That simply prevents cpufreq_disable_fast_switch() from being called without invoking the ->governor callback for the CPUFREQ_GOV_POLICY_EXIT event (which happens during system suspend now). Fixes: b7898fda (cpufreq: Support for fast frequency switching) Signed-off-by:
-
- Apr 05, 2016
-
-
Viresh Kumar authored
The comment in file header doesn't hold true anymore, drop it. Signed-off-by:
-
Srinivas Pandruvada authored
No code change. Only added kernel doc style comments for structures. Signed-off-by:
-
Srinivas Pandruvada authored
When user sets performance policy using cpufreq interface, it is possible that because of policy->max limits, the actual performance is still limited. But the current implementation will silently switch the policy to powersave and start using powersave limits. If user modifies any limits using intel_pstate sysfs, this is actually changing powersave limits. The current implementation tracks limits under powersave and performance policy using two different variables. When policy->max is less than policy->cpuinfo.max_freq, only powersave limit variable is used. This fix causes the performance limits variable to be used always when the policy is performance. Signed-off-by:
-
- Apr 01, 2016
-
-
Rafael J. Wysocki authored
Add a new cpufreq scaling governor, called "schedutil", that uses scheduler-provided CPU utilization information as input for making its decisions. Doing that is possible after commit 34e2c555 (cpufreq: Add mechanism for registering utilization update callbacks) that introduced cpufreq_update_util() called by the scheduler on utilization changes (from CFS) and RT/DL task status updates. In particular, CPU frequency scaling decisions may be based on the the utilization data passed to cpufreq_update_util() by CFS. The new governor is relatively simple. The frequency selection formula used by it depends on whether or not the utilization is frequency-invariant. In the frequency-invariant case the new CPU frequency is given by next_freq = 1.25 * max_freq * util / max where util and max are the last two arguments of cpufreq_update_util(). In turn, if util is not frequency-invariant, the maximum frequency in the above formula is replaced with the current frequency of the CPU: next_freq = 1.25 * curr_freq * util / max The coefficient 1.25 corresponds to the frequency tipping point at (util / max) = 0.8. All of the computations are carried out in the utilization update handlers provided by the new governor. One of those handlers is used for cpufreq policies shared between multiple CPUs and the other one is for policies with one CPU only (and therefore it doesn't need to use any extra synchronization means). The governor supports fast frequency switching if that is supported by the cpufreq driver in use and possible for the given policy. In the fast switching case, all operations of the governor take place in its utilization update handlers. If fast switching cannot be used, the frequency switch operations are carried out with the help of a work item which only calls __cpufreq_driver_target() (under a mutex) to trigger a frequency update (to a value already computed beforehand in one of the utilization update handlers). Currently, the governor treats all of the RT and DL tasks as "unknown utilization" and sets the frequency to the allowed maximum when updated from the RT or DL sched classes. That heavy-handed approach should be replaced with something more subtle and specifically targeted at RT and DL tasks. The governor shares some tunables management code with the "ondemand" and "conservative" governors and uses some common definitions from cpufreq_governor.h, but apart from that it is stand-alone. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org>
-
Rafael J. Wysocki authored
Modify the ACPI cpufreq driver to provide a method for switching CPU frequencies from interrupt context and update the cpufreq core to support that method if available. Introduce a new cpufreq driver callback, ->fast_switch, to be invoked for frequency switching from interrupt context by (future) governors supporting that feature via (new) helper function cpufreq_driver_fast_switch(). Add two new policy flags, fast_switch_possible, to be set by the cpufreq driver if fast frequency switching can be used for the given policy and fast_switch_enabled, to be set by the governor if it is going to use fast frequency switching for the given policy. Also add a helper for setting the latter. Since fast frequency switching is inherently incompatible with cpufreq transition notifiers, make it possible to set the fast_switch_enabled only if there are no transition notifiers already registered and make the registration of new transition notifiers fail if fast_switch_enabled is set for at least one policy. Implement the ->fast_switch callback in the ACPI cpufreq driver and make it set fast_switch_possible during policy initialization as appropriate. Signed-off-by:
-
Rafael J. Wysocki authored
Move definitions of symbols related to transition latency and sampling rate to include/linux/cpufreq.h so they can be used by (future) goverernors located outside of drivers/cpufreq/. No functional changes. Signed-off-by:
-
Rafael J. Wysocki authored
Move definitions and function headers related to struct gov_attr_set to include/linux/cpufreq.h so they can be used by (future) goverernors located outside of drivers/cpufreq/. No functional changes. Signed-off-by:
-
Rafael J. Wysocki authored
Move abstract code related to struct gov_attr_set to a separate (new) file so it can be shared with (future) goverernors that won't share more code with "ondemand" and "conservative". No intentional functional changes. Signed-off-by:
-
Rafael J. Wysocki authored
In addition to fields representing governor tunables, struct dbs_data contains some fields needed for the management of objects of that type. As it turns out, that part of struct dbs_data may be shared with (future) governors that won't use the common code used by "ondemand" and "conservative", so move it to a separate struct type and modify the code using struct dbs_data to follow. Signed-off-by:
-
Rafael J. Wysocki authored
Replace the single helper for adding and removing cpufreq utilization update hooks, cpufreq_set_update_util_data(), with a pair of helpers, cpufreq_add_update_util_hook() and cpufreq_remove_update_util_hook(), and modify the users of cpufreq_set_update_util_data() accordingly. With the new helpers, the code using them doesn't need to worry about the internals of struct update_util_data and in particular it doesn't need to worry about populating the func field in it properly upfront. Signed-off-by:
-
Rafael J. Wysocki authored
The initialization of intel_pstate for a given CPU involves populating the fields of its struct cpudata that represent the previous sample, but currently that is done in a problematic way. Namely, intel_pstate_init_cpu() makes an extra call to intel_pstate_sample() so it reads the current register values that will be used to populate the "previous sample" record during the next invocation of intel_pstate_sample(). However, after commit a4675fbc (cpufreq: intel_pstate: Replace timers with utilization update callbacks) that doesn't work for last_sample_time, because the time value is passed to intel_pstate_sample() as an argument now. Passing 0 to it from intel_pstate_init_cpu() is problematic, because that causes cpu->last_sample_time == 0 to be visible in get_target_pstate_use_performance() (and hence the extra cpu->last_sample_time > 0 check in there) and effectively allows the first invocation of intel_pstate_sample() from intel_pstate_update_util() to happen immediately after the initialization which may lead to a significant "turn on" effect in the governor algorithm. To mitigate that issue, rework the initialization to avoid the extra intel_pstate_sample() call from intel_pstate_init_cpu(). Instead, make intel_pstate_sample() return false if it has been called with cpu->sample.time equal to zero, which will make intel_pstate_update_util() skip the sample in that case, and reset cpu->sample.time from intel_pstate_set_update_util_hook() to make the algorithm start properly every time the hook is set. Signed-off-by:
-
- Mar 31, 2016
-
-
Rafael J. Wysocki authored
The utilization update hook in the intel_pstate driver is set too early, as it only should be set after the policy has been fully initialized by the core. That may cause intel_pstate_update_util() to use incorrect data and put the CPUs into incorrect P-states as a result. To prevent that from happening, make intel_pstate_set_policy() set the utilization update hook instead of intel_pstate_init_cpu() so intel_pstate_update_util() only runs when all things have been initialized as appropriate. Signed-off-by:
-
- Mar 26, 2016
-
-
Allen Hubbe authored
Kernel zero day testing warned about address space confusion. A virtual iomem address was used where a physical address is expected. The offending functions implement an optional part of the api, so they are removed. They can be added later, after testing. Fixes: a1b36958 Signed-off-by:
Allen Hubbe <Allen.Hubbe@emc.com> Acked-by:
Xiangliang Yu <Xiangliang.Yu@amd.com> Signed-off-by:
Jon Mason <jdmason@kudzu.us>
-
- Mar 25, 2016
-
-
Arnd Bergmann authored
The r592 driver relies on behavior of the DMA mapping API that is normally observed but not guaranteed by the API. Instead it uses a runtime check to fail transfers if the API ever behaves When CONFIG_NEED_SG_DMA_LENGTH is not set, one of the checks turns into a comparison of a variable with itself, which gcc-6.0 now warns about: drivers/memstick/host/r592.c: In function 'r592_transfer_fifo_dma': drivers/memstick/host/r592.c:302:31: error: self-comparison always evaluates to false [-Werror=tautological-compare] (sg_dma_len(&dev->req->sg) < dev->req->sg.length)) { ^ The check itself is not a problem, so this patch just rephrases the condition in a way that gcc does not consider an indication of a mistake. We already know that dev->req->sg.length was initially R592_LFIFO_SIZE, so we can compare it to that constant again. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Quentin Lambert <lambert.quentin@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
INPUT_COMPAT_TEST became much simpler after commit f4056b52 ("input: redefine INPUT_COMPAT_TEST as in_compat_syscall()") so we can cleanly eliminate it altogether. Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by:
-
Rafael J. Wysocki authored
The permissions of this file were modified by commit (f447671b PM / AVS: rockchip-io: add io selectors and supplies for rk3399) by mistake, so fix them. Signed-off-by:
-
Geliang Tang authored
Use KMEM_CACHE() instead of kmem_cache_create() to simplify the code. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com>
-
Ilya Dryomov authored
Turn r_ops into a flexible array member to enable large, consisting of up to 16 ops, OSD requests. The use case is scattered writeback in cephfs and, as far as the kernel client is concerned, 16 is just a made up number. r_ops had size 3 for copyup+hint+write, but copyup is really a special case - it can only happen once. ceph_osd_request_cache is therefore stuffed with num_ops=2 requests, anything bigger than that is allocated with kmalloc(). req_mempool is backed by ceph_osd_request_cache, which means either num_ops=1 or num_ops=2 for use_mempool=true - all existing users (ceph_writepages_start(), ceph_osdc_writepages()) are fine with that. Signed-off-by: -
Yan, Zheng authored
This avoids defining large array of r_reply_op_{len,result} in in struct ceph_osd_request. Signed-off-by:Yan, Zheng <zyan@redhat.com> Signed-off-by:
-
Linus Torvalds authored
This reverts commit e7223f18. It causes problems when a ppdev tries to register before the parport driver has been registered with the device model. That will trigger the BUG_ON(!drv->bus->p); at drivers/base/driver.c:153. The call chain is kernel_init -> kernel_init_freeable -> do_one_initcall -> ppdev_init -> __parport_register_driver -> driver_register *BOOM* Reported-by:
kernel test robot <fengguang.wu@intel.com> Reported-by:
Ross Zwisler <zwisler@gmail.com> Reported-by:
Petr Mladek <pmladek@suse.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mylène Josserand authored
Handle the Oscillator Failure ('OF') bit from Oscillator Status register (0x1D). This bit is cleared on set_time function and is read each time the date/time is read, but only in case of XT Oscillator selection. In RC mode, this bit is always set. Signed-off-by:Mylène Josserand <mylene.josserand@free-electrons.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Mylène Josserand authored
The autocalibration is separated in two bits to set in Oscillator Control register (0x1c) : - OSEL bit to select the oscillator type (XT or RC). - ACAL bit to select the autocalibration type. These functionnalities are exported in sysfs entries : "oscillator" and "autocalibration". Respectively, the values are "xtal" for XT oscillator and "rc" for RC oscillator and 0 to disable the autocalibration cycle, 512 for a 512 seconds autocalibration cycle and 1024 for a cycle of 1024 seconds. Examples : Set to XT Oscillator echo xtal > /sys/class/rtc/rtc0/device/oscillator Activate an autocalibration every 512 seconds echo 512 > /sys/class/rtc/rtc0/device/autocalibration Signed-off-by:
-
Alexandre Belloni authored
The rv8803 has a 60µs window where it will not answer on the i2c bus. It also means there will be no ack for the communication. Make sure communication is tried multiple times when this happens (the i2c subsystem mandates -ENXIO is that case but the number of retries is host specific). The critical parts are the probe function and the alarm callback so make sure we handle the failure there. Cc: stable@vger.kernel.org # v4.4 Signed-off-by:
-
- Mar 24, 2016
-
-
Haiyang Zhang authored
Reorder the code in netvsc_sc_open(), so num_sc_offered is only decremented after vmbus_open() is called. This avoid pontential race of removing device before all channels are setup. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Oliver Neukum authored
During the initialisation the driver uses a buffer on the stack for DMA. That violates the cache coherency rules. The fix is to allocate the buffer with kmalloc(). Signed-off-by:
Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Vladis Dronov authored
The ati_remote2 driver expects at least two interfaces with one endpoint each. If given malicious descriptor that specify one interface or no endpoints, it will crash in the probe function. Ensure there is at least two interfaces and one endpoint for each interface before using it. The full disclosure: http://seclists.org/bugtraq/2016/Mar/90 Reported-by:
Ralf Spenneberg <ralf@spenneberg.net> Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- Mar 23, 2016
-
-
David Wu authored
This adds the necessary data for handling io voltage domains on the rk3399. As interesting tidbit, the rk3399 contains two separate iodomain areas. One in the regular General Register Files (GRF) and one in PMUGRF in the pmu power domain. Signed-off-by:
David Wu <david.wu@rock-chips.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Dasaratharaman Chandramouli authored
Enables "Intel(R) Xeon Phi(TM) Processor x200 Product Family" support, formerly code-named KNL. It is based on modified Intel Atom Silvermont microarchitecture. Signed-off-by:
Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com> [micah.barany@intel.com: adjusted values of residency and latency] Signed-off-by:
Micah Barany <micah.barany@intel.com> [hubert.chrzaniuk@intel.com: removed deprecated CPUIDLE_FLAG_TIME_VALID flag] Signed-off-by:
Hubert Chrzaniuk <hubert.chrzaniuk@intel.com> Signed-off-by:
Pawel Karczewski <pawel.karczewski@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
Len Brown authored
Some SKL-H configurations require "intel_idle.max_cstate=7" to boot. While that is an effective workaround, it disables C10. This patch detects the problematic configuration, and disables C8 and C9, keeping C10 enabled. Note that enabling SGX in BIOS SETUP can also prevent this issue, if the system BIOS provides that option. https://bugzilla.kernel.org/show_bug.cgi?id=109081 "Freezes with Intel i7 6700HQ (Skylake), unless intel_idle.max_cstate=7" Signed-off-by:
-
