27 Nov, 2020

1 commit


24 Nov, 2020

1 commit


23 Nov, 2020

2 commits

  • Pull SCMI cpufreq driver fix for 5.10-rc6 from Viresh Kumar:

    "This fixes a build issues with SCMI cpufreq driver in the
    !CONFIG_COMMON_CLK case."

    * 'cpufreq/arm/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
    cpufreq: scmi: Fix build for !CONFIG_COMMON_CLK

    Rafael J. Wysocki
     
  • Commit 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a
    dummy clock provider") registers a dummy clock provider using
    devm_of_clk_add_hw_provider. These *_hw_provider functions are defined
    only when CONFIG_COMMON_CLK=y. One possible fix is to add the Kconfig
    dependency, but since we plan to move away from the clock dependency
    for scmi cpufreq, it is preferrable to avoid that.

    Let us just conditionally compile out the offending call to
    devm_of_clk_add_hw_provider. It also uses the variable 'dev' outside
    of the #ifdef block to avoid build warning.

    Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider")
    Cc: Rafael J. Wysocki
    Cc: Viresh Kumar
    Signed-off-by: Sudeep Holla
    Signed-off-by: Viresh Kumar

    Sudeep Holla
     

20 Nov, 2020

1 commit


17 Nov, 2020

3 commits

  • Pull cpufreq-arm fixes for 5.10-rc5 from Viresh Kumar:

    "- tegra186: Fix ->get() callback.
    - arm/scmi: Add dummy clock provider to fix failure."

    * 'cpufreq/arm/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
    cpufreq: scmi: Fix OPP addition failure with a dummy clock provider
    cpufreq: tegra186: Fix get frequency callback

    Rafael J. Wysocki
     
  • Commit dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return
    -EPROBE_DEFER") handles -EPROBE_DEFER for the clock/interconnects within
    _allocate_opp_table() which is called from dev_pm_opp_add and it
    now propagates the error back to the caller.

    SCMI performance domain re-used clock bindings to keep it simple. However
    with the above mentioned change, if clock property is present in a device
    node, opps fails to get added with below errors until clk_get succeeds.

    cpu0: failed to add opp 450000000Hz
    cpu0: failed to add opps to the device
    ....(errors on cpu1-cpu4)
    cpu5: failed to add opp 450000000Hz
    cpu5: failed to add opps to the device

    So, in order to fix the issue, we need to register dummy clock provider.
    With the dummy clock provider, clk_get returns NULL(no errors!), then opp
    core proceeds to add OPPs for the CPUs.

    Cc: Rafael J. Wysocki
    Fixes: dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER")
    Signed-off-by: Sudeep Holla
    Signed-off-by: Viresh Kumar

    Sudeep Holla
     
  • Commit b89c01c96051 ("cpufreq: tegra186: Fix initial frequency")
    implemented the CPUFREQ 'get' callback to determine the current
    operating frequency for each CPU. This implementation used a simple
    looked up to determine the current operating frequency. The problem
    with this is that frequency table for different Tegra186 devices may
    vary and so the default boot frequency for Tegra186 device may or may
    not be present in the frequency table. If the default boot frequency is
    not present in the frequency table, this causes the function
    tegra186_cpufreq_get() to return 0 and in turn causes cpufreq_online()
    to fail which prevents CPUFREQ from working.

    Fix this by always calculating the CPU frequency based upon the current
    'ndiv' setting for the CPU. Note that the CPU frequency for Tegra186 is
    calculated by reading the current 'ndiv' setting, multiplying by the
    CPU reference clock and dividing by a constant divisor.

    Fixes: b89c01c96051 ("cpufreq: tegra186: Fix initial frequency")

    Signed-off-by: Jon Hunter
    Signed-off-by: Viresh Kumar

    Jon Hunter
     

13 Nov, 2020

1 commit


11 Nov, 2020

