From: 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
From: Rafael J. Wysocki
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
On Tue, Nov 10, 2020 at 12:07 PM Viresh Kumar wrote:
>
> The cpufreq and thermal core, both provide sysfs statistics to help
> userspace learn about the behavior of frequencies and cooling states.
>
> This is how they look:
>
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:208000 11
On Tue, Nov 10, 2020 at 1:39 PM Heikki Krogerus
wrote:
>
> On Mon, Nov 09, 2020 at 09:05:51PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 09, 2020 at 10:53:05AM -0800, Dmitry Torokhov wrote:
> > > On Mon, Nov 09, 2020 at 07:18:37PM +0100, Lukasz Stelmach wrote:
> > > > It was <2020-11-09 pon 19:
On Tue, Nov 10, 2020 at 3:35 AM Viresh Kumar wrote:
>
> On 09-11-20, 15:18, Rafael J. Wysocki wrote:
> > On Tue, Nov 3, 2020 at 4:14 PM Pali Rohár wrote:
> > >
> > > Some of cpufreq drivers are tristate, can be compiled as modules, but do
> > > not have
On Tue, Nov 10, 2020 at 3:47 AM Viresh Kumar wrote:
>
> On 09-11-20, 17:53, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Add a new field to be set when the CPUFREQ_GOV_FLAG_STRICT_TARGET
> > flag is set for the current governor to struct cpufreq_p
On Tue, Nov 10, 2020 at 3:41 AM Viresh Kumar wrote:
>
> On 09-11-20, 17:51, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > A new cpufreq governor flag will be added subsequently, so replace
> > the bool dynamic_switching fleid in struct cpufreq_gover
On Sat, Nov 7, 2020 at 9:49 AM Nick Desaulniers wrote:
>
> Clang is more aggressive about -Wformat warnings when the format flag
> specifies a type smaller than the parameter. It turns out that gsi is an
> int. Fixes:
>
> drivers/acpi/evged.c:105:48: warning: format specifies type 'unsigned
> char
On Thu, Nov 5, 2020 at 3:06 AM Maximilian Luz wrote:
>
> Replaces spaces with tabs where spaces have been (inconsistently) used
> for indentation and removes trailing whitespaces.
>
> Signed-off-by: Maximilian Luz
> ---
>
> Was previously: ACPI: Remove trailing whitespace
>
> Changes in v2:
> -
On Mon, Nov 2, 2020 at 12:23 PM John Garry wrote:
>
> For some reason building with W=1 doesn't pick up on this, but the
> kerneldoc name for acpi_dma_configure_id() is not right, so fix it up.
>
> Signed-off-by: John Garry
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index a896e5
From: Rafael J. Wysocki
Introduce a new governor flag, CPUFREQ_GOV_FLAG_STRICT_TARGET, for
the govenors 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
From: 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_FLAG_DYN_SWITCH to set for
the "dynamic switching" governors instead of it.
No i
From: Rafael J. Wysocki
Add a new field to be set when the CPUFREQ_GOV_FLAG_STRICT_TARGET
flag is set for the current governor to struct cpufreq_policy, so
that the drivers needing to check CPUFREQ_GOV_FLAG_STRICT_TARGET do
not have to access the governor object during every frequency
transition
From: Rafael J. Wysocki
Make intel_pstate take the new CPUFREQ_GOV_FLAG_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
Hi,
Even after the changes made very recently, the handling of the powersave
governor is not exactly as expected when intel_pstate operates in the
"passive" mode with HWP enabled.
Namely, in that case HWP is not limited to the policy min frequency, but it
can scale the frequency up to the policy
On Tue, Nov 3, 2020 at 4:14 PM Pali Rohár wrote:
>
> Some of cpufreq drivers are tristate, can be compiled as modules, but do
> not have defined modalias for automatic loading. This patch series add
> for all those cpufreq drivers missing MODULE_DEVICE_TABLE macro, based
> on OF definitions, or MO
On Mon, Nov 9, 2020 at 5:39 AM Viresh Kumar wrote:
>
> On 06-11-20, 18:02, Rafael J. Wysocki wrote:
> > On Fri, Nov 6, 2020 at 11:07 AM Viresh Kumar
> > wrote:
> > >
> > > On 05-11-20, 19:23, Rafael J. Wysocki wrote:
> > &
On Fri, Nov 6, 2020 at 11:07 AM Viresh Kumar wrote:
>
> On 05-11-20, 19:23, Rafael J. Wysocki wrote:
> > Index: linux-pm/include/linux/cpufreq.h
> > ===
> > --- linux-pm.orig/include/linux/cpufreq.h
> &
n that disables page poison sanity checking when hibernation
> is enabled.
>
> Signed-off-by: Vlastimil Babka
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Pavel Machek
> Cc:
Acked-by: Rafael J. Wysocki
for the hibernation part and I'm assuming that this
Hi,
Even after the changes made very recently, the handling of the powersave
governor is not exactly as expected when intel_pstate operates in the
"passive" mode with HWP enabled.
Namely, in that case HWP is not limited to the policy min frequency, but it
can scale the frequency up to the policy
From: Rafael J. Wysocki
Make the intel_pstate driver take the new target_min and target_max
cpufreq policy parameters into accout 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 p
From: Rafael J. Wysocki
Some cpufreq drivers, like intel_pstate (in the passive mode with
HWP enabled) or the CPPC driver, take the "target frequency" coming
from the governor as a hint to pass to the hardware rather than the
exact value to apply. Then, the hardware may choose
On Thursday, November 5, 2020 6:14:01 PM CET Srinivas Pandruvada wrote:
> On Thu, 2020-11-05 at 14:53 +1100, Victor Ding wrote:
> > On Wed, Nov 4, 2020 at 1:17 PM Srinivas Pandruvada
> > wrote:
> > > On Wed, 2020-11-04 at 12:43 +1100, Victor Ding wrote:
> > > > On Wed, Nov 4, 2020 at 4:09 AM Srini
On Thursday, November 5, 2020 4:08:30 PM CET Mike Galbraith wrote:
> On Thu, 2020-11-05 at 15:31 +0100, Rafael J. Wysocki wrote:
> > On Monday, November 2, 2020 7:18:41 AM CET Mike Galbraith wrote:
> >
> > > Desktop box did, it gained a working ondemand, while its
On Thu, Oct 8, 2020 at 3:08 AM Stanimir Varbanov
wrote:
>
> Hi Rafael,
>
> On 10/7/20 5:37 PM, Rafael J. Wysocki wrote:
> > On Wed, Oct 7, 2020 at 2:20 AM Stanimir Varbanov
> > wrote:
> >>
> >> Calling pm_runtime_put_sync over a device with suppli
On Thursday, November 5, 2020 3:02:02 PM CET Ionela Voinescu wrote:
> Hi Rafael,
>
> On Thursday 05 Nov 2020 at 14:05:55 (+0100), Rafael J. Wysocki wrote:
> > On Thu, Nov 5, 2020 at 1:57 PM Ionela Voinescu
> > wrote:
> > >
> > > For errors parsing the _PSD
On Monday, November 2, 2020 7:18:41 AM CET Mike Galbraith wrote:
> On Sun, 2020-11-01 at 17:23 +0100, Mike Galbraith wrote:
> > Greetings,
> >
> > As you can see in the data below, my i4790 box used to default to the
> > powersave governor despite CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y, and
> > dis
ulia Lawall (2):
Documentation: PM: cpuidle: correct typo
Documentation: PM: cpuidle: correct path name
Rafael J. Wysocki (3):
PM: runtime: Drop runtime PM references to supplier on link removal
PM: runtime: Drop pm_runtime_clean_up_links()
PM: runtime: Resume the d
On Fri, Oct 16, 2020 at 10:31 PM Daniel Lezcano
wrote:
>
>
> Hi Rafael,
>
> On 16/10/2020 17:24, Rafael J. Wysocki wrote:
> > On Thu, Oct 15, 2020 at 4:44 PM Daniel Lezcano
> > wrote:
> >>
> >> The cpuidle.h header is declaring functions with a
On Thu, Oct 15, 2020 at 4:45 PM Daniel Lezcano
wrote:
>
> In the next patch, the governors will be converted to modules. Export
> the symbols of the different functions used by the governors.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/cpuidle/governor.c | 3 +++
> include/linux/tick.h
h functions return domains with a single CPU, this change
> does not affect the functionality, but clarifies the intention.
Is this related to any other patches in the series?
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Len Brown
> Cc: Viresh Kumar
> ---
&g
On Wed, Nov 4, 2020 at 6:13 PM Joe Perches wrote:
>
> On Wed, 2020-11-04 at 16:48 +0100, Maximilian Luz wrote:
> > On 11/4/20 6:13 AM, Joe Perches wrote:
> >
> > [...]
> >
> > > > Yes. I scanned drivers/acpi for trailing whitespaces after I noticed a
> > > > couple of them. I did not explicitly sc
ne.
Feel free to add
Reviewed-by: Rafael J. Wysocki
to all of the patches in it.
Thanks!
> Changelog v2:
> - rebased on top of v5.10-rc1
> - dependency-free (they are in v5.10-rc1)
> - added Ack (Mark)
>
> Andy Shevchenko (5):
> irqdomain: Remove unused of_device_id forw
On Sun, Nov 1, 2020 at 3:11 PM wrote:
>
> From: Tom Rix
>
> A semicolon is not needed after a switch statement.
>
> Signed-off-by: Tom Rix
> ---
> drivers/powercap/intel_rapl_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/powercap/intel_rapl_common.c
On Sat, Oct 31, 2020 at 11:23 AM Julia Lawall wrote:
>
> cpu/ is needed before cpu/
>
> Signed-off-by: Julia Lawall
>
> ---
> Documentation/admin-guide/pm/cpuidle.rst |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/pm/cpuidle.rst
> b/Documen
On Sat, Oct 31, 2020 at 11:23 AM Julia Lawall wrote:
>
> cerainly -> certainly
>
> Signed-off-by: Julia Lawall
>
> ---
> Documentation/admin-guide/pm/cpuidle.rst |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/pm/cpuidle.rst
> b/Documentatio
Hi Greg,
On Wed, Oct 21, 2020 at 9:14 PM Rafael J. Wysocki wrote:
>
> Hi Greg & all,
>
> Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in
> rpm_get/put_supplier()") merged recently introduced a weakness
> in the handling of device links in the ru
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pnp-5.10-rc2
with top-most commit e510785f8aca4a7346497edd4d5aceefe5370960
PNP: fix kernel-doc markups
on top of commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec
Linux 5.10-rc1
to receiv
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
devprop-5.10-rc2
with top-most commit 99aed9227073fb34ce2880cbc7063e04185a65e1
device property: Don't clear secondary pointer for shared primary firmware node
on top of commit 3650b228f83a
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-5.10-rc2
with top-most commit 8f7304bb9113c95b256d3aa79a884b4c60a806e1
Merge branches 'acpi-button' and 'acpi-dock'
on top of commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec
Linux 5
I (Chen Yu).
- Clean up assorted pieces of power management code (Jackie Zamow,
Tom Rix, Zhang Qilong).
Thanks!
---
Chen Yu (1):
intel_idle: Fix max_cstate for processor models without C-state tables
Jackie Zamow (1):
PM: sleep: fix typo in kernel/power/proc
rret
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
For the schedutil part:
Acked-by: Rafael J. Wysocki
and I'm assuming the patch to be taken care of by Peter.
> ---
> include/linux/sched/topology.h | 8
> kernel/sched
On Fri, Oct 30, 2020 at 4:07 PM Rafael J. Wysocki wrote:
>
> On Fri, Oct 30, 2020 at 8:31 AM Viresh Kumar wrote:
> >
> > The cpufreq policy's frequency limits (min/max) can get changed at any
> > point of time, while schedutil is trying to update the next freque
gt;
> We also don't need to consider the need_freq_update flag in
> sugov_update_single() anymore to handle the special case of busy CPU, as
> we won't abort a frequency update anymore.
>
> Reported-by: zhuguangqing
> Suggested-by: Rafael J. Wysocki
Thanks for follow
| 23 +++--
> .../sysfs-devices-platform-stratix10-rsu | 10 ++
> .../ABI/testing/sysfs-driver-w1_therm | 75 ++-
> .../ABI/testing/sysfs-platform-dfl-fme| 14 ++-
> Documentation/ABI/testing/sysfs-platform-dptf | 11 ++-
For the DPTF part
Acked-by:
On Fri, Oct 30, 2020 at 8:42 AM Mauro Carvalho Chehab
wrote:
>
> There are some problems with this file when a ReST content
> is produced. Fix it.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Rafael J. Wysocki
and I assume this to go in via the doc
On Thu, Oct 29, 2020 at 11:59 AM Heikki Krogerus
wrote:
>
> The software node specific PM operations make it possible to
> handle most PM related quirks separately in their own
> functions instead of conditionally in the device driver's
> generic PM functions (and in some cases all over the
> driv
ault,invalid}_noflush().
>
> Still, add a WARN_ON() so that future changes in set_memory APIs will not
> silently break hibernation.
>
> Signed-off-by: Mike Rapoport
>From the hibernation support perspective:
Acked-by: Rafael J. Wysocki
> ---
&
On Thursday, October 29, 2020 8:19:52 AM CET Viresh Kumar wrote:
> Your mail client is screwing the "In-reply-to" field of the message
> and that prevents it to appear properly in the thread in mailboxes of
> other people, please fix that.
>
> On 29-10-20, 09:43, zhuguangqing83 wrote:
> > > diff -
On Thu, Oct 29, 2020 at 12:23 PM Viresh Kumar wrote:
>
> On 29-10-20, 12:12, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Because sugov_update_next_freq() may skip a frequency update even if
> > the need_freq_update flag has been set for the pol
On Thu, Oct 29, 2020 at 2:53 AM Bastien Nocera wrote:
>
> Hey Hans, Mark,
>
> On Tue, 2020-10-27 at 12:42 -0400, Mark Pearson wrote:
> > From: Hans de Goede
> >
> > On modern systems the platform performance, temperature, fan and
> > other
> > hardware related characteristics are often dynamicall
From: Rafael J. Wysocki
Because sugov_update_next_freq() may skip a frequency update even if
the need_freq_update flag has been set for the policy at hand, policy
limits updates may not take effect as expected.
For example, if the intel_pstate driver operates in the passive mode
with HWP
On Thu, Oct 29, 2020 at 12:10 AM Viresh Kumar wrote:
>
> On 27-10-20, 16:35, Rafael J. Wysocki wrote:
> > Index: linux-pm/kernel/sched/cpufreq_schedutil.c
> > ===
> > --- linux-pm.orig/kernel/sched/cpufreq_s
On Tue, Oct 27, 2020 at 8:00 PM wrote:
>
> From: Tom Rix
>
> A semicolon is not needed after a switch statement.
>
> Signed-off-by: Tom Rix
> ---
> drivers/cpufreq/speedstep-lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/speedstep-lib.c b/drivers/
On Mon, Oct 26, 2020 at 10:48 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> gcc points out a type mismatch:
>
> drivers/acpi/dock.c: In function 'hot_remove_dock_devices':
> drivers/acpi/dock.c:234:53: warning: implicit conversion from 'enum
> ' to 'enum dock_callback_type' [-Wenum-convers
On Fri, Oct 23, 2020 at 6:38 PM Mauro Carvalho Chehab
wrote:
>
> It sounds that there were function renames. Update the kernel-doc
> markups accordingly.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/pnp/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Thu, Oct 22, 2020 at 8:41 PM Andy Shevchenko
wrote:
>
> Behind primary and secondary we understand the type of the nodes
> which might define their ordering. However, if primary node gone,
> we can't maintain the ordering by definition of the linked list.
> Thus, by ordering secondary node beco
On Tue, Oct 27, 2020 at 1:43 PM Jackie Zamow wrote:
>
> This patch fixes a typo found in the function freeze_processes()
>
> Signed-off-by: Jackie Zamow
>
> ---
> kernel/power/process.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/power/process.c b/kernel/power
On Sat, Oct 24, 2020 at 6:27 PM Chen Yu wrote:
>
> Currently intel_idle driver gets the c-state information from ACPI
> _CST if the processor model is not recognized by it. However the
> c-state in _CST starts with index 1 which is different from the
> index in intel_idle driver's internal c-state
From: Rafael J. Wysocki
Because sugov_update_next_freq() may skip a frequency update even if
the need_freq_update flag has been set for the policy at hand, policy
limits updates may not take effect as expected.
For example, if the intel_pstate driver operates in the passive mode
with HWP
On Tue, Oct 27, 2020 at 5:26 AM Viresh Kumar wrote:
>
> Spelling mistake in $subject (driver)
>
> On 23-10-20, 17:36, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Because sugov_update_next_freq() may skip a frequency update even if
> > the ne
ver (Alex Hung).
- Drop a few unreachable break statements (Tom Rix).
Thanks!
---
Alex Hung (1):
ACPI: processor: remove comment regarding string _UID support
Jamie Iles (1):
ACPI: debug: don't allow debugging when ACPI is disabled
Rafael J. Wysocki (3):
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-5.10-rc1-2
with top-most commit 41c169d9ae2c890552044e129d101995b62c8a02
Merge branch 'pm-avs'
on top of commit defb53a7c790f9e37a765de8a5d830ed15e2055b
Merge tag 'pnp-5.10-rc1' of
gi
From: Rafael J. Wysocki
Add a helper function to test the flags of the cpufreq driver in use
againt a given flags mask.
In particular, this will be needed to test the
CPUFREQ_NEED_UPDATE_LIMITS cpufreq driver flag in the schedutil
governor.
Signed-off-by: Rafael J. Wysocki
---
New patch in
Hi All,
There is a problem in intel_pstate that if it works in the passive mode with
HWP enabled, changing the policy max frequency may not cause the HWP max limit
to be updated accordingly which is quite confusing and may be incorrect.
That happens because of two checks, one in the cpufreq core
From: 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
From: Rafael J. Wysocki
Because sugov_update_next_freq() may skip a frequency update even if
the need_freq_update flag has been set for the policy at hand, policy
limits updates may not take effect as expected.
For example, if the intel_pstate driver operates in the passive mode
with HWP
From: Rafael J. Wysocki
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, t
From: 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 "c
On Friday, October 23, 2020 5:50:04 AM CEST chenxiang (M) wrote:
> Hi Rafael,
>
> 在 2020/10/22 3:10, Rafael J. Wysocki 写道:
> > Hi Greg & all,
> >
> > Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in
> > rpm_get/put_supplier()") m
On Friday, October 23, 2020 8:12:46 AM CEST Viresh Kumar wrote:
> On 22-10-20, 13:45, Rafael J. Wysocki wrote:
> > On Thursday, October 22, 2020 12:47:03 PM CEST Viresh Kumar wrote:
> > > And I am not really sure why we always wanted this backup performance
> > > gove
On Fri, Oct 23, 2020 at 4:48 PM Sudeep Holla wrote:
>
> On Fri, Oct 23, 2020 at 12:28:20PM +0800, claude yen wrote:
> > On Thu, 2020-10-22 at 08:02 +0100, Sudeep Holla wrote:
> > > On Thu, Oct 22, 2020 at 02:17:48PM +0800, Claude Yen wrote:
> > > > As suspend_set_ops is exported in commit a5e4fd87
On Fri, Oct 23, 2020 at 8:17 AM Viresh Kumar wrote:
>
> On 22-10-20, 18:23, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> > Subject: [PATCH] cpufreq: Avoid configuring old governors as default with
> > intel_pstate
> >
> > Commit 33aa46f252c7 (&quo
On Fri, Oct 23, 2020 at 8:10 AM Viresh Kumar wrote:
>
> On 22-10-20, 13:57, Rafael J. Wysocki wrote:
> > Index: linux-pm/drivers/cpufreq/cpufreq.c
> > ===
> > --- linux-pm.orig/drivers/cpufreq/cpufreq.c
On Thu, Oct 22, 2020 at 6:35 PM Mel Gorman wrote:
>
> On Thu, Oct 22, 2020 at 11:12:00AM -0400, Phil Auld wrote:
> > > > AFAIK, not quite (added Giovanni as he has been paying more attention).
> > > > Schedutil has improved since it was merged but not to the extent where
> > > > it is a drop-in re
On Mon, Oct 19, 2020 at 10:05 PM wrote:
>
> From: Tom Rix
>
> A break is not needed if it is preceded by a return
>
> Signed-off-by: Tom Rix
> ---
> drivers/acpi/utils.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 838b719ec7ce.
On Mon, Oct 19, 2020 at 10:03 PM wrote:
>
> From: Tom Rix
>
> A break is not needed if it is preceded by a return
>
> Signed-off-by: Tom Rix
> ---
> drivers/base/power/main.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 20
From: Rafael J. Wysocki
Subject: [PATCH] cpufreq: Avoid configuring old governors as default with
intel_pstate
Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by
default without HWP") was meant to cause intel_pstate without HWP
to be used in the passive mode with the
On Thu, Oct 22, 2020 at 5:25 PM Peter Zijlstra wrote:
>
> On Thu, Oct 22, 2020 at 03:52:50PM +0100, Mel Gorman wrote:
>
> > There are some questions
> > currently on whether schedutil is good enough when HWP is not available.
>
> Srinivas and Rafael will know better, but Intel does run a lot of te
From: Rafael J. Wysocki
Since the device is resumed from runtime-suspend in
__device_release_driver() anyway, it is better to do that before
looking for busy managed device links from it to consumers, because
if there are any, device_links_unbind_consumers() will be called
and it will cause the
On Thu, Oct 22, 2020 at 3:40 PM chenxiang (M) wrote:
>
> Hi Rafael,
>
> 在 2020/10/22 3:14, Rafael J. Wysocki 写道:
> > From: Rafael J. Wysocki
> >
> > Since the device is resumed from runtime-suspend in
> > __device_release_driver() anyway, it is better to
[CC linux-pm and Len]
On Thursday, October 22, 2020 2:02:13 PM CEST Peter Zijlstra wrote:
> On Thu, Oct 22, 2020 at 01:45:25PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, October 22, 2020 12:47:03 PM CEST Viresh Kumar wrote:
> > > On 22-10-20, 09:11, Peter Zijlstra wrote:
On Thu, Oct 22, 2020 at 1:58 PM Peter Zijlstra wrote:
>
> On Thu, Oct 22, 2020 at 01:30:01PM +0200, Rafael J. Wysocki wrote:
>
> > Many people use intel_pstate in the active mode with HWP enabled too.
>
> We now have HWP-passive supported, afaict. So we should discourage th
From: Rafael J. Wysocki
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, t
Hi All,
There is a problem in intel_pstate that if it works in the passive mode with
HWP enabled and the "powersave" governor is used on top of it, then changing
the policy max frequency doesn't cause the HWP max limit to be updated which
is quite confusing.
That happens because of two checks, on
From: Rafael J. Wysocki
The restore_freq field in struct cpufreq_policy is only used by
__target_index() in one place and a local variable in that function
may as well be used instead of it, so drop it and modify
__target_index() accordingly.
Signed-off-by: Rafael J. Wysocki
---
drivers
On Thursday, October 22, 2020 12:47:03 PM CEST Viresh Kumar wrote:
> On 22-10-20, 09:11, Peter Zijlstra wrote:
> > Well, but we need to do something to force people onto schedutil,
> > otherwise we'll get more crap like this thread.
> >
> > Can we take the choice away? Only let Kconfig select whic
On Thu, Oct 22, 2020 at 1:07 PM Viresh Kumar wrote:
>
> On 22-10-20, 11:05, Peter Zijlstra wrote:
> > On Thu, Oct 22, 2020 at 02:02:55PM +0530, Viresh Kumar wrote:
> > > One of the issues I see with this is that schedutil may not be
> > > available in all configurations and it is still absolutely
On Wednesday, October 21, 2020 9:47:51 PM CEST Julia Lawall wrote:
>
> On Wed, 21 Oct 2020, Rafael J. Wysocki wrote:
>
> > On Wednesday, October 21, 2020 2:42:20 PM CEST Julia Lawall wrote:
> > >
> > > On Wed, 21 Oct 2020, Peter Zijlstra wrote:
> > >
From: Rafael J. Wysocki
After commit d12544fb2aa9 ("PM: runtime: Remove link state checks in
rpm_get/put_supplier()") nothing prevents the consumer device's
runtime PM from acquiring additional references to the supplier
device after pm_runtime_clean_up_links() has run (or e
From: Rafael J. Wysocki
Since the device is resumed from runtime-suspend in
__device_release_driver() anyway, it is better to do that before
looking for busy managed device links from it to consumers, because
if there are any, device_links_unbind_consumers() will be called
and it will cause the
Hi Greg & all,
Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in
rpm_get/put_supplier()") merged recently introduced a weakness
in the handling of device links in the runtime PM framework that
may be confusing and even harmful.
Namely, the checks removed by that commit prevented PM-r
From: Rafael J. Wysocki
While removing a device link, drop the supplier device's runtime PM
usage counter as many times as needed to drop all of the runtime PM
references to it from the consumer in addition to dropping the
consumer's link count.
Fixes: baa8809f6097 ("PM / runtim
On Wednesday, October 21, 2020 12:41:50 PM CEST Ulf Hansson wrote:
> On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki wrote:
> >
> > On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson wrote:
> > >
> > > + Arnd
> > >
> > > On Wed, 7 Oct 2020 at 17:09, Ra
On Wednesday, October 21, 2020 2:52:03 PM CEST Peter Zijlstra wrote:
> On Wed, Oct 21, 2020 at 02:42:20PM +0200, Julia Lawall wrote:
> >
> >
> > On Wed, 21 Oct 2020, Peter Zijlstra wrote:
> >
> > > On Wed, Oct 21, 2020 at 01:56:55PM +0200, Julia Lawall wrote:
> > > > Prior to 5.8, my machine was
On Wednesday, October 21, 2020 2:42:20 PM CEST Julia Lawall wrote:
>
> On Wed, 21 Oct 2020, Peter Zijlstra wrote:
>
> > On Wed, Oct 21, 2020 at 01:56:55PM +0200, Julia Lawall wrote:
> > > Prior to 5.8, my machine was using intel_pstate and had few background
> > > tasks. Thus the problem wasn't
On Wednesday, October 21, 2020 3:10:26 PM CEST Peter Zijlstra wrote:
> On Wed, Oct 21, 2020 at 02:19:50PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 21, 2020 at 01:56:55PM +0200, Julia Lawall wrote:
> > > Prior to 5.8, my machine was using intel_pstate and had few background
> > > tasks. Thus th
On Wed, Oct 21, 2020 at 4:09 AM Joseph Jang wrote:
>
> Since dpm_watchdog just cover device power management, we proposed sleep
> timer to cover not only device power management hang issues, but also
> core power management hand issue.
>
> Add sleep timer and timeout handler to prevent device stuc
On Tue, Oct 20, 2020 at 5:00 PM Bean Huo wrote:
>
> From: Bean Huo
>
> This patch is to fix typo in the comment of helper pm_runtime_set_active().
>
> Signed-off-by: Bean Huo
> ---
> include/linux/pm_runtime.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linu
[Fix the Linus Walleij's address.]
On Tue, Oct 20, 2020 at 12:59 AM Daniel Scally wrote:
>
> Hello all
>
> This series adds support to the ipu3-cio2 driver for fwnode connections
> between cio2 and sensors to be defined via software_nodes. The final patch
> in the series deals wholly with those c
701 - 800 of 10197 matches
Mail list logo
