summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
2020-02-09cpufreq: 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>
2020-02-07Merge tag 'v4.14.164' into 4.14-2.3.x-imxMarcel Ziswiler
This is the 4.14.164 stable release Conflicts: arch/arm/Kconfig.debug arch/arm/boot/dts/imx7s.dtsi arch/arm/mach-imx/cpuidle-imx6q.c arch/arm/mach-imx/cpuidle-imx6sx.c arch/arm64/kernel/cpu_errata.c arch/arm64/kvm/hyp/tlb.c drivers/crypto/caam/caamalg.c drivers/crypto/mxs-dcp.c drivers/dma/imx-sdma.c drivers/gpio/gpio-vf610.c drivers/gpu/drm/bridge/adv7511/adv7511_drv.c drivers/input/keyboard/imx_keypad.c drivers/input/keyboard/snvs_pwrkey.c drivers/mmc/core/block.c drivers/mmc/core/queue.h drivers/mmc/host/sdhci-esdhc-imx.c drivers/net/can/flexcan.c drivers/net/can/rx-offload.c drivers/net/ethernet/freescale/fec_main.c drivers/net/wireless/ath/ath10k/pci.c drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c drivers/pci/dwc/pci-imx6.c drivers/spi/spi-fsl-lpspi.c drivers/usb/dwc3/gadget.c include/net/tcp.h sound/soc/fsl/Kconfig sound/soc/fsl/fsl_esai.c
2019-12-31cpufreq: 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-12-17cpufreq: powernv: fix stack bloat and hard limit on number of CPUsJohn Hubbard
commit db0d32d84031188443e25edbd50a71a6e7ac5d1d upstream. The following build warning occurred on powerpc 64-bit builds: drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is with a cross-compiler based on gcc 8.1.0, which I got from: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ The warning is due to putting 1024 bytes on the stack: unsigned int chip[256]; ...and it's also undesirable to have a hard limit on the number of CPUs here. Fix both problems by dynamically allocating based on num_possible_cpus, as recommended by Michael Ellerman. Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.10+ <stable@vger.kernel.org> # 4.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-01cpufreq: 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-12-01cpufreq: 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-11-12cpufreq: ti-cpufreq: add missing of_node_put()Zumeng Chen
commit 248aefdcc3a7e0cfbd014946b4dead63e750e71b upstream call of_node_put to release the refcount of np. Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@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-16cpufreq/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: kirkwood: fix possible object reference leakWen Yang
[ Upstream commit 7c468966f05ac9c17bb5948275283d34e6fe0660 ] The call to of_get_child_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/kirkwood-cpufreq.c:127:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 118, but without a corresponding object release within this function. ./drivers/cpufreq/kirkwood-cpufreq.c:133:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 118, but without a corresponding object release within this function. and also do some cleanup: - of_node_put(np); - np = NULL; ... of_node_put(np); 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-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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-05cpufreq: acpi-cpufreq: Report if CPU doesn't support boost technologiesErwan Velu
[ Upstream commit 1222d527f314c86a3b59a522115d62facc5a7965 ] There is some rare cases where CPB (and possibly IDA) are missing on processors. This is the case fixed by commit f7f3dc00f612 ("x86/cpu/AMD: Fix erratum 1076 (CPB bit)") and following. In such context, the boost status isn't reported by /sys/devices/system/cpu/cpufreq/boost. This commit is about printing a message to report that the CPU doesn't expose the boost capabilities. This message could help debugging platforms hit by this phenomena. Signed-off-by: Erwan Velu <e.velu@criteo.com> [ rjw: Change the message text somewhat ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
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>
2019-02-12MLK-20203-2 cpufreq: imx7ulp: fix coverity issueAnson Huang
This patch fixes coverity issue of "divide by 0". Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Bai Ping <ping.bai@nxp.com>
2019-02-12MLK-20203-1 cpufreq: imx6q: fix coverity issueAnson Huang
This patch fixes coverity issue of "unchecked return value". Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Bai Ping <ping.bai@nxp.com>
2019-02-12MLK-20104 driver: cpufreq: remove unnecessary mutex & rcu lockBai Ping
Remove the unnecessary mutex and rcu lock from i.MX8MQ & i.MX7ULP cpufreq driver. Signed-off-by: Bai Ping <ping.bai@nxp.com> Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
2019-02-12MLK-19589-03 driver: cpufreq: Add cpufreq support for imx6ulzBai Ping
Add cpufreq support for i.MX6ULZ. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-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>
2019-02-12MLK-13014 ARM: imx: fix system hang when run cpufreq-info in low bus modeBai Ping
On i.MX6ULL, when the system entering the low bus mode, system will enter low power run mode in which the cpufreq is at 24MHz. If we run 'cpufreq-info' until, the cpu frequency will be change from 24MHz to 99MHz, this will lead to system enter low power idle wrong, and system will hang in low power idle. Add the ARM core clock handling code to fix this issue. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2019-02-12MLK-12868-01 cpufreq: imx: get old_freq from policy->curBai Ping
Get the old_freq from the policy->cur. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2019-02-12MLK-12623-01 cpufreq: imx: Add support for 700MHz setpoint in cpufreqBai Ping
On i.MX6UL EVK board, we use a external GPIO DC regulator to control the VDD_ARM_SOC_IN voltage, if default voltage is 1.4V when the system is bootup. Per design team, when the highest setpoint freq is not bigger than 528MHz, we can decrease this regulator voltage to 1.3V. On i.MX6UL TO1.1, we add a 700MHz setpoint. When the highest setpoint freq is 700MHz, the DC regulator should be at 1.4V to to cover the IR drop. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2019-02-12cpufreq: Add android's 'interactive' governorViresh Kumar
Interactive governor has lived in Android sources for a very long time and this commit is based on the code present in following branch: https://android.googlesource.com/kernel/common android-4.4 The Interactive governor is designed for latency-sensitive workloads, such as interactive user interfaces like the mobile phones and tablets. The interactive governor aims to be significantly more responsive to ramp CPU quickly up when CPU-intensive activity begins. Existing governors sample CPU load at a particular rate, typically every X ms and then update the frequency from a work-handler. This can lead to under-powering UI threads for the period of time during which the user begins interacting with a previously-idle system until the next sample period happens. The 'interactive' governor uses a different approach. A real-time thread is used for scaling up, giving the remaining tasks the CPU performance benefit, unlike existing governors which are more likely to schedule ramp-up work to occur after your performance starved tasks have completed. The Android version of interactive governor also checks whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, the governor check if the CPU sampling is overdue or not. If yes, it immediately starts the sampling. Otherwise, the utilization hooks from the scheduler handle the sampling later. If the CPU is very busy from exiting idle to when the evaluation happens, then it assumes that the CPU is under-powered and ramps it to MAX speed. If the CPU was not sufficiently busy to immediately ramp to MAX speed, then the governor evaluates the CPU load since the last speed adjustment, choosing the highest value between that longer-term load or the short-term load since idle exit to determine the CPU speed to ramp to. Idle notifiers will be be handled later and are not included for now. The core of this code is written and maintained (in Android repositories) by Mike Chan and Todd Poyner over a long period of time. Vireshk has made changes to to the governor to align it with the current practices followed with mainline governors, like using utilization hooks from the scheduler and handling kobject (for governor's sysfs directory) in a race free manner. And of course this included general cleanup of the governor as well. Signed-off-by: Mike Chan <mike@android.com> Signed-off-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-12cpufreq: Move gov_attr_* macros to cpufreq.hViresh Kumar
These macros can be reused by governors which don't use the common governor code present in cpufreq_governor.c and should be moved to the relevant header. Now that they are getting moved to the right header file, reuse them in schedutil governor as well (that required rename of show/store routines). Also create gov_attr_wo() macro for write-only sysfs files, this will be used by Interactive governor in a later patch. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-12MLK-11252-02 cpufreq: imx: add dc regulator in cpufreq driverLeonard Crestez
In some i.MX6 board (i.MX6UL EVK), it will have a additional GPIO controlled DC-DC regulator. we need to change this regulator's voltage According the maximum frequency that CPU can run at. At present, we only need to set the voltage to minimum one, we need to set the voltage to the maximum before suspend, resume back to the minimum voltage after suspend. Signed-off-by: Bai Ping <b51503@freescale.com> (cherry picked from commit 31f0773ee7d6ba5715486a221857f2ceccb434b4)
2019-02-12cpufreq: imx6: add empty imx6_cpufreq_pm_notifyLeonard Crestez
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-17 18:21:38 +0000