4 commits

  • Make intel_pstate take the new CPUFREQ_GOV_STRICT_TARGET governor
    flag into account when it operates in the passive mode with HWP
    enabled, so as to fix the "powersave" governor behavior in that
    case (currently, HWP is allowed to scale the performance all the
    way up to the policy max limit when the "powersave" governor is
    used, but it should be constrained to the policy min limit then).

    Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled")
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar
    Cc: 5.9+ # 5.9+: 9a2a9ebc0a75 cpufreq: Introduce governor flags
    Cc: 5.9+ # 5.9+: 218f66870181 cpufreq: Introduce CPUFREQ_GOV_STRICT_TARGET
    Cc: 5.9+ # 5.9+: ea9364bbadf1 cpufreq: Add strict_target to struct cpufreq_policy

    Rafael J. Wysocki
     
  • Add a new field to be set when the CPUFREQ_GOV_STRICT_TARGET flag is
    set for the current governor to struct cpufreq_policy, so that the
    drivers needing to check CPUFREQ_GOV_STRICT_TARGET do not have to
    access the governor object during every frequency transition.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar

    Rafael J. Wysocki
     
  • Introduce a new governor flag, CPUFREQ_GOV_STRICT_TARGET, for the
    governors that want the target frequency to be set exactly to the
    given value without leaving any room for adjustments on the hardware
    side and set this flag for the powersave and performance governors.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar

    Rafael J. Wysocki
     
  • A new cpufreq governor flag will be added subsequently, so replace
    the bool dynamic_switching fleid in struct cpufreq_governor with a
    flags field and introduce CPUFREQ_GOV_DYNAMIC_SWITCHING to set for
    the "dynamic switching" governors instead of it.

    No intentional functional impact.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar

    Rafael J. Wysocki
     

02 Nov, 2020

1 commit


29 Oct, 2020

2 commits


28 Oct, 2020

4 commits

  • If the cpufreq policy max limit is changed when intel_pstate operates
    in the passive mode with HWP enabled and the "powersave" governor is
    used on top of it, the HWP max limit is not updated as appropriate.

    Namely, in the "powersave" governor case, the target P-state
    is always equal to the policy min limit, so if the latter does
    not change, intel_cpufreq_adjust_hwp() is not invoked to update
    the HWP Request MSR due to the "target_pstate != old_pstate" check
    in intel_cpufreq_update_pstate(), so the HWP max limit is not
    updated as a result.

    Also, if the CPUFREQ_NEED_UPDATE_LIMITS flag is not set for the
    driver and the target frequency does not change along with the
    policy max limit, the "target_freq == policy->cur" check in
    __cpufreq_driver_target() prevents the driver's ->target() callback
    from being invoked at all, so the HWP max limit is not updated.

    To prevent that occurring, set the CPUFREQ_NEED_UPDATE_LIMITS flag
    in the intel_cpufreq driver structure if HWP is enabled and modify
    intel_cpufreq_update_pstate() to do the "target_pstate != old_pstate"
    check only in the non-HWP case and let intel_cpufreq_adjust_hwp()
    always run in the HWP case (it will update HWP Request only if the
    cached value of the register is different from the new one including
    the limits, so if neither the target P-state value nor the max limit
    changes, the register write will still be avoided).

    Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled")
    Reported-by: Zhang Rui
    Cc: 5.9+ # 5.9+: 1c534352f47f cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS ...
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar
    Tested-by: Zhang Rui

    Rafael J. Wysocki
     
  • Generally, a cpufreq driver may need to update some internal upper
    and lower frequency boundaries on policy max and min changes,
    respectively, but currently this does not work if the target
    frequency does not change along with the policy limit.

    Namely, if the target frequency does not change along with the
    policy min or max, the "target_freq == policy->cur" check in
    __cpufreq_driver_target() prevents driver callbacks from being
    invoked and they do not even have a chance to update the
    corresponding internal boundary.

    This particularly affects the "powersave" and "performance"
    governors that always set the target frequency to one of the
    policy limits and it never changes when the other limit is updated.

    To allow cpufreq the drivers needing to update internal frequency
    boundaries on policy limits changes to avoid this issue, introduce
    a new driver flag, CPUFREQ_NEED_UPDATE_LIMITS, that (when set) will
    neutralize the check mentioned above.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar

    Rafael J. Wysocki
     
  • Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by
    default without HWP") was meant to cause intel_pstate to be used
    in the passive mode with the schedutil governor on top of it, but
    it missed the case in which either "ondemand" or "conservative"
    was selected as the default governor in the existing kernel config,
    in which case the previous old governor configuration would be used,
    causing the default legacy governor to be used on top of intel_pstate
    instead of schedutil.

    Address this by preventing "ondemand" and "conservative" from being
    configured as the default cpufreq governor in the case when schedutil
    is the default choice for the default governor setting.

    [Note that the default cpufreq governor can still be set via the
    kernel command line if need be and that choice is not limited,
    so if anyone really wants to use one of the legacy governors by
    default, it can be achieved this way.]

    Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP")
    Reported-by: Julia Lawall
    Cc: 5.8+ # 5.8+
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar

    Rafael J. Wysocki
     
  • A 'break' following a 'return' statement is pointless, so remove it.

    Signed-off-by: Zhang Qilong
    Acked-by: Viresh Kumar
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki

    Zhang Qilong
     

