08 Oct, 2020
1 commit
-
* tag 'v5.4.70': (3051 commits)
Linux 5.4.70
netfilter: ctnetlink: add a range check for l3/l4 protonum
ep_create_wakeup_source(): dentry name can change under you...
...Conflicts:
arch/arm/mach-imx/pm-imx6.c
arch/arm64/boot/dts/freescale/imx8mm-evk.dts
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
drivers/crypto/caam/caamalg.c
drivers/gpu/drm/imx/dw_hdmi-imx.c
drivers/gpu/drm/imx/imx-ldb.c
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
drivers/mmc/host/sdhci-esdhc-imx.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/net/ethernet/freescale/enetc/enetc.c
drivers/net/ethernet/freescale/enetc/enetc_pf.c
drivers/thermal/imx_thermal.c
drivers/usb/cdns3/ep0.c
drivers/xen/swiotlb-xen.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.cSigned-off-by: Jason Liu
01 Oct, 2020
1 commit
-
[ Upstream commit d95fe371ecd28901f11256c610b988ed44e36ee2 ]
The patch avoids allocating cpufreq_policy on stack hence fixing frame
size overflow in 'powernv_cpufreq_work_fn'Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling")
Signed-off-by: Pratik Rajesh Sampat
Reviewed-by: Daniel Axtens
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/20200316135743.57735-1-psampat@linux.ibm.com
Signed-off-by: Sasha Levin
17 Sep, 2020
2 commits
-
[ Upstream commit eacc9c5a927e474c173a5d53dd7fb8e306511768 ]
This fixes the behavior of the scaling_max_freq and scaling_min_freq
sysfs files in systems which had turbo disabled by the BIOS.Caleb noticed that the HWP is programmed to operate in the wrong
P-state range on his system when the CPUFREQ policy min/max frequency
is set via sysfs. This seems to be because in his system
intel_pstate_get_hwp_max() is returning the maximum turbo P-state even
though turbo was disabled by the BIOS, which causes intel_pstate to
scale kHz frequencies incorrectly e.g. setting the maximum turbo
frequency whenever the maximum guaranteed frequency is requested via
sysfs.Tested-by: Caleb Callaway
Signed-off-by: Francisco Jerez
Acked-by: Srinivas Pandruvada
[ rjw: Minor subject edits ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit 43298db3009f06fe5c69e1ca8b6cfc2565772fa1 ]
After commit f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive
mode with HWP enabled") it is possible to change the driver status
to "off" via sysfs with HWP enabled, which effectively causes the
driver to unregister itself, but HWP remains active and it forces the
minimum performance, so even if another cpufreq driver is loaded,
it will not be able to control the CPU frequency.For this reason, make the driver refuse to change the status to
"off" with HWP enabled.Signed-off-by: Rafael J. Wysocki
Acked-by: Srinivas Pandruvada
Signed-off-by: Sasha Levin
03 Sep, 2020
1 commit
-
[ Upstream commit de002c55cadfc2f6cdf0ed427526f6085d240238 ]
Because intel_pstate_set_energy_pref_index() reads and writes the
MSR_HWP_REQUEST register without using the cached value of it used by
intel_pstate_hwp_boost_up() and intel_pstate_hwp_boost_down(), those
functions may overwrite the value written by it and so the EPP value
set via sysfs may be lost.To avoid that, make intel_pstate_set_energy_pref_index() take the
cached value of MSR_HWP_REQUEST just like the other two routines
mentioned above and update it with the new EPP value coming from
user space in addition to updating the MSR.Note that the MSR itself still needs to be updated too in case
hwp_boost is unset or the boosting mechanism is not active at the
EPP change time.Fixes: e0efd5be63e8 ("cpufreq: intel_pstate: Add HWP boost utility and sched util hooks")
Reported-by: Francisco Jerez
Cc: 4.18+ # 4.18+: 3da97d4db8ee cpufreq: intel_pstate: Rearrange ...
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Francisco Jerez
Signed-off-by: Sasha Levin
26 Aug, 2020
1 commit
-
[ Upstream commit 4daca379c703ff55edc065e8e5173dcfeecf0148 ]
The MSR_TURBO_RATIO_LIMIT can be 0. This is not an error. User can update
this MSR via BIOS settings on some systems or can use msr tools to update.
Also some systems boot with value = 0.This results in display of cpufreq/cpuinfo_max_freq wrong. This value
will be equal to cpufreq/base_frequency, even though turbo is enabled.But platform will still function normally in HWP mode as we get max
1-core frequency from the MSR_HWP_CAPABILITIES. This MSR is already used
to calculate cpu->pstate.turbo_freq, which is used for to set
policy->cpuinfo.max_freq. But some other places cpu->pstate.turbo_pstate
is used. For example to set policy->max.To fix this, also update cpu->pstate.turbo_pstate when updating
cpu->pstate.turbo_freq.Signed-off-by: Srinivas Pandruvada
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
19 Aug, 2020
3 commits
-
commit 10470dec3decaf5ed3c596f85debd7c42777ae12 upstream.
Commit 0c868627e617e43a295d8 (cpufreq: dt: Allow platform specific
intermediate callbacks) added two function pointers to the
struct cpufreq_dt_platform_data. However, armada37xx_cpufreq_driver_init()
has this struct (pdata) located on the stack and uses only "suspend"
and "resume" fields. So these newly added "get_intermediate" and
"target_intermediate" pointers are uninitialized and contain arbitrary
non-null values, causing all kinds of trouble.For instance, here is an oops on espressobin after an attempt to change
the cpefreq governor:[ 29.174554] Unable to handle kernel execute from non-executable memory at virtual address ffff00003f87bdc0
...
[ 29.269373] pc : 0xffff00003f87bdc0
[ 29.272957] lr : __cpufreq_driver_target+0x138/0x580
...Fixed by zeroing out pdata before use.
Cc: # v5.7+
Signed-off-by: Ivan Kokshaysky
Reviewed-by: Andrew Lunn
Signed-off-by: Viresh Kumar
Signed-off-by: Greg Kroah-Hartman -
commit 8cc46ae565c393f77417cb9530b1265eb50f5d2e upstream.
The locking around governors handling isn't adequate currently.
The list of governors should never be traversed without the locking
in place. Also governor modules must not be removed while the code
in them is still in use.Reported-by: Quentin Perret
Signed-off-by: Viresh Kumar
Cc: All applicable
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 8c37ad2f523396e15cf002b29f8f796447c71932 ]
The Armada 8K cpufreq driver needs the Armada AP CPU CLK
to work. This dependency is currently not satisfied and
the ARMADA_AP_CPU_CLK can not be selected independently.Add it to the cpufreq Armada8k driver.
Fixes: f525a670533d ("cpufreq: ap806: add cpufreq driver for Armada 8K")
Signed-off-by: Sven Auhagen
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
19 Jun, 2020
1 commit
-
* tag 'v5.4.47': (2193 commits)
Linux 5.4.47
KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
...Conflicts:
arch/arm/boot/dts/imx6qdl.dtsi
arch/arm/mach-imx/Kconfig
arch/arm/mach-imx/common.h
arch/arm/mach-imx/suspend-imx6.S
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
arch/powerpc/include/asm/cacheflush.h
drivers/cpufreq/imx6q-cpufreq.c
drivers/dma/imx-sdma.c
drivers/edac/synopsys_edac.c
drivers/firmware/imx/imx-scu.c
drivers/net/ethernet/freescale/fec.h
drivers/net/ethernet/freescale/fec_main.c
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
drivers/net/phy/phy_device.c
drivers/perf/fsl_imx8_ddr_perf.c
drivers/usb/cdns3/gadget.c
drivers/usb/dwc3/gadget.c
include/uapi/linux/dma-buf.hSigned-off-by: Jason Liu
17 Jun, 2020
1 commit
-
commit 552abb884e97d26589964e5a8c7e736f852f95f0 upstream.
After commit 18c49926c4bf ("cpufreq: Add QoS requests for userspace
constraints") the return value of freq_qos_update_request(), that can
be 1, passed by cpufreq_boost_set_sw() to its caller sometimes
confuses the latter, which only expects to see 0 or negative error
codes, so notice that cpufreq_boost_set_sw() can return an error code
(which should not be -EINVAL for that matter) as soon as the first
policy without a frequency table is found (because either all policies
have a frequency table or none of them have it) and rework it to meet
its caller's expectations.Fixes: 18c49926c4bf ("cpufreq: Add QoS requests for userspace constraints")
Reported-by: Serge Semin
Reported-by: Xiongfeng Wang
Acked-by: Viresh Kumar
Cc: 5.3+ # 5.3+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
20 May, 2020
1 commit
-
[ Upstream commit 8c539776ac83c0857395e1ccc9c6b516521a2d32 ]
Make a note of the first time we discover the turbo mode has been
disabled by the BIOS, as otherwise we complain every time we try to
update the mode.Signed-off-by: Chris Wilson
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
07 May, 2020
1 commit
-
It is possible that the regulator_get will return defer probe error if
the regulator is not ready when cpufreq doing probe. cpufreq need to
defer probe again if regulator_get return '-EPROBE_DEFER', so fix it.Signed-off-by: Jacky Bai
Reviewed-by: Anson Huang
17 Apr, 2020
3 commits
-
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
Reviewed-by: Gautham R. Shenoy
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/20200206062622.28235-1-oohall@gmail.com
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3646f50a3838c5949a89ecbdb868497cdc05b8fd ]
When speed checking failed, direclty jumping to put_node label
is not correct. Need jump to out_free_opp to avoid resources leak.Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
Signed-off-by: Peng Fan
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin -
[ Upstream commit 36eb7dc1bd42fe5f850329c893768ff89b696fba ]
imx6ul_opp_check_speed_grading is called for both i.MX6UL and i.MX6ULL.
Since the i.MX6ULL was introduced to a separate ocotp compatible node
later, it is possible that the i.MX6ULL has also dtbs with
"fsl,imx6ull-ocotp". On a system without nvmem-cell speed grade a
missing check on this node causes a driver fail without considering
the cpu speed grade.This patch prevents unwanted cpu overclocking on i.MX6ULL with compatible
node "fsl,imx6ull-ocotp" in old dtbs without nvmem-cell speed grade.Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
Signed-off-by: Christoph Niedermaier
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
10 Mar, 2020
1 commit
-
i.MX8MP's market segment fuse location is 0x440 bit[6:5], corrent it.
Signed-off-by: Anson Huang
Reviewed-by: Jacky Bai
08 Mar, 2020
1 commit
-
Merge Linux stable release v5.4.24 into imx_5.4.y
* tag 'v5.4.24': (3306 commits)
Linux 5.4.24
blktrace: Protect q->blk_trace with RCU
kvm: nVMX: VMWRITE checks unsupported field before read-only field
...Signed-off-by: Jason Liu
Conflicts:
arch/arm/boot/dts/imx6sll-evk.dts
arch/arm/boot/dts/imx7ulp.dtsi
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
drivers/clk/imx/clk-composite-8m.c
drivers/gpio/gpio-mxc.c
drivers/irqchip/Kconfig
drivers/mmc/host/sdhci-of-esdhc.c
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
drivers/net/can/flexcan.c
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
drivers/net/ethernet/mscc/ocelot.c
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
drivers/net/phy/realtek.c
drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
drivers/perf/fsl_imx8_ddr_perf.c
drivers/tee/optee/shm_pool.c
drivers/usb/cdns3/gadget.c
kernel/sched/cpufreq.c
net/core/xdp.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.c
sound/soc/sof/core.c
sound/soc/sof/imx/Kconfig
sound/soc/sof/loader.c
05 Mar, 2020
1 commit
-
commit f5739cb0b56590d68d8df8a44659893b6d0084c3 upstream.
Before commit 1e4f63aecb53 ("cpufreq: Avoid creating excessively
large stack frames") the initial value of the policy field in struct
cpufreq_policy set by the driver's ->init() callback was implicitly
passed from cpufreq_init_policy() to cpufreq_set_policy() if the
default governor was neither "performance" nor "powersave". After
that commit, however, cpufreq_init_policy() must take that case into
consideration explicitly and handle it as appropriate, so make that
happen.Fixes: 1e4f63aecb53 ("cpufreq: Avoid creating excessively large stack frames")
Link: https://lore.kernel.org/linux-pm/39fb762880c27da110086741315ca8b111d781cd.camel@gmail.com/
Reported-by: Artem Bityutskiy
Cc: 5.4+ # 5.4+
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
Signed-off-by: Greg Kroah-Hartman
11 Feb, 2020
1 commit
-
commit 1e4f63aecb53e48468661e922fc2fa3b83e55722 upstream.
In the process of modifying a cpufreq policy, the cpufreq core makes
a copy of it including all of the internals which is stored on the
CPU stack. Because struct cpufreq_policy is relatively large, this
may cause the size of the stack frame to exceed the 2 KB limit and
so the GCC complains when -Wframe-larger-than= is used.In fact, it is not necessary to copy the entire policy structure
in order to modify it, however.First, because cpufreq_set_policy() obtains the min and max policy
limits from frequency QoS now, it is not necessary to pass the limits
to it from the callers. The only things that need to be passed to it
from there are the new governor pointer or (if there is a built-in
governor in the driver) the "policy" value representing the governor
choice. They both can be passed as individual arguments, though, so
make cpufreq_set_policy() take them this way and rework its callers
accordingly. This avoids making copies of cpufreq policies in the
callers of cpufreq_set_policy().Second, cpufreq_set_policy() still needs to pass the new policy
data to the ->verify() callback of the cpufreq driver whose task
is to sanitize the min and max policy limits. It still does not
need to make a full copy of struct cpufreq_policy for this purpose,
but it needs to pass a few items from it to the driver in case they
are needed (different drivers have different needs in that respect
and all of them have to be covered). For this reason, introduce
struct cpufreq_policy_data to hold copies of the members of
struct cpufreq_policy used by the existing ->verify() driver
callbacks and pass a pointer to a temporary structure of that
type to ->verify() (instead of passing a pointer to full struct
cpufreq_policy to it).While at it, notice that intel_pstate and longrun don't really need
to verify the "policy" value in struct cpufreq_policy, so drop those
check from them to avoid copying "policy" into struct
cpufreq_policy_data (which allows it to be slightly smaller).Also while at it fix up white space in a couple of places and make
cpufreq_set_policy() static (as it can be so).Fixes: 3000ce3c52f8 ("cpufreq: Use per-policy frequency QoS")
Link: https://lore.kernel.org/linux-pm/CAMuHMdX6-jb1W8uC2_237m8ctCpsnGp=JCxqt8pCWVqNXHmkVg@mail.gmail.com
Reported-by: kbuild test robot
Reported-by: Geert Uytterhoeven
Cc: 5.4+ # 5.4+
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
Signed-off-by: Greg Kroah-Hartman
31 Dec, 2019
2 commits
-
[ 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 successfullyBecause 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
Co-developed-by: Amit Kucheria
Signed-off-by: Viresh Kumar
Tested-by: Amit Kucheria
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit c23734487fb44ee16c1b007ba72d793c085e4ec4 ]
I have observed failures to boot on Orange Pi 3, because this driver
determined that my SoC is from the normal bin, but my SoC only works
reliably with the OPP values for the slowest bin.By querying H6 owners, it was found that e-fuse values found in the wild
are in the range of 1-3, value of 7 was not reported, yet. From this and
from unused defines in BSP code, it can be assumed that meaning of efuse
values on H6 actually is:- 1 = slowest bin
- 2 = normal bin
- 3 = fastest binVendor code actually treats 0 and 2 as invalid efuse values, but later
treats all invalid values as a normal bin. This looks like a mistake in
bin detection code, that was plastered over by a hack in cpufreq code,
so let's not repeat it here. It probably only works because there are no
SoCs in the wild with efuse value of 0, and fast bin SoCs are made to
use normal bin OPP tables, which is also safe.Let's play it safe and interpret 0 as the slowest bin, but fix detection
of other bins to match this research. More research will be done before
actual OPP tables are merged.Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
Acked-by: Maxime Ripard
Signed-off-by: Ondrej Jirman
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
26 Dec, 2019
2 commits
-
i.MX8MP uses operating-points-v2, add it to blacklist for proper
OPPs initialization.Signed-off-by: Anson Huang
Reviewed-by: Peng Fan -
Add i.MX8MP cpufreq DT support for speed grading and market
segment check.Signed-off-by: Anson Huang
Reviewed-by: Peng Fan
18 Dec, 2019
1 commit
-
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
Acked-by: Viresh Kumar
Cc: 4.10+ # 4.10+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
16 Dec, 2019
1 commit
-
This is the 5.4.3 stable release
Conflicts:
drivers/cpufreq/imx-cpufreq-dt.c
drivers/spi/spi-fsl-qspi.cThe conflict is very minor, fixed it when do the merge. The imx-cpufreq-dt.c
is just one line code-style change, using upstream one, no any function change.The spi-fsl-qspi.c has minor conflicts when merge upstream fixes: c69b17da53b2
spi: spi-fsl-qspi: Clear TDH bits in FLSHCR registerAfter merge, basic boot sanity test and basic qspi test been done on i.mx
Signed-off-by: Jason Liu
13 Dec, 2019
1 commit
-
[ Upstream commit af44d180e3de4cb411ce327b147ea3513f0bbbcb ]
i.MX8MN has different speed grade definition compared to
i.MX8MQ/i.MX8MM, when fuses are NOT written, the default
speed_grade should be set to minimum available OPP defined
in DT which is 1.2GHz, the corresponding speed_grade value
should be 0xb.Fixes: 5b8010ba70d5 ("cpufreq: imx-cpufreq-dt: Add i.MX8MN support")
Signed-off-by: Anson Huang
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
29 Nov, 2019
1 commit
-
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_freqThis bug was found in linux 4.19.
Signed-off-by: Kai Shen
Reported-by: Feilong Lin
Reviewed-by: Feilong Lin
Acked-by: Viresh Kumar
[ rjw: Subject & changelog ]
Cc: All applicable
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
25 Nov, 2019
6 commits
-
i.MX8MN has different speed grade definition compared to
i.MX8MQ/i.MX8MM, when fuses are NOT written, the default
speed_grade should be set to minimum available OPP defined
in DT which is 1.2GHz, the corresponding speed_grade value
should be 0xb.Fixes: 5b8010ba70d5 ("cpufreq: imx-cpufreq-dt: Add i.MX8MN support")
Signed-off-by: Anson Huang -
Get the old_freq from the policy->cur. So we can
get the correct frequency when low power run mode
is enabled.Signed-off-by: Jacky Bai
-
Add i.MX7ULP cpufreq driver support.
Signed-off-by: Anson Huang
-
Add the busfreq support on i.MX6ULL/SLL. add the dc regulator
support at the same time.Signed-off-by: Jacky Bai
-
For some i.MX platforms such as i.MX6SX, PLL1 is used as temporary
clock during low power idle mode enter/exit, it MUST be enabled, but
can be switch to its default bypass clock source OSC. This patch
adds support for such scenario, when PLL1 is NOT used, bypass it and
keep it enabled.Signed-off-by: Anson Huang
-
Add bus-freq request for high cpu-freq set-point and release
the request when cpu is running at lowest set-point.Signed-off-by: Anson Huang
08 Nov, 2019
1 commit
-
The max value of EPB can only be 0x0F. Attempting to set more than that
triggers an "unchecked MSR access error" warning which happens in
intel_pstate_hwp_force_min_perf() called via cpufreq stop_cpu().However, it is not even necessary to touch the EPB from intel_pstate,
because it is restored on every CPU online by the intel_epb.c code,
so let that code do the right thing and drop the redundant (and
incorrect) EPB update from intel_pstate.Fixes: af3b7379e2d70 ("cpufreq: intel_pstate: Force HWP min perf before offline")
Reported-by: Qian Cai
Cc: 5.2+ # 5.2+
Signed-off-by: Srinivas Pandruvada
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki
23 Oct, 2019
1 commit
-
Scheduled policy update work may end up racing with the freeing of the
policy and unregistering the driver.One possible race is as below, where the cpufreq_driver is unregistered,
but the scheduled work gets executed at later stage when, cpufreq_driver
is NULL (i.e. after freeing the policy and driver).Unable to handle kernel NULL pointer dereference at virtual address 0000001c
pgd = (ptrval)
[0000001c] *pgd=80000080204003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP THUMB2
Modules linked in:
CPU: 0 PID: 34 Comm: kworker/0:1 Not tainted 5.4.0-rc3-00006-g67f5a8081a4b #86
Hardware name: ARM-Versatile Express
Workqueue: events handle_update
PC is at cpufreq_set_policy+0x58/0x228
LR is at dev_pm_qos_read_value+0x77/0xac
Control: 70c5387d Table: 80203000 DAC: fffffffd
Process kworker/0:1 (pid: 34, stack limit = 0x(ptrval))
(cpufreq_set_policy) from (refresh_frequency_limits.part.24+0x37/0x48)
(refresh_frequency_limits.part.24) from (handle_update+0x2f/0x38)
(handle_update) from (process_one_work+0x16d/0x3cc)
(process_one_work) from (worker_thread+0xff/0x414)
(worker_thread) from (kthread+0xff/0x100)
(kthread) from (ret_from_fork+0x11/0x28)Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework")
Signed-off-by: Sudeep Holla
[ rjw: Cancel the work before dropping the QoS requests ]
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
21 Oct, 2019
1 commit
-
Replace the CPU device PM QoS used for the management of min and max
frequency constraints in cpufreq (and its users) with per-policy
frequency QoS to avoid problems with cpufreq policies covering
more then one CPU.Namely, a cpufreq driver is registered with the subsys interface
which calls cpufreq_add_dev() for each CPU, starting from CPU0, so
currently the PM QoS notifiers are added to the first CPU in the
policy (i.e. CPU0 in the majority of cases).In turn, when the cpufreq driver is unregistered, the subsys interface
doing that calls cpufreq_remove_dev() for each CPU, starting from CPU0,
and the PM QoS notifiers are only removed when cpufreq_remove_dev() is
called for the last CPU in the policy, say CPUx, which as a rule is
not CPU0 if the policy covers more than one CPU. Then, the PM QoS
notifiers cannot be removed, because CPUx does not have them, and
they are still there in the device PM QoS notifiers list of CPU0,
which prevents new PM QoS notifiers from being registered for CPU0
on the next attempt to register the cpufreq driver.The same issue occurs when the first CPU in the policy goes offline
before unregistering the driver.After this change it does not matter which CPU is the policy CPU at
the driver registration time and whether or not it is online all the
time, because the frequency QoS is per policy and not per CPU.Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework")
Reported-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Reported-by: Sudeep Holla
Tested-by: Sudeep Holla
Diagnosed-by: Viresh Kumar
Link: https://lore.kernel.org/linux-pm/5ad2624194baa2f53acc1f1e627eb7684c577a19.1562210705.git.viresh.kumar@linaro.org/T/#md2d89e95906b8c91c15f582146173dce2e86e99f
Link: https://lore.kernel.org/linux-pm/20191017094612.6tbkwoq4harsjcqv@vireshk-i7/T/#m30d48cc23b9a80467fbaa16e30f90b3828a5a29b
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
10 Oct, 2019
1 commit
-
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ä
Tested-by: Ville Syrjälä
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
Cc: 4.0+ # 4.0+
18 Sep, 2019
1 commit
-
Pull power management updates from Rafael Wysocki:
"These include a rework of the main suspend-to-idle code flow (related
to the handling of spurious wakeups), a switch over of several users
of cpufreq notifiers to QoS-based limits, a new devfreq driver for
Tegra20, a new cpuidle driver and governor for virtualized guests, an
extension of the wakeup sources framework to expose wakeup sources as
device objects in sysfs, and more.Specifics:
- Rework the main suspend-to-idle control flow to avoid repeating
"noirq" device resume and suspend operations in case of spurious
wakeups from the ACPI EC and decouple the ACPI EC wakeups support
from the LPS0 _DSM support (Rafael Wysocki).- Extend the wakeup sources framework to expose wakeup sources as
device objects in sysfs (Tri Vo, Stephen Boyd).- Expose system suspend statistics in sysfs (Kalesh Singh).
- Introduce a new haltpoll cpuidle driver and a new matching governor
for virtualized guests wanting to do guest-side polling in the idle
loop (Marcelo Tosatti, Joao Martins, Wanpeng Li, Stephen Rothwell).- Fix the menu and teo cpuidle governors to allow the scheduler tick
to be stopped if PM QoS is used to limit the CPU idle state exit
latency in some cases (Rafael Wysocki).- Increase the resolution of the play_idle() argument to microseconds
for more fine-grained injection of CPU idle cycles (Daniel
Lezcano).- Switch over some users of cpuidle notifiers to the new QoS-based
frequency limits and drop the CPUFREQ_ADJUST and CPUFREQ_NOTIFY
policy notifier events (Viresh Kumar).- Add new cpufreq driver based on nvmem for sun50i (Yangtao Li).
- Add support for MT8183 and MT8516 to the mediatek cpufreq driver
(Andrew-sh.Cheng, Fabien Parent).- Add i.MX8MN support to the imx-cpufreq-dt cpufreq driver (Anson
Huang).- Add qcs404 to cpufreq-dt-platdev blacklist (Jorge Ramirez-Ortiz).
- Update the qcom cpufreq driver (among other things, to make it
easier to extend and to use kryo cpufreq for other nvmem-based
SoCs) and add qcs404 support to it (Niklas Cassel, Douglas
RAILLARD, Sibi Sankar, Sricharan R).- Fix assorted issues and make assorted minor improvements in the
cpufreq code (Colin Ian King, Douglas RAILLARD, Florian Fainelli,
Gustavo Silva, Hariprasad Kelam).- Add new devfreq driver for NVidia Tegra20 (Dmitry Osipenko, Arnd
Bergmann).- Add new Exynos PPMU events to devfreq events and extend that
mechanism (Lukasz Luba).- Fix and clean up the exynos-bus devfreq driver (Kamil Konieczny).
- Improve devfreq documentation and governor code, fix spelling typos
in devfreq (Ezequiel Garcia, Krzysztof Kozlowski, Leonard Crestez,
MyungJoo Ham, Gaël PORTAY).- Add regulators enable and disable to the OPP (operating performance
points) framework (Kamil Konieczny).- Update the OPP framework to support multiple opp-suspend properties
(Anson Huang).- Fix assorted issues and make assorted minor improvements in the OPP
code (Niklas Cassel, Viresh Kumar, Yue Hu).- Clean up the generic power domains (genpd) framework (Ulf Hansson).
- Clean up assorted pieces of power management code and documentation
(Akinobu Mita, Amit Kucheria, Chuhong Yuan).- Update the pm-graph tool to version 5.5 including multiple fixes
and improvements (Todd Brandt).- Update the cpupower utility (Benjamin Weis, Geert Uytterhoeven,
Sébastien Szymanski)"* tag 'pm-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (126 commits)
cpuidle-haltpoll: Enable kvm guest polling when dedicated physical CPUs are available
cpuidle-haltpoll: do not set an owner to allow modunload
cpuidle-haltpoll: return -ENODEV on modinit failure
cpuidle-haltpoll: set haltpoll as preferred governor
cpuidle: allow governor switch on cpuidle_register_driver()
PM: runtime: Documentation: add runtime_status ABI document
pm-graph: make setVal unbuffered again for python2 and python3
powercap: idle_inject: Use higher resolution for idle injection
cpuidle: play_idle: Increase the resolution to usec
cpuidle-haltpoll: vcpu hotplug support
cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist
cpufreq: qcom: Add support for qcs404 on nvmem driver
cpufreq: qcom: Refactor the driver to make it easier to extend
cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
dt-bindings: opp: Add qcom-opp bindings with properties needed for CPR
dt-bindings: opp: qcom-nvmem: Support pstates provided by a power domain
Documentation: cpufreq: Update policy notifier documentation
cpufreq: Remove CPUFREQ_ADJUST and CPUFREQ_NOTIFY policy notifier events
PM / Domains: Verify PM domain type in dev_pm_genpd_set_performance_state()
PM / Domains: Simplify genpd_lookup_dev()
...
05 Sep, 2019
1 commit
-
Pull ARM cpufreq driver changes for 5.4 from Viresh Kumar:
"This contains:
- Minor fixes for mediatek driver (Andrew-sh.Cheng and Fabien Parent).
- Minor updates for imx driver (Anson Huang).
- Minor fix for ti-cpufreq driver (Gustavo A. R. Silva).
- Minor fix for ap806 driver (Hariprasad Kelam).
- Significant updates to qcom cpufreq drivers, mostly to support CPR
stuff (Jorge Ramirez-Ortiz, Niklas Cassel, Sibi Sankar, Douglas
RAILLARD and Sricharan R).
- New sun50i cpufreq driver (Yangtao Li).It also contains a few OPP changes which were required because of
dependencies for the qcom cpufreq changes."* 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (22 commits)
cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist
cpufreq: qcom: Add support for qcs404 on nvmem driver
cpufreq: qcom: Refactor the driver to make it easier to extend
cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
dt-bindings: opp: Add qcom-opp bindings with properties needed for CPR
dt-bindings: opp: qcom-nvmem: Support pstates provided by a power domain
cpufreq: mediatek: Add support for mt8183
cpufreq: mediatek: change to regulator_get_optional
cpufreq: imx-cpufreq-dt: Add i.MX8MN support
cpufreq: Use imx-cpufreq-dt for i.MX8MN's speed grading
cpufreq: qcom-hw: invoke frequency-invariance setter function
cpufreq: qcom-hw: Update logic to detect turbo frequency
cpufreq: mediatek-cpufreq: Add compatible for MT8516
cpufreq: ti-cpufreq: Mark expected switch fall-through
dt-bindings: opp: qcom-nvmem: Make speedbin related properties optional
dt-bindings: opp: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
opp: Add dev_pm_opp_find_level_exact()
opp: Return genpd virtual devices from dev_pm_opp_attach_genpd()
opp: Not all power-domains are scalable
cpufreq: ap806: Add NULL check after kcalloc
...