summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
2020-05-21Merge remote-tracking branch 'remotes/fslc/4.9-2.3.x-imx' into ↵Marcel Ziswiler
toradex_4.9-2.3.x-imx-next Conflicts: sound/soc/codecs/sgtl5000.c sound/soc/fsl/imx-sgtl5000.c
2020-05-19Merge tag 'v4.9.220' into 4.9-2.3.x-imxMarcel Ziswiler
This is the 4.9.220 stable release Conflicts: arch/arm/Kconfig.debug arch/arm/boot/dts/imx7s.dtsi arch/arm/mach-imx/common.h arch/arm/mach-imx/cpuidle-imx6q.c arch/arm/mach-imx/cpuidle-imx6sx.c arch/arm/mach-imx/suspend-imx6.S block/blk-core.c drivers/crypto/caam/caamalg.c drivers/crypto/mxs-dcp.c drivers/dma/imx-sdma.c drivers/gpu/drm/bridge/adv7511/adv7511_drv.c drivers/input/keyboard/imx_keypad.c drivers/input/keyboard/snvs_pwrkey.c drivers/mmc/host/sdhci.c drivers/net/can/flexcan.c drivers/net/ethernet/freescale/fec_main.c drivers/net/phy/phy_device.c drivers/net/wireless/ath/ath10k/pci.c drivers/tty/serial/imx.c drivers/usb/dwc3/gadget.c drivers/usb/host/xhci.c include/linux/blkdev.h include/linux/cpu.h include/linux/platform_data/dma-imx-sdma.h kernel/cpu.c net/wireless/util.c sound/soc/fsl/Kconfig sound/soc/fsl/fsl_esai.c sound/soc/fsl/fsl_sai.c sound/soc/fsl/imx-sgtl5000.c
2020-04-24cpufreq: powernv: Fix use-after-freeOliver O'Halloran
commit d0a72efac89d1c35ac55197895201b7b94c5e6ef upstream. The cpufreq driver has a use-after-free that we can hit if: a) There's an OCC message pending when the notifier is registered, and b) The cpufreq driver fails to register with the core. When a) occurs the notifier schedules a workqueue item to handle the message. The backing work_struct is located on chips[].throttle and when b) happens we clean up by freeing the array. Once we get to the (now free) queued item and the kernel crashes. Fixes: c5e29ea7ac14 ("cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200206062622.28235-1-oohall@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-04cpufreq: Register drivers only after CPU devices have been registeredViresh Kumar
[ Upstream commit 46770be0cf94149ca48be87719bda1d951066644 ] The cpufreq core heavily depends on the availability of the struct device for CPUs and if they aren't available at the time cpufreq driver is registered, we will never succeed in making cpufreq work. This happens due to following sequence of events: - cpufreq_register_driver() - subsys_interface_register() - return 0; //successful registration of driver ... at a later point of time - register_cpu(); - device_register(); - bus_probe_device(); - sif->add_dev(); - cpufreq_add_dev(); - get_cpu_device(); //FAILS - per_cpu(cpu_sys_devices, num) = &cpu->dev; //used by get_cpu_device() - return 0; //CPU registered successfully Because the per-cpu variable cpu_sys_devices is set only after the CPU device is regsitered, cpufreq will never be able to get it when cpufreq_add_dev() is called. This patch avoids this failure by making sure device structure of at least CPU0 is available when the cpufreq driver is registered, else return -EPROBE_DEFER. Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org> Co-developed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-28cpufreq: Add NULL checks to show() and store() methods of cpufreqKai Shen
commit e6e8df07268c1f75dd9215536e2ce4587b70f977 upstream. Add NULL checks to show() and store() in cpufreq.c to avoid attempts to invoke a NULL callback. Though some interfaces of cpufreq are set as read-only, users can still get write permission using chmod which can lead to a kernel crash, as follows: chmod +w /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq This bug was found in linux 4.19. Signed-off-by: Kai Shen <shenkai8@huawei.com> Reported-by: Feilong Lin <linfeilong@huawei.com> Reviewed-by: Feilong Lin <linfeilong@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject & changelog ] Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-28cpufreq: Skip cpufreq resume if it's not suspendedBo Yan
commit 703cbaa601ff3fb554d1246c336ba727cc083ea0 upstream. cpufreq_resume can be called even without preceding cpufreq_suspend. This can happen in following scenario: suspend_devices_and_enter --> dpm_suspend_start --> dpm_prepare --> device_prepare : this function errors out --> dpm_suspend: this is skipped due to dpm_prepare failure this means cpufreq_suspend is skipped over --> goto Recover_platform, due to previous error --> goto Resume_devices --> dpm_resume_end --> dpm_resume --> cpufreq_resume In case schedutil is used as frequency governor, cpufreq_resume will eventually call sugov_start, which does following: memset(sg_cpu, 0, sizeof(*sg_cpu)); .... This effectively erases function pointer for frequency update, causing crash later on. The function pointer would have been set correctly if subsequent cpufreq_add_update_util_hook runs successfully, but that function returns earlier because cpufreq_suspend was not called: if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu))) return; The fix is to check cpufreq_suspended first, if it's false, that means cpufreq_suspend was not called in the first place, so do not resume cpufreq. Signed-off-by: Bo Yan <byan@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Dropped printing a message ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-29cpufreq: Avoid cpufreq_suspend() deadlock on system shutdownRafael J. Wysocki
commit 65650b35133ff20f0c9ef0abd5c3c66dbce3ae57 upstream. It is incorrect to set the cpufreq syscore shutdown callback pointer to cpufreq_suspend(), because that function cannot be run in the syscore stage of system shutdown for two reasons: (a) it may attempt to carry out actions depending on devices that have already been shut down at that point and (b) the RCU synchronization carried out by it may not be able to make progress then. The latter issue has been present since commit 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"), but the former one has been there since commit 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown") regardless. Fix that by dropping cpufreq_syscore_ops altogether and making device_shutdown() call cpufreq_suspend() directly before shutting down devices, which is along the lines of what system-wide power management does. Fixes: 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds") Fixes: 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.0+ <stable@vger.kernel.org> # 4.0+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-25cpufreq/pasemi: fix use-after-free in pas_cpufreq_cpu_init()Wen Yang
[ Upstream commit e0a12445d1cb186d875410d093a00d215bec6a89 ] The cpu variable is still being used in the of_get_property() call after the of_node_put() call, which may result in use-after-free. Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak") Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31cpufreq: pmac32: fix possible object reference leakWen Yang
[ Upstream commit 8d10dc28a9ea6e8c02e825dab28699f3c72b02d9 ] The call to of_find_node_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 552, but without a corresponding object release within this function. ./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 552, but without a corresponding object release within this function. ./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 587, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linux-pm@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31cpufreq/pasemi: fix possible object reference leakWen Yang
[ Upstream commit a9acc26b75f652f697e02a9febe2ab0da648a571 ] The call to of_get_cpu_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pasemi-cpufreq.c:212:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. ./drivers/cpufreq/pasemi-cpufreq.c:220:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31cpufreq: ppc_cbe: fix possible object reference leakWen Yang
[ Upstream commit 233298032803f2802fe99892d0de4ab653bfece4 ] The call to of_get_cpu_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/ppc_cbe_cpufreq.c:89:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 76, but without a corresponding object release within this function. ./drivers/cpufreq/ppc_cbe_cpufreq.c:89:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 76, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31sched/cpufreq: Fix kobject memleakViresh Kumar
[ Upstream commit 9a4f26cc98d81b67ecc23b890c28e2df324e29f3 ] Currently the error return path from kobject_init_and_add() is not followed by a call to kobject_put() - which means we are leaking the kobject. Fix it by adding a call to kobject_put() in the error path of kobject_init_and_add(). Signed-off-by: Tobin C. Harding <tobin@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tobin C. Harding <tobin@kernel.org> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Link: http://lkml.kernel.org/r/20190430001144.24890-1-tobin@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-14x86/cpu: Sanitize FAM6_ATOM namingPeter Zijlstra
commit f2c4db1bd80720cd8cb2a5aa220d9bc9f374f04e upstream. Going primarily by: https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors with additional information gleaned from other related pages; notably: - Bonnell shrink was called Saltwell - Moorefield is the Merriefield refresh which makes it Airmont The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE for i in `git grep -l FAM6_ATOM` ; do sed -i -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g' \ -e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/' \ -e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g' \ -e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g' \ -e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g' \ -e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g' \ -e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g' \ -e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g' \ -e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g' \ -e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g' \ -e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i} done Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: dave.hansen@linux.intel.com Cc: len.brown@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [bwh: Backported to 4.9: - Drop changes to CPU IDs that weren't already included - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-28Merge remote-tracking branch 'remotes/fslc/4.9-2.3.x-imx' into ↵Colibri-iMX7_LXDE-Image_2.8b6.184-20190401Colibri-iMX6_LXDE-Image_2.8b6.184-20190401Colibri-iMX6ULL_LXDE-Image_2.8b6.184-20190401Apalis-iMX6_LXDE-Image_2.8b6.184-20190401Marcel Ziswiler
toradex_4.9-2.3.x-imx-next
2019-03-28Merge tag 'v4.9.166' into 4.9-2.3.x-imxMarcel Ziswiler
This is the 4.9.166 stable release
2019-03-23cpufreq: pxa2xx: remove incorrect __init annotationArnd Bergmann
commit 9505b98ccddc454008ca7efff90044e3e857c827 upstream. pxa_cpufreq_init_voltages() is marked __init but usually inlined into the non-__init pxa_cpufreq_init() function. When building with clang, it can stay as a standalone function in a discarded section, and produce this warning: WARNING: vmlinux.o(.text+0x616a00): Section mismatch in reference from the function pxa_cpufreq_init() to the function .init.text:pxa_cpufreq_init_voltages() The function pxa_cpufreq_init() references the function __init pxa_cpufreq_init_voltages(). This is often because pxa_cpufreq_init lacks a __init annotation or the annotation of pxa_cpufreq_init_voltages is wrong. Fixes: 50e77fcd790e ("ARM: pxa: remove __init from cpufreq_driver->init()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-23cpufreq: tegra124: add missing of_node_put()Yangtao Li
commit 446fae2bb5395f3028d8e3aae1508737e5a72ea1 upstream. of_cpu_device_node_get() will increase the refcount of device_node, it is necessary to call of_node_put() at the end to release the refcount. Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124") Cc: <stable@vger.kernel.org> # 4.4+ Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-13cpufreq: Use struct kobj_attribute instead of struct global_attrViresh Kumar
commit 625c85a62cb7d3c79f6e16de3cfa972033658250 upstream. The cpufreq_global_kobject is created using kobject_create_and_add() helper, which assigns the kobj_type as dynamic_kobj_ktype and show/store routines are set to kobj_attr_show() and kobj_attr_store(). These routines pass struct kobj_attribute as an argument to the show/store callbacks. But all the cpufreq files created using the cpufreq_global_kobject expect the argument to be of type struct attribute. Things work fine currently as no one accesses the "attr" argument. We may not see issues even if the argument is used, as struct kobj_attribute has struct attribute as its first element and so they will both get same address. But this is logically incorrect and we should rather use struct kobj_attribute instead of struct global_attr in the cpufreq core and drivers and the show/store callbacks should take struct kobj_attribute as argument instead. This bug is caught using CFI CLANG builds in android kernel which catches mismatch in function prototypes for such callbacks. Reported-by: Donghee Han <dh.han@samsung.com> Reported-by: Sangkyu Kim <skwith.kim@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-20cpufreq: check if policy is inactive early in __cpufreq_get()Sudeep Holla
[ Upstream commit 2f66196208c98b3d1b4294edffb2c5a8197be899 ] cpuinfo_cur_freq gets current CPU frequency as detected by hardware while scaling_cur_freq last known CPU frequency. Some platforms may not allow checking the CPU frequency of an offline CPU or the associated resources may have been released via cpufreq_exit when the CPU gets offlined, in which case the policy would have been invalidated already. If we attempt to get current frequency from the hardware, it may result in hang or crash. For example on Juno, I see: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000188 [0000000000000188] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 5 PID: 4202 Comm: cat Not tainted 4.20.0-08251-ga0f2c0318a15-dirty #87 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform pstate: 40000005 (nZcv daif -PAN -UAO) pc : scmi_cpufreq_get_rate+0x34/0xb0 lr : scmi_cpufreq_get_rate+0x34/0xb0 Call trace: scmi_cpufreq_get_rate+0x34/0xb0 __cpufreq_get+0x34/0xc0 show_cpuinfo_cur_freq+0x24/0x78 show+0x40/0x60 sysfs_kf_seq_show+0xc0/0x148 kernfs_seq_show+0x44/0x50 seq_read+0xd4/0x480 kernfs_fop_read+0x15c/0x208 __vfs_read+0x60/0x188 vfs_read+0x94/0x150 ksys_read+0x6c/0xd8 __arm64_sys_read+0x24/0x30 el0_svc_common+0x78/0x100 el0_svc_handler+0x38/0x78 el0_svc+0x8/0xc ---[ end trace 3d1024e58f77f6b2 ]--- So fix the issue by checking if the policy is invalid early in __cpufreq_get before attempting to get the current frequency. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-12-24cpufreq: imx7s: add i.MX 7SoloStefan Agner
The i.MX 7Solo currently does not have multiple operating points, however, in order for the i.MX Thermal driver to successfully probe a cpufreq device is required. Add i.MX 7Solo to the devices which use the generic device tree cpufreq driver. Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
2018-12-12Merge tag 'v4.9.144' into 4.9-2.3.x-imxMarcel Ziswiler
This is the 4.9.144 stable release
2018-12-01cpufreq: imx6q: add return value check for voltage scaleAnson Huang
[ Upstream commit 6ef28a04d1ccf718eee069b72132ce4aa1e52ab9 ] Add return value check for voltage scale when ARM clock rate change fail. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-11-13cpufreq: dt: Try freeing static OPPs only if we have added themViresh Kumar
[ Upstream commit 51c99dd2c06b234575661fa1e0a1dea6c3ef566f ] We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore since the latest OPP core updates as that uses reference counting to free resources. There are cases where no static OPPs are added (using DT) for a platform and trying to remove the OPP table may end up decrementing refcount which is already zero and hence generating warnings. Lets track if we were able to add static OPPs or not and then only remove the table based on that. Some reshuffling of code is also done to do that. Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-20sched/cputime: Convert kcpustat to nsecsFrederic Weisbecker
commit 7fb1327ee9b92fca27662f9b9d60c7c3376d6c69 upstream. Kernel CPU stats are stored in cputime_t which is an architecture defined type, and hence a bit opaque and requiring accessors and mutators for any operation. Converting them to nsecs simplifies the code and is one step toward the removal of cputime_t in the core code. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@redhat.com> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Wanpeng Li <wanpeng.li@hotmail.com> Link: http://lkml.kernel.org/r/1485832191-26889-4-git-send-email-fweisbec@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> [colona: minor conflict as 527b0a76f41d ("sched/cpuacct: Avoid %lld seq_printf warning") is missing from v4.9] Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-24MLK-18205-14 cpufreq: imx8mq: add pmic voltage scaling supportAnson Huang
i.MX8MM shares same cpu-freq driver with i.MX8MQ, but its EVK board has a PMIC which can scale VDD_ARM voltage according to voltage defined in dtb, add support for it. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Bai Ping <ping.bai@nxp.com>
2018-08-24MLK-17293-6 cpufreq: imx7ulp: support new set-pointsAnson Huang
According to datasheet Rev-D, on B0 part, below CPU freq needs to be supported: 500MHz for RUN mode; 720MHz for HSRUN mode. To achieve best accurate frequency for CPU, adjust SPLL's frequency for SPLL_PFD0 which is CPU's clock source: SPLL 528MHz -> SPLL_PFD0 500.2MHz; SPLL 480MHz -> SPLL_PFD0 720MHz; Remove CPU RUN/HSRUN mode switch, since it is implemented as clock mux, whenever clock parent is switched, the RUN/HSRUN mode will be changed accordingly. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Bai Ping <ping.bai@nxp.com>
2018-08-24MLK-16710 cpufreq: imx8mq: avoid duplicated OPP table initializationAnson Huang
On i.MX8MQ, since the OPP table is initialized in cpu-freq platform device register according to chip type, so no need to redo the OPP table initialization in cpu-freq driver, this patch adds check for OPP table initialization to avoid below warning during boot up: [ 1.468378] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1501 [ 1.468388] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1301 [ 1.468417] cpu cpu0: _of_add_opp_table_v1: Failed to add OPP 1300000000 [ 1.468425] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1001 [ 1.468434] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 8001 [ 1.468443] cpu cpu0: _of_add_opp_table_v1: Failed to add OPP 800000000 Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Bai Ping <ping.bai@nxp.com>
2018-08-24MLK-16477 cpufreq: imx8: switch cpufreq governor to schedutil for multi-clusterAnson Huang
For multi-cluster platforms like i.MX8QM, the best cpufreq governor is schedutil, as common cpufreq framework decides default cpufreq governor in static compile, so this patch adds dynamic switch of cpufreq governor according to cluster number, changing it via sysfs interface, although it is ugly, but it realizes dynamic cpufreq governor select for users. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-14747 driver: cpufreq: Correct dc regulator voltage on imx6ullBai Ping
On i.MX6ULL EVK board, when the overdrive mode(900MHz/800MHz) is enable, the DC regulator voltage should not be changed. Keep the DC regulator to default 1.4V. Signed-off-by: Bai Ping <ping.bai@nxp.com> (cherry picked from commit e4b51b651ae95226c0ae0447673c64b23b079ee6) Conflicts: drivers/cpufreq/imx6q-cpufreq.c
2018-08-24MLK-16372-2 cpufreq: imx8: add cpu-freq cooling supportAnson Huang
Register cpu-freq cooling device if device tree supports cooling-cells, different cluster can have its own cooling device settings. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-16165-2 cpufreq: imx8mq: remove non-necessary opp table initializationAnson Huang
For i.MX8MQ, suspend freq can use policy->max after cpu freq table is validated, so no need to get OPP number and MAX frequency for suspend freq now, also add necessary resource free when probe failed. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-16165-1 cpufreq: imx8: remove non-necessary opp table initializationAnson Huang
For i.MX8QM/8QXP, suspend freq can use policy->max after cpu freq table is validated, so no need to get OPP number and MAX frequency for suspend freq now, also add necessary resource free when probe failed. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-16244-2 cpufreq: imx8: add SIP cpu-freq supportAnson Huang
Add SIP cpu-freq support, the CPU hardware frequency scale will be performed by ARM Trusted Firmware, and add cpu-freq suspend support, MAX frequency will be used during suspend. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-16121-1 cpufreq: imx8mq: add gpio regulator supportAnson Huang
i.MX8MQ can run at over-drive mode which needs increasing VDD_ARM voltage, add gpio regulator support for over-drive mode. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-16093-3 cpufreq: imx8mq: add cooling device supportAnson Huang
Add i.MX8MQ cooling device support, when temperature exceeds passive threshold, cpu-freq will drop to lowest set-point, and once temperature drops below passive threshold, cpu-freq will restore. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-15342-3 cpufreq: add i.mx8mq supportAnson Huang
Add i.MX8MQ cpufreq support, current version of EVK board does NOT support voltage scale, but next version will add this support, so this driver only supports cpu frequency scale, voltage scale will be added later once new board available. A53 CPU clock normally is from ARM_PLL, but during ARM_PLL relock window, it will be switched to SYS1_PLL_800M to avoid clock missing, and after arm pll relock done, it will be switched back. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-14530-02 driver: cpufreq: Improve the the cpufreq for imx7ulpBai Ping
The pm Qos add/remove only need to be called when A7 change mode between HSRUN and RUN mode. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2018-08-24MLK-14653 cpufreq: imx6q: reparent pll1_sys to pll1_bypass before changing ↵Octavian Purdila
it's rate Make sure we reparent pll1_sys to pll1_bypass before changing it's rate. Otherwise, it may happen that pll1_sys is "parented" to pll1_bypass_src like this: osc pll1 0 0 996000000 0 0 pll1_bypass_src 0 0 24000000 0 0 pll1_bypass 0 0 24000000 0 0 pll1_sys 0 0 24000000 0 0 in which case changing the rate of pll1_sys won't propagate up to pll1 and we will end up with a different pll1_sys rate than requested. This fixes an issue where cpufreq can't properly switch to 792Mhz: $ cpufreq-set -f 996000 $ cpufreq-set -f 396000 $ cpufreq-set -f 792000 $ cat /sys/kernel/debug/clk/clk_summary pll1 1 1 996000000 0 0 pll1_bypass 1 1 996000000 0 0 pll1_sys 1 1 996000000 0 0 pll1_sw 1 1 996000000 0 0 arm 2 2 498000000 0 0 Signed-off-by: Octavian Purdila <octavian.purdila@nxp.com>
2018-08-24MLK-14668 cpufreq: interactive: check index before using itOctavian Purdila
This also fixes the following warning: drivers/cpufreq/cpufreq_interactive.c: In function 'choose_freq': drivers/cpufreq/cpufreq_interactive.c:284:7: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized] if (ret) ^ Signed-off-by: Octavian Purdila <octavian.purdila@nxp.com>
2018-08-24MLK-14624 cpufreq: imx6q: imx6ull should use the same flow as imx6ulOctavian Purdila
This fixes an issue with imx6ull where setting the frequency to 528Mhz would actually set the ARM clock to 324Mhz. Signed-off-by: Octavian Purdila <octavian.purdila@nxp.com> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
2018-08-24MLK-14534-1 cpufreq: imx8: add cpu-freq supportAnson Huang
Add multi-clusters cpu-freq driver support for i.MX8, only support cpu-freq get now. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-14301: Revert "MLK-11343-01 cpufreq: imx: replace clk_get & ↵Leonard Crestez
regulator_get will devm ones" Upstream rejected this patch because it is wrong: Attaching clk and regulator resources to the cpu device results in them never actually getting freed. This is relevant now that we rely on supporting EPROBE_DEFER because we must handle correctly returning from a partial probe. In particular this patch fixes imx6qp-sabresd not setting the PU regulator to bypass mode because the cpufreq driver fetched the regulator before gpc and leaked it. This is not a straight revert because other clks and regulators were added, we add code to free them too. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
2018-08-24MLK-13914-04 cpufreq: imx7ulp: Add cpufreq driver on i.mx7ulpBai Ping
According to the i.MX7ULP RM & datasheet, when A7 is in RUN mode, the max CPU frequency it can run at is 500MHz, if we want to increase the A7 CPU frequency to 800MHz, we need to change the A7 from RUN mode to HSRUN mode. And only when A7 is in RUN mode, we can enter STOP mode and VLLS mode. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2018-08-24MLK-13869 cpufreq: imx7: use updated arm clkIrina Tirdea
The "arm" clock for imx7d has been modified to encapsulate all other clocks needed for normal functioning ("arm_root_src", "pll_arm", "pll_sys_main"). Modify cpufreq to use the new version of "arm" clock. Signed-off-by: Irina Tirdea <irina.tirdea@nxp.com>
2018-08-24MLK-13793-1 cpufreq: imx6q: Return regulator error in probeIrina Tirdea
If there are any errors in getting the cpu0 regulators, the driver returns -ENOENT. In case the regulators are not yet available, the devm_regulator_get calls will return -EPROBE_DEFER, so that the driver can be probed later. If we return -ENOENT, the driver will fail its initialization and will not try to probe again (when the regulators become available). Return the actual error received from regulator_get in probe. Print a differentiated message in case we need to probe the device later and in case we actually failed. Also add a message to inform when the driver has been successfully registered. Signed-off-by: Irina Tirdea <irina.tirdea@nxp.com>
2018-08-24MLK-13843: Ensure PLL1 is bypassed before ARM-PODF is setLeonard Crestez
This is a missing piece of 99a978fbde34227a2ab2a3595446b757b5d7c3ab from linux-imx/imx_4.1.y. This fixes a hang on imx6sl when attempting to decrease cpufreq during late boot. This was found through tracing and comparing code with the imx_4.1.y branch
2018-08-24MLK-13616 ARM: imx: Add low power run voltage change support on i.MX6SLLBai Ping
On i.MX6SLL, if all PLLs is bypassed in low power run mode, we can decrease the VDD_ARM_IN and VDD_SOC_IN voltage to 0.925V to save power. a 25mV margin is added to cover IR drop and board tolerance. Add low power run voltage change support for i.MX6SLL. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2018-08-24MLK-13133-02 cpufreq: imx: Fix system hang when entring low bus mode on imx6ullBai Ping
On i.MX6ULL, when the CPU freq is running at 198MHz or 396MHz, the system will enter low bus mode if no device need high bus mode. The first time the system entering low bus mode, CPU freq will be set to 24MHz, if cpufreq change the CPU freq from 198MHz(396MHz) to 396MHz(198MHz), the CPU freq will be set to 198MHz or 396 MHz. At this time, if the CPU enter low power idle, system will hang. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2018-08-24MLK-13119-3 cpufreq: imx6q: support VPU 396MHzAnson Huang
When VPU runs at 396MHz, VDDSOC_CAP's voltage should be set to 1.275V for all set-points, add VPU clock rate check to support this case. Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
2018-08-24MLK-13096-02 cpufreq: imx: update the cpufeq for imx6llBai Ping
According the the latest datasheet, we updated the lowest OPP to 198MHz. So we need to update the cpufreq code to fix the syttem hang issue when run 'cpufreq-info' in low bus mode on i.MX6ULL. Signed-off-by: Bai Ping <ping.bai@nxp.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-31 12:43:04 +0000