27 Oct, 2020

3 commits


26 Oct, 2020

1 commit


25 Oct, 2020

3 commits

  • …g/pub/scm/linux/kernel/git/konrad/swiotlb") into android-mainline

    Resolves merge issues with:
    drivers/cpufreq/cpufreq.c

    Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
    Change-Id: Ic2907cf71867dab7b8e1b5fcbd4c888fc01f8c22

    Greg Kroah-Hartman
     
  • Pull ARM SoC-related driver updates from Olof Johansson:
    "Various driver updates for platforms. A bulk of this is smaller fixes
    or cleanups, but some of the new material this time around is:

    - Support for Nvidia Tegra234 SoC

    - Ring accelerator support for TI AM65x

    - PRUSS driver for TI platforms

    - Renesas support for R-Car V3U SoC

    - Reset support for Cortex-M4 processor on i.MX8MQ

    There are also new socinfo entries for a handful of different SoCs and
    platforms"

    * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (131 commits)
    drm/mediatek: reduce clear event
    soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
    soc: mediatek: cmdq: add jump function
    soc: mediatek: cmdq: add write_s_mask value function
    soc: mediatek: cmdq: add write_s value function
    soc: mediatek: cmdq: add read_s function
    soc: mediatek: cmdq: add write_s_mask function
    soc: mediatek: cmdq: add write_s function
    soc: mediatek: cmdq: add address shift in jump
    soc: mediatek: mtk-infracfg: Fix kerneldoc
    soc: amlogic: pm-domains: use always-on flag
    reset: sti: reset-syscfg: fix struct description warnings
    reset: imx7: add the cm4 reset for i.MX8MQ
    dt-bindings: reset: imx8mq: add m4 reset
    reset: Fix and extend kerneldoc
    reset: reset-zynqmp: Added support for Versal platform
    dt-bindings: reset: Updated binding for Versal reset driver
    reset: imx7: Support module build
    soc: fsl: qe: Remove unnessesary check in ucc_set_tdm_rxtx_clk
    soc: fsl: qman: convert to use be32_add_cpu()
    ...

    Linus Torvalds
     
  • Pull ARM SoC platform updates from Olof Johansson:
    "SoC changes, a substantial part of this is cleanup of some of the
    older platforms that used to have a bunch of board files.

    In particular:

    - Remove non-DT i.MX platforms that haven't seen activity in years,
    it's time to remove them.

    - A bunch of cleanup and removal of platform data for TI/OMAP
    platforms, moving over to genpd for power/reset control (yay!)

    - Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them
    closer to multiplatform support (not quite there yet, but getting
    close).

    There are a few other changes too, smaller fixlets, etc. For new
    platform support, the primary ones are:

    - New SoC: Hisilicon SD5203, ARM926EJ-S platform.

    - Cpufreq support for i.MX7ULP"

    * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits)
    ARM: mstar: Select MStar intc
    ARM: stm32: Replace HTTP links with HTTPS ones
    ARM: debug: add UART early console support for SD5203
    ARM: hisi: add support for SD5203 SoC
    ARM: omap3: enable off mode automatically
    clk: imx: imx35: Remove mx35_clocks_init()
    clk: imx: imx31: Remove mx31_clocks_init()
    clk: imx: imx27: Remove mx27_clocks_init()
    ARM: imx: Remove unused definitions
    ARM: imx35: Retrieve the IIM base address from devicetree
    ARM: imx3: Retrieve the AVIC base address from devicetree
    ARM: imx3: Retrieve the CCM base address from devicetree
    ARM: imx31: Retrieve the IIM base address from devicetree
    ARM: imx27: Retrieve the CCM base address from devicetree
    ARM: imx27: Retrieve the SYSCTRL base address from devicetree
    ARM: s3c64xx: bring back notes from removed debug-macro.S
    ARM: s3c24xx: fix Wunused-variable warning on !MMU
    ARM: samsung: fix PM debug build with DEBUG_LL but !MMU
    MAINTAINERS: mark linux-samsung-soc list non-moderated
    ARM: imx: Remove remnant board file support pieces
    ...

    Linus Torvalds
     

24 Oct, 2020

1 commit

  • Pull more power management updates from Rafael Wysocki:
    "First of all, the adaptive voltage scaling (AVS) drivers go to new
    platform-specific locations as planned (this part was reported to have
    merge conflicts against the new arm-soc updates in linux-next).

    In addition to that, there are some fixes (intel_idle, intel_pstate,
    RAPL, acpi_cpufreq), the addition of on/off notifiers and idle state
    accounting support to the generic power domains (genpd) code and some
    janitorial changes all over.

    Specifics:

    - Move the AVS drivers to new platform-specific locations and get rid
    of the drivers/power/avs directory (Ulf Hansson).

    - Add on/off notifiers and idle state accounting support to the
    generic power domains (genpd) framework (Ulf Hansson, Lina Iyer).

    - Ulf will maintain the PM domain part of cpuidle-psci (Ulf Hansson).

    - Make intel_idle disregard ACPI _CST if it cannot use the data
    returned by that method (Mel Gorman).

    - Modify intel_pstate to avoid leaving useless sysfs directory
    structure behind if it cannot be registered (Chen Yu).

    - Fix domain detection in the RAPL power capping driver and prevent
    it from failing to enumerate the Psys RAPL domain (Zhang Rui).

    - Allow acpi-cpufreq to use ACPI _PSD information with Family 19 and
    later AMD chips (Wei Huang).

    - Update the driver assumptions comment in intel_idle and fix a
    kerneldoc comment in the runtime PM framework (Alexander Monakov,
    Bean Huo).

    - Avoid unnecessary resets of the cached frequency in the schedutil
    cpufreq governor to reduce overhead (Wei Wang).

    - Clean up the cpufreq core a bit (Viresh Kumar).

    - Make assorted minor janitorial changes (Daniel Lezcano, Geert
    Uytterhoeven, Hubert Jasudowicz, Tom Rix).

    - Clean up and optimize the cpupower utility somewhat (Colin Ian
    King, Martin Kaistra)"

    * tag 'pm-5.10-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits)
    PM: sleep: remove unreachable break
    PM: AVS: Drop the avs directory and the corresponding Kconfig
    PM: AVS: qcom-cpr: Move the driver to the qcom specific drivers
    PM: runtime: Fix typo in pm_runtime_set_active() helper comment
    PM: domains: Fix build error for genpd notifiers
    powercap: Fix typo in Kconfig "Plance" -> "Plane"
    cpufreq: schedutil: restore cached freq when next_f is not changed
    acpi-cpufreq: Honor _PSD table setting on new AMD CPUs
    PM: AVS: smartreflex Move driver to soc specific drivers
    PM: AVS: rockchip-io: Move the driver to the rockchip specific drivers
    PM: domains: enable domain idle state accounting
    PM: domains: Add curly braces to delimit comment + statement block
    PM: domains: Add support for PM domain on/off notifiers for genpd
    powercap/intel_rapl: enumerate Psys RAPL domain together with package RAPL domain
    powercap/intel_rapl: Fix domain detection
    intel_idle: Ignore _CST if control cannot be taken from the platform
    cpuidle: Remove pointless stub
    intel_idle: mention assumption that WBINVD is not needed
    MAINTAINERS: Add section for cpuidle-psci PM domain
    cpufreq: intel_pstate: Delete intel_pstate sysfs if failed to register the driver
    ...

    Linus Torvalds
     

19 Oct, 2020

1 commit

  • acpi-cpufreq has a old quirk that overrides the _PSD table supplied by
    BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+)
    now accurately reports the P-state dependency of CPU cores. Hence this
    quirk needs to be fixed in order to support new CPUs' frequency control.

    Fixes: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs")
    Signed-off-by: Wei Huang
    [ rjw: Subject edit ]
    Cc: 3.10+ # 3.10+
    Signed-off-by: Rafael J. Wysocki

    Wei Huang
     

17 Oct, 2020

1 commit

  • Pull powerpc updates from Michael Ellerman:

    - A series from Nick adding ARCH_WANT_IRQS_OFF_ACTIVATE_MM & selecting
    it for powerpc, as well as a related fix for sparc.

    - Remove support for PowerPC 601.

    - Some fixes for watchpoints & addition of a new ptrace flag for
    detecting ISA v3.1 (Power10) watchpoint features.

    - A fix for kernels using 4K pages and the hash MMU on bare metal
    Power9 systems with > 16TB of RAM, or RAM on the 2nd node.

    - A basic idle driver for shallow stop states on Power10.

    - Tweaks to our sched domains code to better inform the scheduler about
    the hardware topology on Power9/10, where two SMT4 cores can be
    presented by firmware as an SMT8 core.

    - A series doing further reworks & cleanups of our EEH code.

    - Addition of a filter for RTAS (firmware) calls done via sys_rtas(),
    to prevent root from overwriting kernel memory.

    - Other smaller features, fixes & cleanups.

    Thanks to: Alexey Kardashevskiy, Andrew Donnellan, Aneesh Kumar K.V,
    Athira Rajeev, Biwen Li, Cameron Berkenpas, Cédric Le Goater, Christophe
    Leroy, Christoph Hellwig, Colin Ian King, Daniel Axtens, David Dai, Finn
    Thain, Frederic Barrat, Gautham R. Shenoy, Greg Kurz, Gustavo Romero,
    Ira Weiny, Jason Yan, Joel Stanley, Jordan Niethe, Kajol Jain, Konrad
    Rzeszutek Wilk, Laurent Dufour, Leonardo Bras, Liu Shixin, Luca
    Ceresoli, Madhavan Srinivasan, Mahesh Salgaonkar, Nathan Lynch, Nicholas
    Mc Guire, Nicholas Piggin, Nick Desaulniers, Oliver O'Halloran, Pedro
    Miraglia Franco de Carvalho, Pratik Rajesh Sampat, Qian Cai, Qinglang
    Miao, Ravi Bangoria, Russell Currey, Satheesh Rajendran, Scott Cheloha,
    Segher Boessenkool, Srikar Dronamraju, Stan Johnson, Stephen Kitt,
    Stephen Rothwell, Thiago Jung Bauermann, Tyrel Datwyler, Vaibhav Jain,
    Vaidyanathan Srinivasan, Vasant Hegde, Wang Wensheng, Wolfram Sang, Yang
    Yingliang, zhengbin.

    * tag 'powerpc-5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (228 commits)
    Revert "powerpc/pci: unmap legacy INTx interrupts when a PHB is removed"
    selftests/powerpc: Fix eeh-basic.sh exit codes
    cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier
    powerpc/time: Make get_tb() common to PPC32 and PPC64
    powerpc/time: Make get_tbl() common to PPC32 and PPC64
    powerpc/time: Remove get_tbu()
    powerpc/time: Avoid using get_tbl() and get_tbu() internally
    powerpc/time: Make mftb() common to PPC32 and PPC64
    powerpc/time: Rename mftbl() to mftb()
    powerpc/32s: Remove #ifdef CONFIG_PPC_BOOK3S_32 in head_book3s_32.S
    powerpc/32s: Rename head_32.S to head_book3s_32.S
    powerpc/32s: Setup the early hash table at all time.
    powerpc/time: Remove ifdef in get_dec() and set_dec()
    powerpc: Remove get_tb_or_rtc()
    powerpc: Remove __USE_RTC()
    powerpc: Tidy up a bit after removal of PowerPC 601.
    powerpc: Remove support for PowerPC 601
    powerpc: Remove PowerPC 601
    powerpc: Drop SYNC_601() ISYNC_601() and SYNC()
    powerpc: Remove CONFIG_PPC601_SYNC_FIX
    ...

    Linus Torvalds
     

16 Oct, 2020

2 commits

  • There is a corner case that if the intel_pstate driver fails to be
    registered (might be due to invalid MSR access) and acpi_cpufreq
    takse over, the intel_pstate sysfs interface is still populated
    which may confuse user space (turbostat for example):

    grep . /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
    acpi-cpufreq

    grep . /sys/devices/system/cpu/intel_pstate/*
    /sys/devices/system/cpu/intel_pstate/max_perf_pct:0
    /sys/devices/system/cpu/intel_pstate/min_perf_pct:0
    grep: /sys/devices/system/cpu/intel_pstate/no_turbo: Resource temporarily unavailable
    grep: /sys/devices/system/cpu/intel_pstate/num_pstates: Resource temporarily unavailable
    /sys/devices/system/cpu/intel_pstate/status:off
    grep: /sys/devices/system/cpu/intel_pstate/turbo_pct: Resource temporarily unavailable

    The mere presence of the intel_pstate sysfs interface does not mean
    that intel_pstate is in use (for example, echo "off" to "status"),
    but it should not be created in the failing case.

    Fix this issue by deleting the intel_pstate sysfs if the driver
    registration fails.

    Reported-by: Wendy Wang
    Suggested-by: Zhang Rui
    Signed-off-by: Chen Yu
    Acked-by: Srinivas Pandruvada

    Chen Yu
     
  • The cpufreq core checks if the frequency programmed by the bootloaders
    is not listed in the freq table and programs one from the table in such
    a case. This is done only if the driver has set the
    CPUFREQ_NEED_INITIAL_FREQ_CHECK flag.

    Currently we print two separate messages, with almost the same content,
    and do this with a pr_warn() which may be a bit too much as the driver
    only asked us to check this as it expected this to be the case. Lower
    down the severity of the print message by switching to pr_info() instead
    and print a single message only.

    Reported-by: Sumit Gupta
    Signed-off-by: Viresh Kumar
    Reviewed-by: Sumit Gupta
    Tested-by: Sumit Gupta
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

12 Oct, 2020

1 commit

  • Fix following warning:

    drivers/cpufreq/cpufreq_stats.c:63:10: warning: %d in format string (no.
    1) requires 'int' but the argument type is 'unsigned int'

    Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()")
    Reported-by: kernel test robot
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

08 Oct, 2020

2 commits

  • Compared to other arch_* functions, arch_set_freq_scale() has an atypical
    weak definition that can be replaced by a strong architecture specific
    implementation.

    The more typical support for architectural functions involves defining
    an empty stub in a header file if the symbol is not already defined in
    architecture code. Some examples involve:
    - #define arch_scale_freq_capacity topology_get_freq_scale
    - #define arch_scale_freq_invariant topology_scale_freq_invariant
    - #define arch_scale_cpu_capacity topology_get_cpu_scale
    - #define arch_update_cpu_topology topology_update_cpu_topology
    - #define arch_scale_thermal_pressure topology_get_thermal_pressure
    - #define arch_set_thermal_pressure topology_set_thermal_pressure

    Bring arch_set_freq_scale() in line with these functions by renaming it to
    topology_set_freq_scale() in the arch topology driver, and by defining the
    arch_set_freq_scale symbol to point to the new function for arm and arm64.

    While there are other users of the arch_topology driver, this patch defines
    arch_set_freq_scale for arm and arm64 only, due to their existing
    definitions of arch_scale_freq_capacity. This is the getter function of the
    frequency invariance scale factor and without a getter function, the
    setter function - arch_set_freq_scale() has not purpose.

    Signed-off-by: Ionela Voinescu
    Acked-by: Viresh Kumar
    Acked-by: Catalin Marinas
    Acked-by: Sudeep Holla (BL_SWITCHER and topology parts)
    Signed-off-by: Rafael J. Wysocki

    Ionela Voinescu
     
  • The patch avoids allocating cpufreq_policy on stack hence fixing frame
    size overflow in 'powernv_cpufreq_reboot_notifier':

    drivers/cpufreq/powernv-cpufreq.c: In function powernv_cpufreq_reboot_notifier:
    drivers/cpufreq/powernv-cpufreq.c:906:1: error: the frame size of 2064 bytes is larger than 2048 bytes

    Fixes: cf30af76 ("cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec")
    Signed-off-by: Srikar Dronamraju
    Reviewed-by: Daniel Axtens
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20200922080254.41497-1-srikar@linux.vnet.ibm.com

    Srikar Dronamraju
     

07 Oct, 2020

1 commit

  • There is nothing to prevent the CPU or the compiler from reordering
    the writes to stats->reset_time and stats->reset_pending in
    store_reset(), in which case the readers of stats->reset_time may see
    a stale value. Moreover, on 32-bit arches the write to reset_time
    cannot be completed in one go, so the readers of it may see a
    partially updated value in that case.

    To prevent that from happening, add a write memory barrier between
    the writes to stats->reset_time and stats->reset_pending in
    store_reset() and corresponding read memory barrier in the
    readers of stats->reset_time.

    Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()")
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar

    Rafael J. Wysocki
     

06 Oct, 2020

2 commits

  • Pull ARM cpufreq updates for 5.10-rc1 from Viresh Kumar:

    "- STI cpufreq driver updates to allow new hardware (Alain Volmat).

    - Minor tegra driver fixes around initial frequency mismatch warnings (Jon
    Hunter).

    - dev_err simplification for s5pv210 driver (Krzysztof Kozlowski).

    - Qcom driver updates to allow new hardware and minor cleanup (Manivannan
    Sadhasivam and Matthias Kaehlcke).

    - Add missing MODULE_DEVICE_TABLE for armada driver (Pali Rohár).

    - Improved defer-probe handling in cpufreq-dt driver (Stephan Gerhold).

    - Call dev_pm_opp_of_remove_table() unconditionally for imx driver (Viresh
    Kumar)."

    * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
    cpufreq: qcom: Don't add frequencies without an OPP
    cpufreq: qcom-hw: Add cpufreq support for SM8250 SoC
    cpufreq: qcom-hw: Use of_device_get_match_data for offsets and row size
    cpufreq: qcom-hw: Use devm_platform_ioremap_resource() to simplify code
    dt-bindings: cpufreq: cpufreq-qcom-hw: Document Qcom EPSS compatible
    cpufreq: qcom-hw: Make use of cpufreq driver_data for passing pdev
    cpufreq: armada-37xx: Add missing MODULE_DEVICE_TABLE
    cpufreq: arm: Kconfig: add CPUFREQ_DT depend for STI CPUFREQ
    cpufreq: dt-platdev: Blacklist st,stih418 SoC
    cpufreq: sti-cpufreq: add stih418 support
    cpufreq: s5pv210: Use dev_err instead of pr_err in probe
    cpufreq: s5pv210: Simplify with dev_err_probe()
    cpufreq: tegra186: Fix initial frequency
    cpufreq: dt: Refactor initialization to handle probe deferral properly
    opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1()
    cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table()
    opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER

    Rafael J. Wysocki
     
  • Linux 5.9-rc8

    Signed-off-by: Greg Kroah-Hartman
    Change-Id: I4a03857522443f5d032a0cc1ecdced3675255d5e

    Greg Kroah-Hartman
     

05 Oct, 2020

2 commits