* [RFCv3 0/8] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations
From: Parth Shah @ 2019-06-25 4:37 UTC (permalink / raw)
To: linux-kernel, linux-pm; +Cc: mingo, peterz, dietmar.eggemann, patrick.bellasi
This is the 3rd version of the patchset to sustain Turbo frequencies for
longer durations.
The previous versions can be found here:
v2: https://lkml.org/lkml/2019/5/15/1258
v1: https://lwn.net/Articles/783959/
The changes in this versions are:
v[2] -> v[3]:
- Added a new attribute in task_struct to allow per task jitter
classification so that scheduler can use this as request to change wakeup
path for task packing
- Use syscall for jitter classification, removed cgroup based task
classification
- Use mutex over spinlock to get rid of task sleeping problem
- Changed _Bool->int everywhere
- Split few patches to have arch specific code separate from core scheduler
code
ToDo:
- Recompute core capacity only during CPU-Hotplug operation
- Remove smt capacity
v[1] -> v[2]:
- No CPU bound tasks' classification, only jitter tasks are classified from
the cpu cgroup controller
- Use of Spinlock rather than mutex to count number of jitters in the
system classified from cgroup
- Architecture specific implementation of Core capacity multiplication
factor changes dynamically based on the number of active threads in the
core
- Selection of non idle core in the system is bounded by DIE domain
- Use of UCLAMP mechanism to classify jitter tasks
- Removed "highutil_cpu_mask", and rather uses sd for DIE domain to find
better fit
Abstract
========
The modern servers allows multiple cores to run at range of frequencies
higher than rated range of frequencies. But the power budget of the system
inhibits sustaining these higher frequencies for longer durations.
However when certain cores are put to idle states, the power can be
effectively channelled to other busy cores, allowing them to sustain the
higher frequency.
One way to achieve this is to pack tasks onto fewer cores keeping others
idle, but it may lead to performance penalty for such tasks and sustaining
higher frequencies proves to be of no benefit. But if one can identify
unimportant low utilization tasks which can be packed on the already active
cores then waking up of new cores can be avoided. Such tasks are short
and/or bursty "jitter tasks" and waking up new core is expensive for such
case.
Current CFS algorithm in kernel scheduler is performance oriented and hence
tries to assign any idle CPU first for the waking up of new tasks. This
policy is perfect for major categories of the workload, but for jitter
tasks, one can save energy by packing them onto the active cores and allow
those cores to run at higher frequencies.
These patch-set tunes the task wake up logic in scheduler to pack
exclusively classified jitter tasks onto busy cores. The work involves the
jitter tasks classifications by using syscall based mechanisms.
In brief, if we can pack jitter tasks on busy cores then we can save power
by keeping other cores idle and allow busier cores to run at turbo
frequencies, patch-set tries to meet this solution in simplest manner.
Though, there are some challenges in implementing it(like smt_capacity,
un-needed arch hooks, etc) and I'm trying to work around that, it would be
great to have a discussion around this patches.
Implementation
==============
These patches uses UCLAMP mechanism[2] used to clamp utilization from the
userspace, which can be used to classify the jitter tasks. The task wakeup
logic uses this information to pack such tasks onto cores which are already
running busy with CPU intensive tasks. The task packing is done at
`select_task_rq_fair` only so that in case of wrong decision load balancer
may pull the classified jitter tasks for maximizing performance.
Any tasks clamped with cpu.util.max=1 (with sched_setattr syscall) are
classified as jitter tasks. We define a core to be non-idle if it is over
12.5% utilized of its capacity; the jitters are packed over these cores
using First-fit approach.
To demonstrate/benchmark, one can use a synthetic workload generator
`turbo_bench.c`[1] available at
https://github.com/parthsl/tools/blob/master/benchmarks/turbo_bench.c
Following snippet demonstrates the use of TurboSched feature:
```
i=8; ./turbo_bench -t 30 -h $i -n $((i*2)) -j
```
Current implementation uses only jitter classified tasks to be packed on
the first busy cores, but can be further optimized by getting userspace
input of important tasks and keeping track of such tasks. This leads to
optimized searching of non idle cores and also more accurate as userspace
hints are safer than auto classified busy cores/tasks.
Result
======
The patch-set proves to be useful for the system and the workload where
frequency boost is found to be useful than packing tasks into cores. IBM
POWER 9 system shows the benefit for a workload can be up to 13%.
Performance benefit of TurboSched w.r.t. CFS
+--+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+-+--+--+--+--+--+
| + + + + + + + + + + + + + + + + + + + + + + + |
15 +-+ Performance benefit in % +-+
| ** |
| ** ** |
10 +-+ ** ** ** +-+
| ** ** ** |
| ** ** ** |
5 +-+ ** ** ** ** ** ** +-+
| ** ** ** ** ** ** ** ** |
| ** ** ** ** ** ** ** ** ** ** |
| * ** ** ** ** ** ** ** ** ** ** ** * |
0 +-+** ** ** ** ** * ** ** ** ** ** ** ** ** ** ** ** * ** ** ** ** **-+
| ** ** ** ** |
| ** |
-5 +-+ +-+
| + + + + + + + + + + + + + + + + + + + + + + + |
+--+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+-+--+--+--+--+--+
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1920 21 22 23 24
No. of workload threads
Frequency benefit of TurboSched w.r.t. CFS
+--+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+-+--+--+--+--+--+
| + + + + + + + + + + + + + + + + + + + + + + + |
15 +-+ Frequency benefit in % +-+
| ** |
| ** |
10 +-+ ** ** +-+
| ** ** ** |
| ** ** * ** ** ** |
5 +-+ ** ** ** * ** ** ** ** +-+
| ** ** ** ** * ** ** ** ** ** |
| ** ** ** ** ** * ** ** ** ** ** ** |
| ** ** ** ** ** * ** ** ** ** ** ** ** ** ** |
0 +-+** ** ** ** ** * ** ** ** ** ** ** ** ** ** ** ** * ** ** ** ** **-+
| |
| |
-5 +-+ +-+
| + + + + + + + + + + + + + + + + + + + + + + + |
+--+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+-+--+--+--+--+--+
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1920 21 22 23 24
No. of workload threads
These numbers are w.r.t. `turbo_bench.c` multi-threaded test benchmark
which can create two kinds of tasks: CPU bound (High Utilization) and
Jitters (Low Utilization). N in X-axis represents N-CPU bound and N-Jitter
tasks spawned.
Series organization
==============
- Patches [01-03]: Jitter tasks classification using syscall
- Patches [04-05]: Defines Core Capacity to limit task packing
- Patches [06-08]: Tune CFS task wakeup logic to pack tasks onto busy
cores
Series can be applied on top of Patrick Bellasi's UCLAMP RFCv9[2]
patches with branch on tip/sched/core and UCLAMP_TASK_GROUP config
options enabled.
References
==========
[1] "Turbo_bench: Synthetic workload generator"
https://github.com/parthsl/tools/blob/master/benchmarks/turbo_bench.c
[2] "Patrick Bellasi, Add utilization clamping support"
https://lkml.org/lkml/2019/5/15/212
Parth Shah (8):
sched/core: Add manual jitter classification using sched_setattr
syscall
sched: Introduce switch to enable TurboSched mode
sched/core: Update turbo_sched count only when required
sched/fair: Define core capacity to limit task packing
powerpc: Define Core Capacity for POWER systems
sched/fair: Tune task wake-up logic to pack jitter tasks
sched/fair: Bound non idle core search within LLC domain
powerpc: Set turbo domain to NUMA node for task packing
arch/powerpc/include/asm/topology.h | 7 ++
arch/powerpc/kernel/smp.c | 38 ++++++++
include/linux/sched.h | 6 ++
kernel/sched/core.c | 35 +++++++
kernel/sched/fair.c | 141 +++++++++++++++++++++++++++-
kernel/sched/sched.h | 9 ++
6 files changed, 235 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
From: Viresh Kumar @ 2019-06-25 4:10 UTC (permalink / raw)
To: Saravana Kannan
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki,
Android Kernel Team, Linux PM, LKML
In-Reply-To: <CAGETcx_ggG8oDnAVaSfuHfip1ozjQpFiGs15cz8nLQnzjTiSTg@mail.gmail.com>
On 24-06-19, 15:17, Saravana Kannan wrote:
> Here's an example. This can't be done today, but can be done with this change.
>
> In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have something
> like this with the following changes:
>
> bus_g2d_400: bus0 {
> compatible = "samsung,exynos-bus";
> clocks = <&cmu_top CLK_ACLK_G2D_400>;
> clock-names = "bus";
> operating-points-v2 = <&bus_g2d_400_opp_table>;
> status = "disabled";
> };
>
> bus_noc2: bus9 {
> compatible = "samsung,exynos-bus";
> clocks = <&cmu_mif CLK_ACLK_BUS2_400>;
> clock-names = "bus";
> operating-points-v2 = <&bus_noc2_opp_table>;
> status = "disabled";
> };
And what is the relation between these two busses ?
> bus_g2d_400_opp_table: opp_table2 {
> compatible = "operating-points-v2";
> opp-shared;
>
> opp-400000000 {
> opp-hz = /bits/ 64 <400000000>;
> opp-microvolt = <1075000>;
> + required-opps = <&noc2_400>;
> };
> opp-267000000 {
> opp-hz = /bits/ 64 <267000000>;
> opp-microvolt = <1000000>;
> + required-opps = <&noc2_200>;
> };
> opp-200000000 {
> opp-hz = /bits/ 64 <200000000>;
> opp-microvolt = <975000>;
> + required-opps = <&noc2_200>;
> };
> opp-160000000 {
> opp-hz = /bits/ 64 <160000000>;
> opp-microvolt = <962500>;
> + required-opps = <&noc2_134>;
> };
> opp-134000000 {
> opp-hz = /bits/ 64 <134000000>;
> opp-microvolt = <950000>;
> + required-opps = <&noc2_134>;
> };
> opp-100000000 {
> opp-hz = /bits/ 64 <100000000>;
> opp-microvolt = <937500>;
> + required-opps = <&noc2_100>;
> };
> };
>
> bus_noc2_opp_table: opp_table6 {
> compatible = "operating-points-v2";
>
> - opp-400000000 {
> + noc2_400: opp-400000000 {
> opp-hz = /bits/ 64 <400000000>;
> };
> - opp-200000000 {
> + noc2_200: opp-200000000 {
> opp-hz = /bits/ 64 <200000000>;
> };
> - opp-134000000 {
> + noc2_134: opp-134000000 {
> opp-hz = /bits/ 64 <134000000>;
> };
> - opp-100000000 {
> + noc2_100: opp-100000000 {
> opp-hz = /bits/ 64 <100000000>;
> };
> };
>
> Thanks,
> Saravana
--
viresh
^ permalink raw reply
* RE: Re: [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30
From: MyungJoo Ham @ 2019-06-25 1:42 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Chanwoo Choi, linux-pm@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
jonathanh@nvidia.com, thierry.reding@gmail.com
In-Reply-To: <7561edbc-c17c-101a-b339-fc7f9968a470@gmail.com>
Sender : Dmitry Osipenko <digetx@gmail.com>
>24.06.2019 14:11, MyungJoo Ham пишет:
>>>
>>> --------- Original Message ---------
>>> Sender : Dmitry Osipenko <digetx@gmail.com>
>>>
>>> 24.06.2019 10:34, MyungJoo Ham пишет:
>>>>>
>>>>> A question:
>>>>>
>>>>> Does this driver support Tegra20 as well?
>>>>> I'm asking this because ARCH_TEGRA includes ARCH_TEGRA_2x_SOC
>>>>> according to /drivers/soc/tegra/Kconfig.
>>>>>
>>>>
>>>> For this matter, how about updating your 13/16 patch as follows?
>>>>
>> []
>>>
>>> Good call! I'll update this patch following yours suggestion, thanks.
>>
>> Or, you may approve the modified commits here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/log/?h=for-next
>
>Looks almost good to me!
>
>I just recalled that there is also a 64bit variant of Tegra124, the Tegra132. Hence
>the Tegra30+ Kconfig entry should look like this (it's also worthy to break the lines
>for readability):
>
>diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>index ccb1a68c4b51..bd2efbc27725 100644
>--- a/drivers/devfreq/Kconfig
>+++ b/drivers/devfreq/Kconfig
>@@ -94,7 +94,10 @@ config ARM_EXYNOS_BUS_DEVFREQ
>
> config ARM_TEGRA_DEVFREQ
> tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver"
>- depends on ARCH_TEGRA || COMPILE_TEST
>+ depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \
>+ ARCH_TEGRA_132_SOC || ARCH_TEGRA_124_SOC || \
>+ ARCH_TEGRA_210_SOC || \
>+ COMPILE_TEST
> select PM_OPP
> help
> This adds the DEVFREQ driver for the Tegra family of SoCs.
>
>Could you please adjust the patches like I'm suggesting? I'll approve yours change
>then and won't re-spin the first batch of the patches.
I've adjusted as you suggested. It's pushed to the git repo as well.
Cheers,
MyungJoo.
^ permalink raw reply
* Re: [PATCH v4 08/11] thermal: sun8i: support ahb clocks
From: Ondřej Jirman @ 2019-06-25 0:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Yangtao Li, mark.rutland, devicetree, linux-pm, gregkh,
linus.walleij, daniel.lezcano, linux-kernel, edubezval, wens,
robh+dt, mchehab+samsung, rui.zhang, paulmck, davem,
linux-arm-kernel
In-Reply-To: <20190624182333.di7avywtdvzwukms@flea>
On Mon, Jun 24, 2019 at 08:23:33PM +0200, Maxime Ripard wrote:
> On Sun, Jun 23, 2019 at 12:42:03PM -0400, Yangtao Li wrote:
> > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > and adds the process of the clock.
> >
> > This is pre-work for supprt it.
> >
> > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > ---
> > drivers/thermal/sun8i_thermal.c | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> > index ed1c19bb27cf..04f53ffb6a14 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -54,6 +54,7 @@ struct tsensor {
> > };
> >
> > struct ths_thermal_chip {
> > + bool has_ahb_clk;
> > int sensor_num;
> > int offset;
> > int scale;
> > @@ -69,6 +70,7 @@ struct ths_device {
> > struct regmap *regmap;
> > struct reset_control *reset;
> > struct clk *bus_clk;
> > + struct clk *ahb_clk;
>
> Hmm, thinking a bit about this, the name of those two clocks doesn't
> make sense. AHB is the bus being used to access that device, so the
> bus clock is the AHB clock.
>
> What is that clock being used for?
To control the A/D and sample averaging logic, I suppose. It's controlled by the
THS_CLK_REG (THS Clock Register) in H3 user manual.
bus_clk controls THS_GATING in BUS_CLK_GATING_REG2 (THS module is connected to
APB bus).
I'd call it ths_clk and bus_clk.
regards,
o.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] power: Do not clear events_check_enabled in pm_wakeup_pending()
From: Rafael J. Wysocki @ 2019-06-24 23:35 UTC (permalink / raw)
To: Ravi Chandra Sadineni
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Linux PM, linux-kernel, Todd Broch, Rajat Jain
In-Reply-To: <CAEZbON4e1=w6G4KEqq2qP0nTD4z00fcqHErWTBVGFGb17f=+1Q@mail.gmail.com>
On Tue, Jun 25, 2019 at 1:25 AM Ravi Chandra Sadineni
<ravisadineni@chromium.org> wrote:
>
> Hi,
>
> Just wanted to check if this is o.k.
It is in my "for review" queue, I'll let you know.
Thanks!
^ permalink raw reply
* Re: [PATCH] power: Do not clear events_check_enabled in pm_wakeup_pending()
From: Ravi Chandra Sadineni @ 2019-06-24 23:25 UTC (permalink / raw)
To: rjw, len.brown, pavel, gregkh, linux-pm, linux-kernel, Todd Broch,
Ravi Chandra Sadineni, Rajat Jain
In-Reply-To: <20190619175142.237794-1-ravisadineni@chromium.org>
Hi,
Just wanted to check if this is o.k.
Thanks,
Ravi
On Wed, Jun 19, 2019 at 10:52 AM Ravi Chandra Sadineni
<ravisadineni@chromium.org> wrote:
>
> events_check_enabled bool is set when wakeup_count sysfs attribute
> is written. User level daemon is expected to write this attribute
> just before suspend.
>
> When this boolean is set, calls to pm_wakeup_event() will result in
> increment of per device and global wakeup count that helps in
> identifying the wake source. global wakeup count is also used by
> pm_wakeup_pending() to identify if there are any pending events that
> should result in an suspend abort.
>
> Currently calls to pm_wakeup_pending() also clears events_check_enabled.
> This can be a problem when there are multiple wake events or when the
> suspend is aborted due to an interrupt on a shared interrupt line.
> For example an Mfd device can create several platform devices which
> might fetch the state on resume in the driver resume method and increment
> the wakeup count if needed. But if events_check_enabled is cleared before
> resume methods get to execute, wakeup count will not be incremented. Thus
> let us not reset the bool here.
>
> Note that events_check_enabled is also cleared in suspend.c/enter_state()
> on every resume at the end.
>
> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
> ---
> drivers/base/power/wakeup.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index 5b2b6a05a4f3..88aade871589 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -838,7 +838,6 @@ bool pm_wakeup_pending(void)
>
> split_counters(&cnt, &inpr);
> ret = (cnt != saved_count || inpr > 0);
> - events_check_enabled = !ret;
> }
> raw_spin_unlock_irqrestore(&events_lock, flags);
>
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v2] PCI: PM: Skip devices in D0 for suspend-to-idle
From: Rafael J. Wysocki @ 2019-06-24 23:09 UTC (permalink / raw)
To: Jon Hunter
Cc: Linux PCI, Bjorn Helgaas, Linux PM, Linux ACPI, LKML,
Mika Westerberg, Keith Busch, Kai-Heng Feng, linux-tegra
In-Reply-To: <CAJZ5v0gGdXmgc_9r2rbiadq4e31hngpjYQ40QoC6C0z19da_hQ@mail.gmail.com>
On Tuesday, June 25, 2019 12:20:26 AM CEST Rafael J. Wysocki wrote:
> On Mon, Jun 24, 2019 at 11:37 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Mon, Jun 24, 2019 at 2:43 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> > >
> > > Hi Rafael,
> > >
> > > On 13/06/2019 22:59, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > >
> > > > Commit d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
> > > > attempted to avoid a problem with devices whose drivers want them to
> > > > stay in D0 over suspend-to-idle and resume, but it did not go as far
> > > > as it should with that.
> > > >
> > > > Namely, first of all, the power state of a PCI bridge with a
> > > > downstream device in D0 must be D0 (based on the PCI PM spec r1.2,
> > > > sec 6, table 6-1, if the bridge is not in D0, there can be no PCI
> > > > transactions on its secondary bus), but that is not actively enforced
> > > > during system-wide PM transitions, so use the skip_bus_pm flag
> > > > introduced by commit d491f2b75237 for that.
> > > >
> > > > Second, the configuration of devices left in D0 (whatever the reason)
> > > > during suspend-to-idle need not be changed and attempting to put them
> > > > into D0 again by force is pointless, so explicitly avoid doing that.
> > > >
> > > > Fixes: d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
> > > > Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > >
> > > I have noticed a regression in both the mainline and -next branches on
> > > one of our boards when testing suspend. The bisect is point to this
> > > commit and reverting on top of mainline does fix the problem. So far I
> > > have not looked at this in close detail but kernel log is showing ...
> >
> > Can you please collect a log like that, but with dynamic debug in
> > pci-driver.c enabled?
> >
> > Note that reverting this commit is rather out of the question, so we
> > need to get to the bottom of the failure.
>
> I suspect that there is a problem with the pm_suspend_via_firmware()
> check which returns 'false' on the affected board, but the platform
> actually removes power from devices left in D0 during suspend.
>
> I guess it would be more appropriate to check something like
> pm_suspend_no_platform() which would return 'true' in the
> suspend-to-idle patch w/ ACPI.
So I wonder if the patch below makes any difference?
---
drivers/pci/pci-driver.c | 8 ++++----
include/linux/suspend.h | 26 ++++++++++++++++++++++++--
kernel/power/suspend.c | 3 +++
3 files changed, 31 insertions(+), 6 deletions(-)
Index: linux-pm/include/linux/suspend.h
===================================================================
--- linux-pm.orig/include/linux/suspend.h
+++ linux-pm/include/linux/suspend.h
@@ -209,8 +209,9 @@ extern int suspend_valid_only_mem(suspen
extern unsigned int pm_suspend_global_flags;
-#define PM_SUSPEND_FLAG_FW_SUSPEND (1 << 0)
-#define PM_SUSPEND_FLAG_FW_RESUME (1 << 1)
+#define PM_SUSPEND_FLAG_FW_SUSPEND BIT(0)
+#define PM_SUSPEND_FLAG_FW_RESUME BIT(1)
+#define PM_SUSPEND_FLAG_NO_PLATFORM BIT(2)
static inline void pm_suspend_clear_flags(void)
{
@@ -227,6 +228,11 @@ static inline void pm_set_resume_via_fir
pm_suspend_global_flags |= PM_SUSPEND_FLAG_FW_RESUME;
}
+static inline void pm_set_suspend_no_platform(void)
+{
+ pm_suspend_global_flags |= PM_SUSPEND_FLAG_NO_PLATFORM;
+}
+
/**
* pm_suspend_via_firmware - Check if platform firmware will suspend the system.
*
@@ -268,6 +274,22 @@ static inline bool pm_resume_via_firmwar
return !!(pm_suspend_global_flags & PM_SUSPEND_FLAG_FW_RESUME);
}
+/**
+ * pm_suspend_no_platform - Check if platform may change device power states.
+ *
+ * To be called during system-wide power management transitions to sleep states
+ * or during the subsequent system-wide transitions back to the working state.
+ *
+ * Return 'true' if the power states of devices remain under full control of the
+ * kernel throughout the system-wide suspend and resume cycle in progress (that
+ * is, if a device is put into a certain power state during suspend, it can be
+ * expected to remain in that state during resume).
+ */
+static inline bool pm_suspend_no_platform(void)
+{
+ return !!(pm_suspend_global_flags & PM_SUSPEND_FLAG_NO_PLATFORM);
+}
+
/* Suspend-to-idle state machnine. */
enum s2idle_states {
S2IDLE_STATE_NONE, /* Not suspended/suspending. */
Index: linux-pm/kernel/power/suspend.c
===================================================================
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -493,6 +493,9 @@ int suspend_devices_and_enter(suspend_st
pm_suspend_target_state = state;
+ if (state == PM_SUSPEND_TO_IDLE)
+ pm_set_suspend_no_platform();
+
error = platform_suspend_begin(state);
if (error)
goto Close;
Index: linux-pm/drivers/pci/pci-driver.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -870,7 +870,7 @@ static int pci_pm_suspend_noirq(struct d
pci_dev->bus->self->skip_bus_pm = true;
}
- if (pci_dev->skip_bus_pm && !pm_suspend_via_firmware()) {
+ if (pci_dev->skip_bus_pm && pm_suspend_no_platform()) {
dev_dbg(dev, "PCI PM: Skipped\n");
goto Fixup;
}
@@ -925,10 +925,10 @@ static int pci_pm_resume_noirq(struct de
/*
* In the suspend-to-idle case, devices left in D0 during suspend will
* stay in D0, so it is not necessary to restore or update their
- * configuration here and attempting to put them into D0 again may
- * confuse some firmware, so avoid doing that.
+ * configuration here and attempting to put them into D0 again is
+ * pointless, so avoid doing that.
*/
- if (!pci_dev->skip_bus_pm || pm_suspend_via_firmware())
+ if (!(pci_dev->skip_bus_pm && pm_suspend_no_platform()))
pci_pm_default_resume_early(pci_dev);
pci_fixup_device(pci_fixup_resume_early, pci_dev);
^ permalink raw reply
* Re: [PATCH 1/3] notifier: Fix broken error handling pattern
From: Josh Poimboeuf @ 2019-06-24 22:21 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jessica Yu, linux-kernel, jikos, mbenes, pmladek, ast, daniel,
akpm, Rafael J. Wysocki, Pavel Machek, Len Brown, Sam Protsenko,
Thomas Gleixner, Greg Kroah-Hartman, Alexios Zavras,
Allison Randal, Vasily Averin, Todd Brandt, linux-pm
In-Reply-To: <20190624092109.745446564@infradead.org>
On Mon, Jun 24, 2019 at 11:18:44AM +0200, Peter Zijlstra wrote:
> The current notifiers have the following error handling pattern all
> over the place:
>
> int nr;
>
> ret = __foo_notifier_call_chain(&chain, val_up, v, -1, &nr);
> if (err & NOTIFIER_STOP_MASK)
s/err/ret/
> __foo_notifier_call_chain(&chain, val_down, v, nr-1, NULL)
>
> And aside from the endless repetition thereof, it is broken. Consider
> blocking notifiers; both calls take and drop the rwsem, this means
> that the notifier list can change in between the two calls, making @nr
> meaningless.
>
> Fix this by replacing all the __foo_notifier_call_chain() functions
> with foo_notifier_call_chain_error() that embeds the above patter, but
> ensures it is inside a single lock region.
The name "notifier_call_chain_error()" seems confusing, it almost sounds
like it's notifying an error code. Then again, I can't really think of
a more reasonably succinct name.
> @@ -25,8 +25,23 @@ static int cpu_pm_notify(enum cpu_pm_eve
> * RCU know this.
> */
> rcu_irq_enter_irqson();
> - ret = __atomic_notifier_call_chain(&cpu_pm_notifier_chain, event, NULL,
> - nr_to_call, nr_calls);
> + ret = atomic_notifier_call_chain(&cpu_pm_notifier_chain, event, NULL);
> + rcu_irq_exit_irqson();
> +
> + return notifier_to_errno(ret);
> +}
> +
> +static int cpu_pm_notify_error(enum cpu_pm_event event_up, enum cpu_pm_event event_down)
> +{
> + int ret;
> +
> + /*
> + * __atomic_notifier_call_chain has a RCU read critical section, which
__atomic_notifier_call_chain() no longer exists.
> + * could be disfunctional in cpu idle. Copy RCU_NONIDLE code to let
"dysfunctional"
> @@ -156,43 +169,30 @@ int atomic_notifier_chain_unregister(str
> }
> EXPORT_SYMBOL_GPL(atomic_notifier_chain_unregister);
>
> -/**
> - * __atomic_notifier_call_chain - Call functions in an atomic notifier chain
> - * @nh: Pointer to head of the atomic notifier chain
> - * @val: Value passed unmodified to notifier function
> - * @v: Pointer passed unmodified to notifier function
> - * @nr_to_call: See the comment for notifier_call_chain.
> - * @nr_calls: See the comment for notifier_call_chain.
> - *
> - * Calls each function in a notifier chain in turn. The functions
> - * run in an atomic context, so they must not block.
> - * This routine uses RCU to synchronize with changes to the chain.
> - *
> - * If the return value of the notifier can be and'ed
> - * with %NOTIFY_STOP_MASK then atomic_notifier_call_chain()
> - * will return immediately, with the return value of
> - * the notifier function which halted execution.
> - * Otherwise the return value is the return value
> - * of the last notifier function called.
> - */
Why remove the useful comment?
Ditto for the blocking, raw, srcu, comments.
--
Josh
^ permalink raw reply
* Re: [PATCH v2] PCI: PM: Skip devices in D0 for suspend-to-idle
From: Rafael J. Wysocki @ 2019-06-24 22:20 UTC (permalink / raw)
To: Jon Hunter
Cc: Linux PCI, Bjorn Helgaas, Linux PM, Linux ACPI, LKML,
Mika Westerberg, Keith Busch, Kai-Heng Feng, linux-tegra
In-Reply-To: <CAJZ5v0hdtXqoK84DpYtyMSCnkR9zOHFiUPAzWZDtkFmEjyWD1g@mail.gmail.com>
On Mon, Jun 24, 2019 at 11:37 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Mon, Jun 24, 2019 at 2:43 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >
> > Hi Rafael,
> >
> > On 13/06/2019 22:59, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > Commit d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
> > > attempted to avoid a problem with devices whose drivers want them to
> > > stay in D0 over suspend-to-idle and resume, but it did not go as far
> > > as it should with that.
> > >
> > > Namely, first of all, the power state of a PCI bridge with a
> > > downstream device in D0 must be D0 (based on the PCI PM spec r1.2,
> > > sec 6, table 6-1, if the bridge is not in D0, there can be no PCI
> > > transactions on its secondary bus), but that is not actively enforced
> > > during system-wide PM transitions, so use the skip_bus_pm flag
> > > introduced by commit d491f2b75237 for that.
> > >
> > > Second, the configuration of devices left in D0 (whatever the reason)
> > > during suspend-to-idle need not be changed and attempting to put them
> > > into D0 again by force is pointless, so explicitly avoid doing that.
> > >
> > > Fixes: d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
> > > Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> >
> > I have noticed a regression in both the mainline and -next branches on
> > one of our boards when testing suspend. The bisect is point to this
> > commit and reverting on top of mainline does fix the problem. So far I
> > have not looked at this in close detail but kernel log is showing ...
>
> Can you please collect a log like that, but with dynamic debug in
> pci-driver.c enabled?
>
> Note that reverting this commit is rather out of the question, so we
> need to get to the bottom of the failure.
I suspect that there is a problem with the pm_suspend_via_firmware()
check which returns 'false' on the affected board, but the platform
actually removes power from devices left in D0 during suspend.
I guess it would be more appropriate to check something like
pm_suspend_no_platform() which would return 'true' in the
suspend-to-idle patch w/ ACPI.
^ permalink raw reply
* Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
From: Saravana Kannan @ 2019-06-24 22:17 UTC (permalink / raw)
To: Viresh Kumar
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki,
Android Kernel Team, Linux PM, LKML
In-Reply-To: <20190624094349.rtjb7nuv6g7zmsf2@vireshk-i7>
On Mon, Jun 24, 2019 at 2:43 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 21-06-19, 17:34, Saravana Kannan wrote:
> > The devfreq passive governor scales the frequency of a "child" device
> > based on the current frequency of a "parent" device (not parent/child in
> > the sense of device hierarchy). As of today, the passive governor
> > requires one of the following to work correctly:
> > 1. The parent and child device have the same number of frequencies
> > 2. The child device driver passes a mapping function to translate from
> > parent frequency to child frequency.
> >
> > When (1) is not true, (2) is the only option right now. But often times,
> > all that is required is a simple mapping from parent's frequency to
> > child's frequency.
> >
> > Since OPPs already support pointing to other "required-opps", add
> > support for using that to map from parent device frequency to child
> > device frequency. That way, every child device driver doesn't have to
> > implement a separate mapping function anytime (1) isn't true.
>
> Can you please provide a real world example with DT code here so I
> can understand it better ?
>
Here's an example. This can't be done today, but can be done with this change.
In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have something
like this with the following changes:
bus_g2d_400: bus0 {
compatible = "samsung,exynos-bus";
clocks = <&cmu_top CLK_ACLK_G2D_400>;
clock-names = "bus";
operating-points-v2 = <&bus_g2d_400_opp_table>;
status = "disabled";
};
bus_noc2: bus9 {
compatible = "samsung,exynos-bus";
clocks = <&cmu_mif CLK_ACLK_BUS2_400>;
clock-names = "bus";
operating-points-v2 = <&bus_noc2_opp_table>;
status = "disabled";
};
bus_g2d_400_opp_table: opp_table2 {
compatible = "operating-points-v2";
opp-shared;
opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1075000>;
+ required-opps = <&noc2_400>;
};
opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <1000000>;
+ required-opps = <&noc2_200>;
};
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <975000>;
+ required-opps = <&noc2_200>;
};
opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <962500>;
+ required-opps = <&noc2_134>;
};
opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <950000>;
+ required-opps = <&noc2_134>;
};
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <937500>;
+ required-opps = <&noc2_100>;
};
};
bus_noc2_opp_table: opp_table6 {
compatible = "operating-points-v2";
- opp-400000000 {
+ noc2_400: opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
- opp-200000000 {
+ noc2_200: opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp-134000000 {
+ noc2_134: opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp-100000000 {
+ noc2_100: opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
Thanks,
Saravana
^ permalink raw reply
* Re: Alternatives to /sys/kernel/debug/wakeup_sources
From: Tri Vo @ 2019-06-24 22:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Joel Fernandes, Greg Kroah-Hartman, Rafael J. Wysocki,
Sandeep Patil, Viresh Kumar, Hridya Valsaraju, Linux PM,
Cc: Android Kernel, LKML
In-Reply-To: <CAJZ5v0jeYRx=9stkGbJZgvyQz=Wp2CBkyTwOkJ2Y61AEE6sMdg@mail.gmail.com>
On Mon, Jun 24, 2019 at 2:55 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Mon, Jun 24, 2019 at 2:27 PM Joel Fernandes <joelaf@google.com> wrote:
> >
> > On Mon, Jun 24, 2019 at 3:37 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sun, Jun 23, 2019 at 06:48:43PM -0700, Tri Vo wrote:
> > > > On Wed, Jun 19, 2019 at 1:35 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > >
> > > > > On Wed, Jun 19, 2019 at 1:52 AM Joel Fernandes <joelaf@google.com> wrote:
> > > > > >
> > > > > > On Tue, Jun 18, 2019 at 7:15 PM Tri Vo <trong@android.com> wrote:
> > > > > > [snip]
> > > > > > > > > > >
> > > > > > > > > > > Android userspace reading wakeup_sources is not ideal because:
> > > > > > > > > > > - Debugfs API is not stable, i.e. Android tools built on top of it are
> > > > > > > > > > > not guaranteed to be backward/forward compatible.
> > > > > > > > > > > - This file requires debugfs to be mounted, which itself is
> > > > > > > > > > > undesirable for security reasons.
> > > > > > > > > > >
> > > > > > > > > > > To address these problems, we want to contribute a way to expose these
> > > > > > > > > > > statistics that doesn't depend on debugfs.
> > > > > > > > > > >
> > > > > > > > > > > Some initial thoughts/questions: Should we expose the stats in sysfs?
> > > > > > > > > > > Or maybe implement eBPF-based solution? What do you think?
> > > > > > > > >
> > > > > > > > > We are going through Android's out-of-tree kernel dependencies along with
> > > > > > > > > userspace APIs that are not necessarily considered "stable and forever
> > > > > > > > > supported" upstream. The debugfs dependencies showed up on our radar as a
> > > > > > > > > result and so we are wondering if we should worry about changes in debugfs
> > > > > > > > > interface and hence the question(s) below.
> > > > > > > > >
> > > > > > > > > So, can we rely on /d/wakeup_sources to be considered a userspace API and
> > > > > > > > > hence maintained stable as we do for other /proc and /sys entries?
> > > > > > > > >
> > > > > > > > > If yes, then we will go ahead and add tests for this in LTP or
> > > > > > > > > somewhere else suitable.
> > > > > > > >
> > > > > > > > No, debugfs is not ABI.
> > > > > > > >
> > > > > > > > > If no, then we would love to hear suggestions for any changes that need to be
> > > > > > > > > made or we simply just move the debugfs entry into somewhere like
> > > > > > > > > /sys/power/ ?
> > > > > > > >
> > > > > > > > No, moving that entire file from debugfs into sysfs is not an option either.
> > > > > > > >
> > > > > > > > The statistics for the wakeup sources associated with devices are already there
> > > > > > > > under /sys/devices/.../power/ , but I guess you want all wakeup sources?
> > > > > > > >
> > > > > > > > That would require adding a kobject to struct wakeup_source and exposing
> > > > > > > > all of the statistics as separate attributes under it. In which case it would be
> > > > > > > > good to replace the existing wakeup statistics under /sys/devices/.../power/
> > > > > > > > with symbolic links to the attributes under the wakeup_source kobject.
> > > > > > >
> > > > > > > Thanks for your input, Rafael! Your suggestion makes sense. I'll work
> > > > > > > on a patch for this.
> > > > > >
> > > > > > Does that entail making each wake up source, a new sysfs node under a
> > > > > > particular device, and then adding stats under that new node?
> > > > >
> > > > > Not under a device, because there are wakeup source objects without
> > > > > associated devices.
> > > > >
> > > > > It is conceivable to have a "wakeup_sources" directory under
> > > > > /sys/power/ and sysfs nodes for all wakeup sources in there.
> > > > >
> > > > > Then, instead of exposing wakeup statistics directly under
> > > > > /sys/devices/.../power/, there can be symbolic links from there to the
> > > > > new wakeup source nodes under "wakeup_sources" (so as to avoid
> > > > > exposing the same data in two different places in sysfs, which may be
> > > > > confusing).
> > > >
> > > > This may be a dumb question. Is it appropriate to make symbolic links
> > > > in sysfs from one attribute to another attribute? For example,
> > > > /sys/devices/.../power/wakeup_count ->
> > > > /sys/power/wakeup_sources/.../wakeup_count.
> > >
> > > Why? would you want that?
> >
> > This sounds like what Rafael suggested (quoted above), right?
>
> I did, basically to avoid exposing the same information in two places
> via different code paths.
>
> I tend to forget about this limitation, sorry for the confusion.
>
> That's not a big deal, though, the attributes under
> /sys/devices/.../power/ just need to stay the way they are (for
> backwards compatibility).
Thanks for the clarification, Rafael!
^ permalink raw reply
* Re: [PATCH v2 2/2] thermal/drivers/cpu_cooling: Unregister with the policy
From: Rafael J. Wysocki @ 2019-06-24 22:08 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Viresh Kumar, Rafael J. Wysocki, Eduardo Valentin,
Linux Kernel Mailing List, Sudeep Holla, Amit Daniel Kachhap,
Javi Merino, Zhang Rui, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Keerthy,
open list:CPU FREQUENCY DRIVERS - ARM BIG LITTLE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:TI BANDGAP AND THERMAL DRIVER
In-Reply-To: <20190624131715.1857-2-daniel.lezcano@linaro.org>
) On Mon, Jun 24, 2019 at 3:17 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> Currently the function cpufreq_cooling_register() returns a cooling
> device pointer which is used back as a pointer to call the function
> cpufreq_cooling_unregister(). Even if it is correct, it would make
> sense to not leak the structure inside a cpufreq driver and keep the
> code thermal code self-encapsulate. Moreover, that forces to add an
> extra variable in each driver using this function.
[cut]
> @@ -667,9 +667,9 @@ static int imx_thermal_register_legacy_cooling(struct imx_thermal_data *data)
> np = of_get_cpu_node(data->policy->cpu, NULL);
>
> if (!np || !of_find_property(np, "#cooling-cells", NULL)) {
> - data->cdev = cpufreq_cooling_register(data->policy);
> - if (IS_ERR(data->cdev)) {
> - ret = PTR_ERR(data->cdev);
> + cdev = cpufreq_cooling_register(data->policy);
It looks like after the changes in this patch the only reason for
returning (struct thermal_cooling_device *) from
cpufreq_cooling_register() is error checking, but it would be much
more straightforward to return int for this purpose.
Moreover, that would prevent the callers of it from doing incorrect
things with the returned pointers (like using it to unregister the
cooling device).
> + if (IS_ERR(cdev)) {
> + ret = PTR_ERR(cdev);
> cpufreq_cpu_put(data->policy);
> return ret;
> }
^ permalink raw reply
* Re: Alternatives to /sys/kernel/debug/wakeup_sources
From: Rafael J. Wysocki @ 2019-06-24 21:55 UTC (permalink / raw)
To: Joel Fernandes
Cc: Greg Kroah-Hartman, Tri Vo, Rafael J. Wysocki, Rafael J. Wysocki,
Sandeep Patil, Viresh Kumar, Hridya Valsaraju, Linux PM,
Cc: Android Kernel, LKML
In-Reply-To: <CAJWu+orGgYwnC+ya13+KtdNrH7ZjvmKL8625m=msVZd0==dq9A@mail.gmail.com>
On Mon, Jun 24, 2019 at 2:27 PM Joel Fernandes <joelaf@google.com> wrote:
>
> On Mon, Jun 24, 2019 at 3:37 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Sun, Jun 23, 2019 at 06:48:43PM -0700, Tri Vo wrote:
> > > On Wed, Jun 19, 2019 at 1:35 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > >
> > > > On Wed, Jun 19, 2019 at 1:52 AM Joel Fernandes <joelaf@google.com> wrote:
> > > > >
> > > > > On Tue, Jun 18, 2019 at 7:15 PM Tri Vo <trong@android.com> wrote:
> > > > > [snip]
> > > > > > > > > >
> > > > > > > > > > Android userspace reading wakeup_sources is not ideal because:
> > > > > > > > > > - Debugfs API is not stable, i.e. Android tools built on top of it are
> > > > > > > > > > not guaranteed to be backward/forward compatible.
> > > > > > > > > > - This file requires debugfs to be mounted, which itself is
> > > > > > > > > > undesirable for security reasons.
> > > > > > > > > >
> > > > > > > > > > To address these problems, we want to contribute a way to expose these
> > > > > > > > > > statistics that doesn't depend on debugfs.
> > > > > > > > > >
> > > > > > > > > > Some initial thoughts/questions: Should we expose the stats in sysfs?
> > > > > > > > > > Or maybe implement eBPF-based solution? What do you think?
> > > > > > > >
> > > > > > > > We are going through Android's out-of-tree kernel dependencies along with
> > > > > > > > userspace APIs that are not necessarily considered "stable and forever
> > > > > > > > supported" upstream. The debugfs dependencies showed up on our radar as a
> > > > > > > > result and so we are wondering if we should worry about changes in debugfs
> > > > > > > > interface and hence the question(s) below.
> > > > > > > >
> > > > > > > > So, can we rely on /d/wakeup_sources to be considered a userspace API and
> > > > > > > > hence maintained stable as we do for other /proc and /sys entries?
> > > > > > > >
> > > > > > > > If yes, then we will go ahead and add tests for this in LTP or
> > > > > > > > somewhere else suitable.
> > > > > > >
> > > > > > > No, debugfs is not ABI.
> > > > > > >
> > > > > > > > If no, then we would love to hear suggestions for any changes that need to be
> > > > > > > > made or we simply just move the debugfs entry into somewhere like
> > > > > > > > /sys/power/ ?
> > > > > > >
> > > > > > > No, moving that entire file from debugfs into sysfs is not an option either.
> > > > > > >
> > > > > > > The statistics for the wakeup sources associated with devices are already there
> > > > > > > under /sys/devices/.../power/ , but I guess you want all wakeup sources?
> > > > > > >
> > > > > > > That would require adding a kobject to struct wakeup_source and exposing
> > > > > > > all of the statistics as separate attributes under it. In which case it would be
> > > > > > > good to replace the existing wakeup statistics under /sys/devices/.../power/
> > > > > > > with symbolic links to the attributes under the wakeup_source kobject.
> > > > > >
> > > > > > Thanks for your input, Rafael! Your suggestion makes sense. I'll work
> > > > > > on a patch for this.
> > > > >
> > > > > Does that entail making each wake up source, a new sysfs node under a
> > > > > particular device, and then adding stats under that new node?
> > > >
> > > > Not under a device, because there are wakeup source objects without
> > > > associated devices.
> > > >
> > > > It is conceivable to have a "wakeup_sources" directory under
> > > > /sys/power/ and sysfs nodes for all wakeup sources in there.
> > > >
> > > > Then, instead of exposing wakeup statistics directly under
> > > > /sys/devices/.../power/, there can be symbolic links from there to the
> > > > new wakeup source nodes under "wakeup_sources" (so as to avoid
> > > > exposing the same data in two different places in sysfs, which may be
> > > > confusing).
> > >
> > > This may be a dumb question. Is it appropriate to make symbolic links
> > > in sysfs from one attribute to another attribute? For example,
> > > /sys/devices/.../power/wakeup_count ->
> > > /sys/power/wakeup_sources/.../wakeup_count.
> >
> > Why? would you want that?
>
> This sounds like what Rafael suggested (quoted above), right?
I did, basically to avoid exposing the same information in two places
via different code paths.
I tend to forget about this limitation, sorry for the confusion.
That's not a big deal, though, the attributes under
/sys/devices/.../power/ just need to stay the way they are (for
backwards compatibility).
^ permalink raw reply
* Re: [PATCH v2] PCI: PM: Skip devices in D0 for suspend-to-idle
From: Rafael J. Wysocki @ 2019-06-24 21:37 UTC (permalink / raw)
To: Jon Hunter
Cc: Rafael J. Wysocki, Linux PCI, Bjorn Helgaas, Linux PM, Linux ACPI,
LKML, Mika Westerberg, Keith Busch, Kai-Heng Feng, linux-tegra
In-Reply-To: <9906d02b-8c77-f2c8-7168-93ea444b950e@nvidia.com>
On Mon, Jun 24, 2019 at 2:43 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Rafael,
>
> On 13/06/2019 22:59, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Commit d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
> > attempted to avoid a problem with devices whose drivers want them to
> > stay in D0 over suspend-to-idle and resume, but it did not go as far
> > as it should with that.
> >
> > Namely, first of all, the power state of a PCI bridge with a
> > downstream device in D0 must be D0 (based on the PCI PM spec r1.2,
> > sec 6, table 6-1, if the bridge is not in D0, there can be no PCI
> > transactions on its secondary bus), but that is not actively enforced
> > during system-wide PM transitions, so use the skip_bus_pm flag
> > introduced by commit d491f2b75237 for that.
> >
> > Second, the configuration of devices left in D0 (whatever the reason)
> > during suspend-to-idle need not be changed and attempting to put them
> > into D0 again by force is pointless, so explicitly avoid doing that.
> >
> > Fixes: d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
> > Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>
> I have noticed a regression in both the mainline and -next branches on
> one of our boards when testing suspend. The bisect is point to this
> commit and reverting on top of mainline does fix the problem. So far I
> have not looked at this in close detail but kernel log is showing ...
Can you please collect a log like that, but with dynamic debug in
pci-driver.c enabled?
Note that reverting this commit is rather out of the question, so we
need to get to the bottom of the failure.
^ permalink raw reply
* Re: [PATCH v4 08/11] thermal: sun8i: support ahb clocks
From: Maxime Ripard @ 2019-06-24 18:23 UTC (permalink / raw)
To: Yangtao Li
Cc: rui.zhang, edubezval, daniel.lezcano, robh+dt, mark.rutland, wens,
davem, gregkh, mchehab+samsung, linus.walleij, nicolas.ferre,
paulmck, linux-pm, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20190623164206.7467-9-tiny.windzz@gmail.com>
On Sun, Jun 23, 2019 at 12:42:03PM -0400, Yangtao Li wrote:
> H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> and adds the process of the clock.
>
> This is pre-work for supprt it.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
> drivers/thermal/sun8i_thermal.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index ed1c19bb27cf..04f53ffb6a14 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -54,6 +54,7 @@ struct tsensor {
> };
>
> struct ths_thermal_chip {
> + bool has_ahb_clk;
> int sensor_num;
> int offset;
> int scale;
> @@ -69,6 +70,7 @@ struct ths_device {
> struct regmap *regmap;
> struct reset_control *reset;
> struct clk *bus_clk;
> + struct clk *ahb_clk;
Hmm, thinking a bit about this, the name of those two clocks doesn't
make sense. AHB is the bus being used to access that device, so the
bus clock is the AHB clock.
What is that clock being used for?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v10 12/16] sched/core: uclamp: Extend CPU's cgroup controller
From: Tejun Heo @ 2019-06-24 17:52 UTC (permalink / raw)
To: Patrick Bellasi
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra,
Rafael J . Wysocki, Vincent Guittot, Viresh Kumar, Paul Turner,
Quentin Perret, Dietmar Eggemann, Morten Rasmussen, Juri Lelli,
Todd Kjos, Joel Fernandes, Steve Muckle, Suren Baghdasaryan,
Alessio Balsini
In-Reply-To: <20190624172906.3d3w6352ji4izjgo@e110439-lin>
Hey, Patrick.
On Mon, Jun 24, 2019 at 06:29:06PM +0100, Patrick Bellasi wrote:
> > I kinda wonder whether the term bandwidth is a bit confusing because
> > it's also used for cpu.max/min. Would just calling it frequency be
> > clearer?
>
> Maybe I should find a better way to express the concept above.
>
> I agree that bandwidth is already used by cpu.{max,min}, what I want
> to call out is that clamps allows to enrich that concept.
>
> By hinting the scheduler on min/max required utilization we can better
> defined the amount of actual CPU cycles required/allowed.
> That's a bit more precise bandwidth control compared to just rely on
> temporal runnable/period limits.
I see. I wonder whether it's overloading the same term too subtly
tho. It's great to document how they interact but it *might* be
easier for readers if a different term is used even if the meaning is
essentially the same. Anyways, it's a nitpick. Please feel free to
ignore.
> > > + tg = css_tg(of_css(of));
> > > + if (tg == &root_task_group) {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> >
> > I don't think you need the above check.
>
> Don't we want to forbid attributes tuning from the root group?
Yeah, that's enforced by NOT_ON_ROOT flag, right?
> > So, uclamp.max limits the maximum freq% can get and uclamp.min limits
> > hte maximum freq% protection can get in the subtree. Let's say
> > uclamp.max is 50% and uclamp.min is 100%.
>
> That's not possible, in the current implementation we always enforce
> the limit (uclamp.max) to be _not smaller_ then the protection
> (uclamp.min).
>
> Indeed, in principle, it does not make sense to ask for a minimum
> utilization (i.e. frequency boosting) which is higher then the
> maximum allowed utilization (i.e. frequency capping).
Yeah, I'm trying to explain actually it does.
> > It means that protection is not limited but the actual freq% is
> > limited upto 50%, which isn't necessarily invalid.
> > For a simple example, a user might be saying
> > that they want to get whatever protection they can get from its parent
> > but wanna limit eventual freq at 50% and it isn't too difficult to
> > imagine cases where the two knobs are configured separately especially
> > configuration is being managed hierarchically / automatically.
>
> That's not my understanding, in v10 by default when we create a
> subgroup we assign it uclamp.min=0%, meaning that we don't boost
> frequencies.
>
> It seems instead that you are asking to set uclamp.min=100% by
> default, so that the effective value will give us whatever the father
> allow. Is that correct?
No, the defaults are fine. I'm trying to say that min/max
configurations don't need to be coupled like this and there are valid
use cases where the configured min is higher than max when
configurations are nested and managed automatically.
Limits always trump protection in effect of course but please don't
limit what can be configured.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v10 13/16] sched/core: uclamp: Propagate parent clamps
From: Tejun Heo @ 2019-06-24 17:46 UTC (permalink / raw)
To: Patrick Bellasi
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra,
Rafael J . Wysocki, Vincent Guittot, Viresh Kumar, Paul Turner,
Quentin Perret, Dietmar Eggemann, Morten Rasmussen, Juri Lelli,
Todd Kjos, Joel Fernandes, Steve Muckle, Suren Baghdasaryan,
Alessio Balsini
In-Reply-To: <20190624173405.enrxqalaqinbgsut@e110439-lin>
Hello, Patrick.
On Mon, Jun 24, 2019 at 06:34:05PM +0100, Patrick Bellasi wrote:
> > On Fri, Jun 21, 2019 at 09:42:14AM +0100, Patrick Bellasi wrote:
> > > Since it can be interesting for userspace, e.g. system management
> > > software, to know exactly what the currently propagated/enforced
> > > configuration is, the effective clamp values are exposed to user-space
> > > by means of a new pair of read-only attributes
> > > cpu.util.{min,max}.effective.
> >
> > Can we not add the effective interface file for now?
>
> You mean just the (read-only) user-space API right?
Yeah.
> I found it quite convenient, even just for debugging.
> Moreover it allows a container to know what it's exactly getting...
I fully agree.
> > I don't think it's a bad idea but would like to think more about it.
> > For cpuset, it was needed because configuration was so interwoven
> > with the effective masks, but we don't generally do this for other
> > min/max or weight knobs, all of which have effective hierarchical
> > values and I'm not quite sure about adding .effective for all of
> > them.
> > It could be that that's what we end up doing eventually but
> > I'd like to think a bit more about it.
>
> ... but I see your point and, since it's not strictly required, I
> think we can drop it in v11. Will check better if it's of any use
> apart from debugging/testing support.
Yeah, I just wanna figure out a plan which works for other controllers
too. It could be that the right thing to do is just adding .effective
to everything but idk I need to think more about it.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v10 13/16] sched/core: uclamp: Propagate parent clamps
From: Patrick Bellasi @ 2019-06-24 17:34 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra,
Rafael J . Wysocki, Vincent Guittot, Viresh Kumar, Paul Turner,
Quentin Perret, Dietmar Eggemann, Morten Rasmussen, Juri Lelli,
Todd Kjos, Joel Fernandes, Steve Muckle, Suren Baghdasaryan,
Alessio Balsini
In-Reply-To: <20190622150750.GN657710@devbig004.ftw2.facebook.com>
On 22-Jun 08:07, Tejun Heo wrote:
> Hello,
Hi,
> On Fri, Jun 21, 2019 at 09:42:14AM +0100, Patrick Bellasi wrote:
> > Since it can be interesting for userspace, e.g. system management
> > software, to know exactly what the currently propagated/enforced
> > configuration is, the effective clamp values are exposed to user-space
> > by means of a new pair of read-only attributes
> > cpu.util.{min,max}.effective.
>
> Can we not add the effective interface file for now?
You mean just the (read-only) user-space API right?
I found it quite convenient, even just for debugging.
Moreover it allows a container to know what it's exactly getting...
> I don't think it's a bad idea but would like to think more about it.
> For cpuset, it was needed because configuration was so interwoven
> with the effective masks, but we don't generally do this for other
> min/max or weight knobs, all of which have effective hierarchical
> values and I'm not quite sure about adding .effective for all of
> them.
> It could be that that's what we end up doing eventually but
> I'd like to think a bit more about it.
... but I see your point and, since it's not strictly required, I
think we can drop it in v11. Will check better if it's of any use
apart from debugging/testing support.
> Thanks.
>
> --
> tejun
Cheers,
Patrick
--
#include <best/regards.h>
Patrick Bellasi
^ permalink raw reply
* Re: [PATCH v10 12/16] sched/core: uclamp: Extend CPU's cgroup controller
From: Patrick Bellasi @ 2019-06-24 17:29 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra,
Rafael J . Wysocki, Vincent Guittot, Viresh Kumar, Paul Turner,
Quentin Perret, Dietmar Eggemann, Morten Rasmussen, Juri Lelli,
Todd Kjos, Joel Fernandes, Steve Muckle, Suren Baghdasaryan,
Alessio Balsini
In-Reply-To: <20190622150332.GM657710@devbig004.ftw2.facebook.com>
On 22-Jun 08:03, Tejun Heo wrote:
> Hello,
Hi,
> Generally looks good to me. Some nitpicks.
>
> On Fri, Jun 21, 2019 at 09:42:13AM +0100, Patrick Bellasi wrote:
> > @@ -951,6 +951,12 @@ controller implements weight and absolute bandwidth limit models for
> > normal scheduling policy and absolute bandwidth allocation model for
> > realtime scheduling policy.
> >
> > +Cycles distribution is based, by default, on a temporal base and it
> > +does not account for the frequency at which tasks are executed.
> > +The (optional) utilization clamping support allows to enforce a minimum
> > +bandwidth, which should always be provided by a CPU, and a maximum bandwidth,
> > +which should never be exceeded by a CPU.
>
> I kinda wonder whether the term bandwidth is a bit confusing because
> it's also used for cpu.max/min. Would just calling it frequency be
> clearer?
Maybe I should find a better way to express the concept above.
I agree that bandwidth is already used by cpu.{max,min}, what I want
to call out is that clamps allows to enrich that concept.
By hinting the scheduler on min/max required utilization we can better
defined the amount of actual CPU cycles required/allowed.
That's a bit more precise bandwidth control compared to just rely on
temporal runnable/period limits.
> > +static ssize_t cpu_uclamp_min_write(struct kernfs_open_file *of,
> > + char *buf, size_t nbytes,
> > + loff_t off)
> > +{
> > + struct task_group *tg;
> > + u64 min_value;
> > + int ret;
> > +
> > + ret = uclamp_scale_from_percent(buf, &min_value);
> > + if (ret)
> > + return ret;
> > + if (min_value > SCHED_CAPACITY_SCALE)
> > + return -ERANGE;
> > +
> > + rcu_read_lock();
> > +
> > + tg = css_tg(of_css(of));
> > + if (tg == &root_task_group) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
>
> I don't think you need the above check.
Don't we want to forbid attributes tuning from the root group?
> > + if (tg->uclamp_req[UCLAMP_MIN].value == min_value)
> > + goto out;
> > + if (tg->uclamp_req[UCLAMP_MAX].value < min_value) {
> > + ret = -EINVAL;
>
> So, uclamp.max limits the maximum freq% can get and uclamp.min limits
> hte maximum freq% protection can get in the subtree. Let's say
> uclamp.max is 50% and uclamp.min is 100%.
That's not possible, in the current implementation we always enforce
the limit (uclamp.max) to be _not smaller_ then the protection
(uclamp.min).
Indeed, in principle, it does not make sense to ask for a minimum
utilization (i.e. frequency boosting) which is higher then the
maximum allowed utilization (i.e. frequency capping).
> It means that protection is not limited but the actual freq% is
> limited upto 50%, which isn't necessarily invalid.
> For a simple example, a user might be saying
> that they want to get whatever protection they can get from its parent
> but wanna limit eventual freq at 50% and it isn't too difficult to
> imagine cases where the two knobs are configured separately especially
> configuration is being managed hierarchically / automatically.
That's not my understanding, in v10 by default when we create a
subgroup we assign it uclamp.min=0%, meaning that we don't boost
frequencies.
It seems instead that you are asking to set uclamp.min=100% by
default, so that the effective value will give us whatever the father
allow. Is that correct?
> tl;dr is that we don't need the above restriction and shouldn't
> generally be restricting configurations when they don't need to.
>
> Thanks.
>
> --
> tejun
Cheers,
Patrick
--
#include <best/regards.h>
Patrick Bellasi
^ permalink raw reply
* Re: cpupower: update German translation
From: Dominik Brodowski @ 2019-06-24 14:09 UTC (permalink / raw)
To: Benjamin Weis; +Cc: trenn, shuah, linux-pm
In-Reply-To: <20190624133150.12322-1-benjamin.weis@gmx.com>
On Mon, Jun 24, 2019 at 03:31:50PM +0200, Benjamin Weis wrote:
> Update the German translation of cpupower, and change the encoding
> to UTF-8.
>
> Signed-off-by: Benjamin Weis <benjamin.weis@gmx.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Thanks,
Dominik
^ permalink raw reply
* Re: [PATCH v2 1/2] cpufreq: Move the IS_ENABLED(CPU_THERMAL) macro in a stub
From: Viresh Kumar @ 2019-06-24 13:59 UTC (permalink / raw)
To: Daniel Lezcano
Cc: rjw, edubezval, linux-kernel,
open list:CPU FREQUENCY SCALING FRAMEWORK
In-Reply-To: <20190624131715.1857-1-daniel.lezcano@linaro.org>
On 24-06-19, 15:17, Daniel Lezcano wrote:
> The cpufreq_online and the cpufreq_offline [un]register the driver as
> a cooling device. This is done if the driver is flagged as a cooling
> device in addition with a IS_ENABLED macro to compile out the branching
> code.
>
> Group this test in a stub function added in the cpufreq header instead
> of having the IS_ENABLED in the code path.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> drivers/cpufreq/cpufreq.c | 6 ++----
> include/linux/cpufreq.h | 5 +++++
> 2 files changed, 7 insertions(+), 4 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Thermal microconference proposal @ LPC
From: Amit Kucheria @ 2019-06-24 13:52 UTC (permalink / raw)
To: Linux PM list; +Cc: Zhang Rui, Eduardo Valentin, Daniel Lezcano
In-Reply-To: <f1efad22-66a6-a094-1ebe-43e794aff6d0@linaro.org>
Hi all,
We've proposed a thermal microconf at LPC again this year. I've bcc'ed
a few people who were interested last year. We already have the
following topics listed for the proposal but could certainly use more
topics especially from the non-mobile Linux community.
- Samsung: Thermal aware scheduling (Lukasz Luba)
- Linaro: Combining idle and freq change for cpu cooling (Daniel Lezcano)
- ARM: Discriminating thermal throttling (Volker Eckert)
- IBM: Sustain turbo mode (Parth Shah)
- QCOM/Linaro: Make thermal framework easier to use in products (Amit Kucheria)
Please help bring this to the attention of those who might be
interested in talking about thermal-related problems at the
conference.
Thanks.
Regards,
Amit Kucheria & Daniel Lezcano
^ permalink raw reply
* cpupower: update German translation
From: Benjamin Weis @ 2019-06-24 13:31 UTC (permalink / raw)
To: trenn, shuah, linux-pm; +Cc: Benjamin Weis
Update the German translation of cpupower, and change the encoding
to UTF-8.
Signed-off-by: Benjamin Weis <benjamin.weis@gmx.com>
---
tools/power/cpupower/po/de.po | 344 ++++++++++++++++++----------------
1 file changed, 180 insertions(+), 164 deletions(-)
diff --git a/tools/power/cpupower/po/de.po b/tools/power/cpupower/po/de.po
index 840c17cc450a..e73fb0744aec 100644
--- a/tools/power/cpupower/po/de.po
+++ b/tools/power/cpupower/po/de.po
@@ -8,66 +8,66 @@ msgstr ""
"Project-Id-Version: cpufrequtils 006\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2011-03-08 17:03+0100\n"
-"PO-Revision-Date: 2009-08-08 17:18+0100\n"
-"Last-Translator: <linux@dominikbrodowski.net>\n"
+"PO-Revision-Date: 2019-06-02 15:23+0200\n"
+"Last-Translator: Benjamin Weis <benjamin.weis@gmx.com>\n"
"Language-Team: NONE\n"
"Language: \n"
"MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=ISO-8859-1\n"
+"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
#: utils/idle_monitor/nhm_idle.c:36
msgid "Processor Core C3"
-msgstr ""
+msgstr "Prozessorkern C3"
#: utils/idle_monitor/nhm_idle.c:43
msgid "Processor Core C6"
-msgstr ""
+msgstr "Prozessorkern C6"
#: utils/idle_monitor/nhm_idle.c:51
msgid "Processor Package C3"
-msgstr ""
+msgstr "Prozessorpaket C3"
#: utils/idle_monitor/nhm_idle.c:58 utils/idle_monitor/amd_fam14h_idle.c:70
msgid "Processor Package C6"
-msgstr ""
+msgstr "Prozessorpaket C6"
#: utils/idle_monitor/snb_idle.c:33
msgid "Processor Core C7"
-msgstr ""
+msgstr "Prozessorkern C7"
#: utils/idle_monitor/snb_idle.c:40
msgid "Processor Package C2"
-msgstr ""
+msgstr "Prozessorpaket C2"
#: utils/idle_monitor/snb_idle.c:47
msgid "Processor Package C7"
-msgstr ""
+msgstr "Prozessorpaket C7"
#: utils/idle_monitor/amd_fam14h_idle.c:56
msgid "Package in sleep state (PC1 or deeper)"
-msgstr ""
+msgstr "Paket in Schlafzustand (PC1 oder tiefer)"
#: utils/idle_monitor/amd_fam14h_idle.c:63
msgid "Processor Package C1"
-msgstr ""
+msgstr "Prozessorpaket C1"
#: utils/idle_monitor/amd_fam14h_idle.c:77
msgid "North Bridge P1 boolean counter (returns 0 or 1)"
-msgstr ""
+msgstr "North Bridge P1 boolescher Zähler (gibt 0 oder 1 zurück)"
#: utils/idle_monitor/mperf_monitor.c:35
msgid "Processor Core not idle"
-msgstr ""
+msgstr "Prozessorkern ist nicht im Leerlauf"
#: utils/idle_monitor/mperf_monitor.c:42
msgid "Processor Core in an idle state"
-msgstr ""
+msgstr "Prozessorkern ist in einem Ruhezustand"
#: utils/idle_monitor/mperf_monitor.c:50
msgid "Average Frequency (including boost) in MHz"
-msgstr ""
+msgstr "Durchschnittliche Frequenz (einschließlich Boost) in MHz"
#: utils/idle_monitor/cpupower-monitor.c:66
#, c-format
@@ -75,6 +75,8 @@ msgid ""
"cpupower monitor: [-h] [ [-t] | [-l] | [-m <mon1>,[<mon2>] ] ] [-i "
"interval_sec | -c command ...]\n"
msgstr ""
+"cpupower monitor: [-h] [ [-t] | [-l] | [-m <mon1>,[<mon2>] ] ] [-i "
+"interval_sec | -c Befehl ...]\n"
#: utils/idle_monitor/cpupower-monitor.c:69
#, c-format
@@ -82,36 +84,40 @@ msgid ""
"cpupower monitor: [-v] [-h] [ [-t] | [-l] | [-m <mon1>,[<mon2>] ] ] [-i "
"interval_sec | -c command ...]\n"
msgstr ""
+"cpupower monitor: [-v] [-h] [ [-t] | [-l] | [-m <mon1>,[<mon2>] ] ] [-i "
+"interval_sec | -c Befehl ...]\n"
#: utils/idle_monitor/cpupower-monitor.c:71
#, c-format
msgid "\t -v: be more verbose\n"
-msgstr ""
+msgstr "\t -v: ausführlicher\n"
#: utils/idle_monitor/cpupower-monitor.c:73
#, c-format
msgid "\t -h: print this help\n"
-msgstr ""
+msgstr "\t -h: diese Hilfe ausgeben\n"
#: utils/idle_monitor/cpupower-monitor.c:74
#, c-format
msgid "\t -i: time intervall to measure for in seconds (default 1)\n"
-msgstr ""
+msgstr "\t -i: Zeitintervall für die Messung in Sekunden (Standard 1)\n"
#: utils/idle_monitor/cpupower-monitor.c:75
#, c-format
msgid "\t -t: show CPU topology/hierarchy\n"
-msgstr ""
+msgstr "\t -t: CPU-Topologie/Hierarchie anzeigen\n"
#: utils/idle_monitor/cpupower-monitor.c:76
#, c-format
msgid "\t -l: list available CPU sleep monitors (for use with -m)\n"
msgstr ""
+"\t -l: verfügbare CPU-Schlafwächter auflisten (für Verwendung mit -m)\n"
#: utils/idle_monitor/cpupower-monitor.c:77
#, c-format
msgid "\t -m: show specific CPU sleep monitors only (in same order)\n"
msgstr ""
+"\t -m: spezifische CPU-Schlafwächter anzeigen (in gleicher Reihenfolge)\n"
#: utils/idle_monitor/cpupower-monitor.c:79
#, c-format
@@ -119,71 +125,73 @@ msgid ""
"only one of: -t, -l, -m are allowed\n"
"If none of them is passed,"
msgstr ""
+"nur einer von: -t, -l, -m ist erlaubt\n"
+"Wenn keiner von ihnen übergeben wird,"
#: utils/idle_monitor/cpupower-monitor.c:80
#, c-format
msgid " all supported monitors are shown\n"
-msgstr ""
+msgstr " werden alle unterstützten Wächter angezeigt\n"
#: utils/idle_monitor/cpupower-monitor.c:197
#, c-format
msgid "Monitor %s, Counter %s has no count function. Implementation error\n"
-msgstr ""
+msgstr "Wächter %s, Zähler %s hat keine Zählfunktion. Implementierungsfehler\n"
#: utils/idle_monitor/cpupower-monitor.c:207
#, c-format
msgid " *is offline\n"
-msgstr ""
+msgstr " *ist offline\n"
#: utils/idle_monitor/cpupower-monitor.c:236
#, c-format
msgid "%s: max monitor name length (%d) exceeded\n"
-msgstr ""
+msgstr "%s: max. Wächternamenslänge (%d) überschritten\n"
#: utils/idle_monitor/cpupower-monitor.c:250
#, c-format
msgid "No matching monitor found in %s, try -l option\n"
-msgstr ""
+msgstr "Kein passender Wächter in %s gefunden, versuchen Sie die Option -l\n"
#: utils/idle_monitor/cpupower-monitor.c:266
#, c-format
msgid "Monitor \"%s\" (%d states) - Might overflow after %u s\n"
-msgstr ""
+msgstr "Wächter \"%s\" (%d Zustände) - Könnte nach %u s überlaufen\n"
#: utils/idle_monitor/cpupower-monitor.c:319
#, c-format
msgid "%s took %.5f seconds and exited with status %d\n"
-msgstr ""
+msgstr "%s hat %.5f Sekunden gedauert und hat sich mit Status %d beendet\n"
#: utils/idle_monitor/cpupower-monitor.c:406
#, c-format
msgid "Cannot read number of available processors\n"
-msgstr ""
+msgstr "Anzahl der verfügbaren Prozessoren kann nicht gelesen werden\n"
#: utils/idle_monitor/cpupower-monitor.c:417
#, c-format
msgid "Available monitor %s needs root access\n"
-msgstr ""
+msgstr "Verfügbarer Wächter %s benötigt root-Zugriff\n"
#: utils/idle_monitor/cpupower-monitor.c:428
#, c-format
msgid "No HW Cstate monitors found\n"
-msgstr ""
+msgstr "Keine HW C-Zustandswächter gefunden\n"
#: utils/cpupower.c:78
#, c-format
msgid "cpupower [ -c cpulist ] subcommand [ARGS]\n"
-msgstr ""
+msgstr "cpupower [ -c cpulist ] Unterbefehl [ARGS]\n"
#: utils/cpupower.c:79
#, c-format
msgid "cpupower --version\n"
-msgstr ""
+msgstr "cpupower --version\n"
#: utils/cpupower.c:80
#, c-format
msgid "Supported subcommands are:\n"
-msgstr ""
+msgstr "Unterstützte Unterbefehle sind:\n"
#: utils/cpupower.c:83
#, c-format
@@ -191,11 +199,15 @@ msgid ""
"\n"
"Some subcommands can make use of the -c cpulist option.\n"
msgstr ""
+"\n"
+"Einige Unterbefehle können die Option -c cpulist verwenden.\n"
#: utils/cpupower.c:84
#, c-format
msgid "Look at the general cpupower manpage how to use it\n"
msgstr ""
+"Schauen Sie sich die allgemeine cpupower manpage an, um zu erfahren, wie man "
+"es benutzt\n"
#: utils/cpupower.c:85
#, c-format
@@ -217,30 +229,31 @@ msgstr "Bitte melden Sie Fehler an %s.\n"
#: utils/cpupower.c:114
#, c-format
msgid "Error parsing cpu list\n"
-msgstr ""
+msgstr "Fehler beim Parsen der CPU-Liste\n"
#: utils/cpupower.c:172
#, c-format
msgid "Subcommand %s needs root privileges\n"
-msgstr ""
+msgstr "Unterbefehl %s benötigt root-Rechte\n"
#: utils/cpufreq-info.c:31
#, c-format
msgid "Couldn't count the number of CPUs (%s: %s), assuming 1\n"
msgstr ""
-"Konnte nicht die Anzahl der CPUs herausfinden (%s : %s), nehme daher 1 an.\n"
+"Anzahl der CPUs konnte nicht herausgefinden werden (%s: %s), es wird daher 1 "
+"angenommen\n"
#: utils/cpufreq-info.c:63
#, c-format
msgid ""
" minimum CPU frequency - maximum CPU frequency - governor\n"
-msgstr ""
-" minimale CPU-Taktfreq. - maximale CPU-Taktfreq. - Regler \n"
+msgstr " minimale CPU-Frequenz - maximale CPU-Frequenz - Regler\n"
#: utils/cpufreq-info.c:151
#, c-format
msgid "Error while evaluating Boost Capabilities on CPU %d -- are you root?\n"
msgstr ""
+"Fehler beim Evaluieren der Boost-Fähigkeiten bei CPU %d -- sind Sie root?\n"
#. P state changes via MSR are identified via cpuid 80000007
#. on Intel and AMD, but we assume boost capable machines can do that
@@ -250,50 +263,50 @@ msgstr ""
#: utils/cpufreq-info.c:161
#, c-format
msgid " boost state support: \n"
-msgstr ""
+msgstr " Boost-Zustand-Unterstützung: \n"
#: utils/cpufreq-info.c:163
#, c-format
msgid " Supported: %s\n"
-msgstr ""
+msgstr " Unterstützt: %s\n"
#: utils/cpufreq-info.c:163 utils/cpufreq-info.c:164
msgid "yes"
-msgstr ""
+msgstr "ja"
#: utils/cpufreq-info.c:163 utils/cpufreq-info.c:164
msgid "no"
-msgstr ""
+msgstr "nein"
#: utils/cpufreq-info.c:164
-#, fuzzy, c-format
+#, c-format
msgid " Active: %s\n"
-msgstr " Treiber: %s\n"
+msgstr " Aktiv: %s\n"
#: utils/cpufreq-info.c:177
#, c-format
msgid " Boost States: %d\n"
-msgstr ""
+msgstr " Boost-Zustände: %d\n"
#: utils/cpufreq-info.c:178
#, c-format
msgid " Total States: %d\n"
-msgstr ""
+msgstr " Gesamtzustände: %d\n"
#: utils/cpufreq-info.c:181
#, c-format
msgid " Pstate-Pb%d: %luMHz (boost state)\n"
-msgstr ""
+msgstr " Pstate-Pb%d: %luMHz (Boost-Zustand)\n"
#: utils/cpufreq-info.c:184
#, c-format
msgid " Pstate-P%d: %luMHz\n"
-msgstr ""
+msgstr " Pstate-P%d: %luMHz\n"
#: utils/cpufreq-info.c:211
#, c-format
msgid " no or unknown cpufreq driver is active on this CPU\n"
-msgstr " kein oder nicht bestimmbarer cpufreq-Treiber aktiv\n"
+msgstr " kein oder ein unbekannter cpufreq-Treiber ist auf dieser CPU aktiv\n"
#: utils/cpufreq-info.c:213
#, c-format
@@ -303,12 +316,12 @@ msgstr " Treiber: %s\n"
#: utils/cpufreq-info.c:219
#, c-format
msgid " CPUs which run at the same hardware frequency: "
-msgstr " Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: "
+msgstr " CPUs, die mit der gleichen Hardwarefrequenz laufen: "
#: utils/cpufreq-info.c:230
#, c-format
msgid " CPUs which need to have their frequency coordinated by software: "
-msgstr " Die Taktfrequenz folgender CPUs werden per Software koordiniert: "
+msgstr " CPUs, die ihre Frequenz mit Software koordinieren müssen: "
#: utils/cpufreq-info.c:241
#, c-format
@@ -318,22 +331,22 @@ msgstr " Maximale Dauer eines Taktfrequenzwechsels: "
#: utils/cpufreq-info.c:247
#, c-format
msgid " hardware limits: "
-msgstr " Hardwarebedingte Grenzen der Taktfrequenz: "
+msgstr " Hardwarebegrenzungen: "
#: utils/cpufreq-info.c:256
#, c-format
msgid " available frequency steps: "
-msgstr " mögliche Taktfrequenzen: "
+msgstr " verfügbare Frequenzschritte: "
#: utils/cpufreq-info.c:269
#, c-format
msgid " available cpufreq governors: "
-msgstr " mögliche Regler: "
+msgstr " verfügbare cpufreq-Regler: "
#: utils/cpufreq-info.c:280
#, c-format
msgid " current policy: frequency should be within "
-msgstr " momentane Taktik: die Frequenz soll innerhalb "
+msgstr " momentane Richtlinie: Frequenz sollte innerhalb "
#: utils/cpufreq-info.c:282
#, c-format
@@ -346,29 +359,28 @@ msgid ""
"The governor \"%s\" may decide which speed to use\n"
" within this range.\n"
msgstr ""
-" liegen. Der Regler \"%s\" kann frei entscheiden,\n"
-" welche Taktfrequenz innerhalb dieser Grenze verwendet "
-"wird.\n"
+" sein. Der Regler \"%s\" kann frei entscheiden,\n"
+" welche Geschwindigkeit er in diesem Bereich verwendet.\n"
#: utils/cpufreq-info.c:293
#, c-format
msgid " current CPU frequency is "
-msgstr " momentane Taktfrequenz ist "
+msgstr " momentane CPU-Frequenz ist "
#: utils/cpufreq-info.c:296
#, c-format
msgid " (asserted by call to hardware)"
-msgstr " (verifiziert durch Nachfrage bei der Hardware)"
+msgstr " (durch Aufruf der Hardware sichergestellt)"
#: utils/cpufreq-info.c:304
#, c-format
msgid " cpufreq stats: "
-msgstr " Statistik:"
+msgstr " cpufreq-Statistiken: "
#: utils/cpufreq-info.c:472
-#, fuzzy, c-format
+#, c-format
msgid "Usage: cpupower freqinfo [options]\n"
-msgstr "Aufruf: cpufreq-info [Optionen]\n"
+msgstr "Aufruf: cpupower freqinfo [Optionen]\n"
#: utils/cpufreq-info.c:473 utils/cpufreq-set.c:26 utils/cpupower-set.c:23
#: utils/cpupower-info.c:22 utils/cpuidle-info.c:148
@@ -377,11 +389,9 @@ msgid "Options:\n"
msgstr "Optionen:\n"
#: utils/cpufreq-info.c:474
-#, fuzzy, c-format
+#, c-format
msgid " -e, --debug Prints out debug information [default]\n"
-msgstr ""
-" -e, --debug Erzeugt detaillierte Informationen, hilfreich\n"
-" zum Aufspüren von Fehlern\n"
+msgstr " -e, --debug Gibt Debug-Informationen aus [Standard]\n"
#: utils/cpufreq-info.c:475
#, c-format
@@ -424,7 +434,7 @@ msgstr " -p, --policy Findet die momentane Taktik heraus *\n"
#: utils/cpufreq-info.c:482
#, c-format
msgid " -g, --governors Determines available cpufreq governors *\n"
-msgstr " -g, --governors Erzeugt eine Liste mit verfügbaren Reglern *\n"
+msgstr " -g, --governors Ermittelt verfügbare cpufreq-Regler *\n"
#: utils/cpufreq-info.c:483
#, c-format
@@ -449,8 +459,7 @@ msgstr ""
#: utils/cpufreq-info.c:486
#, c-format
msgid " -s, --stats Shows cpufreq statistics if available\n"
-msgstr ""
-" -s, --stats Zeigt, sofern möglich, Statistiken über cpufreq an.\n"
+msgstr " -s, --stats Zeigt cpufreq-Statistiken an, falls vorhanden\n"
#: utils/cpufreq-info.c:487
#, c-format
@@ -464,13 +473,13 @@ msgstr ""
#: utils/cpufreq-info.c:488
#, c-format
msgid " -b, --boost Checks for turbo or boost modes *\n"
-msgstr ""
+msgstr " -b, --boost Prüft auf Turbo- oder Boost-Modi *\n"
#: utils/cpufreq-info.c:489
#, c-format
msgid ""
-" -o, --proc Prints out information like provided by the /proc/"
-"cpufreq\n"
+" -o, --proc Prints out information like provided by the "
+"/proc/cpufreq\n"
" interface in 2.4. and early 2.6. kernels\n"
msgstr ""
" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
@@ -509,8 +518,8 @@ msgid ""
"For the arguments marked with *, omitting the -c or --cpu argument is\n"
"equivalent to setting it to zero\n"
msgstr ""
-"Bei den mit * markierten Parametern wird '--cpu 0' angenommen, soweit nicht\n"
-"mittels -c oder --cpu etwas anderes angegeben wird\n"
+"Für die mit * markierten Argumente ist das Weglassen des Arguments\n"
+"-c oder --cpu gleichbedeutend mit der Einstellung auf Null\n"
#: utils/cpufreq-info.c:580
#, c-format
@@ -525,8 +534,8 @@ msgid ""
"You can't specify more than one --cpu parameter and/or\n"
"more than one output-specific argument\n"
msgstr ""
-"Man kann nicht mehr als einen --cpu-Parameter und/oder mehr als einen\n"
-"informationsspezifischen Parameter gleichzeitig angeben\n"
+"Sie können nicht mehr als einen Parameter --cpu und/oder\n"
+"mehr als ein ausgabespezifisches Argument angeben\n"
#: utils/cpufreq-info.c:600 utils/cpufreq-set.c:82 utils/cpupower-set.c:42
#: utils/cpupower-info.c:42 utils/cpuidle-info.c:213
@@ -538,17 +547,17 @@ msgstr "unbekannter oder falscher Parameter\n"
#, c-format
msgid "couldn't analyze CPU %d as it doesn't seem to be present\n"
msgstr ""
-"Konnte nicht die CPU %d analysieren, da sie (scheinbar?) nicht existiert.\n"
+"CPU %d konnte nicht analysiert werden, da sie scheinbar nicht existiert\n"
#: utils/cpufreq-info.c:620 utils/cpupower-info.c:142
#, c-format
msgid "analyzing CPU %d:\n"
-msgstr "analysiere CPU %d:\n"
+msgstr "CPU %d wird analysiert:\n"
#: utils/cpufreq-set.c:25
-#, fuzzy, c-format
+#, c-format
msgid "Usage: cpupower frequency-set [options]\n"
-msgstr "Aufruf: cpufreq-set [Optionen]\n"
+msgstr "Aufruf: cpupower frequency-set [Optionen]\n"
#: utils/cpufreq-set.c:27
#, c-format
@@ -556,7 +565,7 @@ msgid ""
" -d FREQ, --min FREQ new minimum CPU frequency the governor may "
"select\n"
msgstr ""
-" -d FREQ, --min FREQ neue minimale Taktfrequenz, die der Regler\n"
+" -d FREQ, --min FREQ neue minimale CPU-Frequenz, die der Regler\n"
" auswählen darf\n"
#: utils/cpufreq-set.c:28
@@ -571,7 +580,7 @@ msgstr ""
#: utils/cpufreq-set.c:29
#, c-format
msgid " -g GOV, --governor GOV new cpufreq governor\n"
-msgstr " -g GOV, --governors GOV wechsle zu Regler GOV\n"
+msgstr " -g GOV, --governors GOV neuer cpufreq-Regler\n"
#: utils/cpufreq-set.c:30
#, c-format
@@ -579,29 +588,29 @@ msgid ""
" -f FREQ, --freq FREQ specific frequency to be set. Requires userspace\n"
" governor to be available and loaded\n"
msgstr ""
-" -f FREQ, --freq FREQ setze exakte Taktfrequenz. Benötigt den Regler\n"
-" 'userspace'.\n"
+" -f FREQ, --freq FREQ bestimmte Frequenz, die eingestellt werden soll.\n"
+" Erfordert einen verfügbaren und geladenen "
+"userspace-Regler\n"
#: utils/cpufreq-set.c:32
#, c-format
msgid " -r, --related Switches all hardware-related CPUs\n"
-msgstr ""
-" -r, --related Setze Werte für alle CPUs, deren Taktfrequenz\n"
-" hardwarebedingt identisch ist.\n"
+msgstr " -r, --related Schaltet alle hardwarebezogenen CPUs um\n"
#: utils/cpufreq-set.c:33 utils/cpupower-set.c:28 utils/cpupower-info.c:27
#, c-format
msgid " -h, --help Prints out this screen\n"
-msgstr " -h, --help Gibt diese Kurzübersicht aus\n"
+msgstr " -h, --help Gibt diesen Bildschirm aus\n"
#: utils/cpufreq-set.c:35
-#, fuzzy, c-format
+#, c-format
msgid ""
"Notes:\n"
"1. Omitting the -c or --cpu argument is equivalent to setting it to \"all\"\n"
msgstr ""
-"Bei den mit * markierten Parametern wird '--cpu 0' angenommen, soweit nicht\n"
-"mittels -c oder --cpu etwas anderes angegeben wird\n"
+"Hinweis:\n"
+"1. Das Weglassen des Arguments -c oder --cpu ist gleichbedeutend mit der "
+"Einstellung auf \"all\"\n"
#: utils/cpufreq-set.c:37
#, fuzzy, c-format
@@ -636,17 +645,21 @@ msgid ""
"frequency\n"
" or because the userspace governor isn't loaded?\n"
msgstr ""
-"Beim Einstellen ist ein Fehler aufgetreten. Typische Fehlerquellen sind:\n"
-"- nicht ausreichende Rechte (Administrator)\n"
-"- der Regler ist nicht verfügbar bzw. nicht geladen\n"
-"- die angegebene Taktik ist inkorrekt\n"
-"- eine spezifische Frequenz wurde angegeben, aber der Regler 'userspace'\n"
-" kann entweder hardwarebedingt nicht genutzt werden oder ist nicht geladen\n"
+"Fehler beim Festlegen neuer Werte. Häufige Fehler:\n"
+"- Verfügen Sie über die erforderlichen Administrationsrechte? (Superuser?)\n"
+"- Ist der von Ihnen gewünschte Regler verfügbar und mittels modprobe "
+"geladen?\n"
+"- Versuchen Sie eine ungültige Richtlinie festzulegen?\n"
+"- Versuchen Sie eine bestimmte Frequenz festzulegen, aber der "
+"userspace-Regler ist nicht verfügbar,\n"
+" z.B. wegen Hardware, die nicht auf eine bestimmte Frequenz eingestellt "
+"werden kann\n"
+" oder weil der userspace-Regler nicht geladen ist?\n"
#: utils/cpufreq-set.c:170
#, c-format
msgid "wrong, unknown or unhandled CPU?\n"
-msgstr "unbekannte oder nicht regelbare CPU\n"
+msgstr "falsche, unbekannte oder nicht regelbare CPU?\n"
#: utils/cpufreq-set.c:302
#, c-format
@@ -654,8 +667,8 @@ msgid ""
"the -f/--freq parameter cannot be combined with -d/--min, -u/--max or\n"
"-g/--governor parameters\n"
msgstr ""
-"Der -f bzw. --freq-Parameter kann nicht mit den Parametern -d/--min, -u/--"
-"max\n"
+"Der -f bzw. --freq-Parameter kann nicht mit den Parametern -d/--min, "
+"-u/--max\n"
"oder -g/--governor kombiniert werden\n"
#: utils/cpufreq-set.c:308
@@ -664,18 +677,18 @@ msgid ""
"At least one parameter out of -f/--freq, -d/--min, -u/--max, and\n"
"-g/--governor must be passed\n"
msgstr ""
-"Es muss mindestens ein Parameter aus -f/--freq, -d/--min, -u/--max oder\n"
-"-g/--governor angegeben werden.\n"
+"Mindestens ein Parameter aus -f/--freq, -d/--min, -u/--max und\n"
+"-g/--governor muss übergeben werden\n"
#: utils/cpufreq-set.c:347
#, c-format
msgid "Setting cpu: %d\n"
-msgstr ""
+msgstr "CPU einstellen: %d\n"
#: utils/cpupower-set.c:22
#, c-format
msgid "Usage: cpupower set [ -b val ] [ -m val ] [ -s val ]\n"
-msgstr ""
+msgstr "Aufruf: cpupower set [ -b val ] [ -m val ] [ -s val ]\n"
#: utils/cpupower-set.c:24
#, c-format
@@ -689,6 +702,8 @@ msgstr ""
msgid ""
" -m, --sched-mc [VAL] Sets the kernel's multi core scheduler policy.\n"
msgstr ""
+" -m, --sched-mc [VAL] Legt die Mehrkern-Scheduler-Richtlinie des "
+"Kernels fest.\n"
#: utils/cpupower-set.c:27
#, c-format
@@ -700,37 +715,37 @@ msgstr ""
#: utils/cpupower-set.c:80
#, c-format
msgid "--perf-bias param out of range [0-%d]\n"
-msgstr ""
+msgstr "--perf-bias-Parameter außerhalb des Bereichs [0-%d]\n"
#: utils/cpupower-set.c:91
#, c-format
msgid "--sched-mc param out of range [0-%d]\n"
-msgstr ""
+msgstr "Parameter --sched-mc außerhalb des Bereichs [0-%d]\n"
#: utils/cpupower-set.c:102
#, c-format
msgid "--sched-smt param out of range [0-%d]\n"
-msgstr ""
+msgstr "Parameter --sched-smt außerhalb des Bereichs [0-%d]\n"
#: utils/cpupower-set.c:121
#, c-format
msgid "Error setting sched-mc %s\n"
-msgstr ""
+msgstr "Fehler beim Einstellen von sched-mc %s\n"
#: utils/cpupower-set.c:127
#, c-format
msgid "Error setting sched-smt %s\n"
-msgstr ""
+msgstr "Fehler beim Einstellen von sched-smt %s\n"
#: utils/cpupower-set.c:146
#, c-format
msgid "Error setting perf-bias value on CPU %d\n"
-msgstr ""
+msgstr "Fehler beim Einstellen des perf-bias-Wertes auf der CPU %d\n"
#: utils/cpupower-info.c:21
#, c-format
msgid "Usage: cpupower info [ -b ] [ -m ] [ -s ]\n"
-msgstr ""
+msgstr "Aufruf: cpupower info [ -b ] [ -m ] [ -s ]\n"
#: utils/cpupower-info.c:23
#, c-format
@@ -740,9 +755,10 @@ msgid ""
msgstr ""
#: utils/cpupower-info.c:25
-#, fuzzy, c-format
+#, c-format
msgid " -m, --sched-mc Gets the kernel's multi core scheduler policy.\n"
-msgstr " -p, --policy Findet die momentane Taktik heraus *\n"
+msgstr ""
+" -m, --sched-mc Ruft die Mehrkern-Scheduler-Richtlinie des Kernels ab.\n"
#: utils/cpupower-info.c:26
#, c-format
@@ -756,17 +772,20 @@ msgid ""
"\n"
"Passing no option will show all info, by default only on core 0\n"
msgstr ""
+"\n"
+"Wenn Sie keine Option übergeben, werden alle Informationen angezeigt, "
+"standardmäßig nur auf Kern 0\n"
#: utils/cpupower-info.c:102
#, c-format
msgid "System's multi core scheduler setting: "
-msgstr ""
+msgstr "Mehrkern-Scheduler-Einstellung des Systems: "
#. if sysfs file is missing it's: errno == ENOENT
#: utils/cpupower-info.c:105 utils/cpupower-info.c:114
#, c-format
msgid "not supported\n"
-msgstr ""
+msgstr "nicht unterstützt\n"
#: utils/cpupower-info.c:111
#, c-format
@@ -786,164 +805,161 @@ msgstr ""
#: utils/cpupower-info.c:147
#, c-format
msgid "Could not read perf-bias value\n"
-msgstr ""
+msgstr "perf-bias-Wert konnte nicht gelesen werden\n"
#: utils/cpupower-info.c:150
#, c-format
msgid "perf-bias: %d\n"
-msgstr ""
+msgstr "perf-bias: %d\n"
#: utils/cpuidle-info.c:28
-#, fuzzy, c-format
+#, c-format
msgid "Analyzing CPU %d:\n"
-msgstr "analysiere CPU %d:\n"
+msgstr "CPU %d wird analysiert:\n"
#: utils/cpuidle-info.c:32
#, c-format
msgid "CPU %u: No idle states\n"
-msgstr ""
+msgstr "CPU %u: Keine Ruhezustände\n"
#: utils/cpuidle-info.c:36
#, c-format
msgid "CPU %u: Can't read idle state info\n"
-msgstr ""
+msgstr "CPU %u: Ruhezustands-Informationen können nicht gelesen werden\n"
#: utils/cpuidle-info.c:41
#, c-format
msgid "Could not determine max idle state %u\n"
-msgstr ""
+msgstr "Max. Ruhezustand %u konnte nicht bestimmt werden\n"
#: utils/cpuidle-info.c:46
#, c-format
msgid "Number of idle states: %d\n"
-msgstr ""
+msgstr "Anzahl der Ruhezustände: %d\n"
#: utils/cpuidle-info.c:48
-#, fuzzy, c-format
+#, c-format
msgid "Available idle states:"
-msgstr " mögliche Taktfrequenzen: "
+msgstr "Verfügbare Ruhezustände:"
#: utils/cpuidle-info.c:71
#, c-format
msgid "Flags/Description: %s\n"
-msgstr ""
+msgstr "Merker/Beschreibung: %s\n"
#: utils/cpuidle-info.c:74
#, c-format
msgid "Latency: %lu\n"
-msgstr ""
+msgstr "Latenz: %lu\n"
#: utils/cpuidle-info.c:76
#, c-format
msgid "Usage: %lu\n"
-msgstr ""
+msgstr "Aufruf: %lu\n"
#: utils/cpuidle-info.c:78
#, c-format
msgid "Duration: %llu\n"
-msgstr ""
+msgstr "Dauer: %llu\n"
#: utils/cpuidle-info.c:90
#, c-format
msgid "Could not determine cpuidle driver\n"
-msgstr ""
+msgstr "cpuidle-Treiber konnte nicht bestimmt werden\n"
#: utils/cpuidle-info.c:94
-#, fuzzy, c-format
+#, c-format
msgid "CPUidle driver: %s\n"
-msgstr " Treiber: %s\n"
+msgstr "CPUidle-Treiber: %s\n"
#: utils/cpuidle-info.c:99
#, c-format
msgid "Could not determine cpuidle governor\n"
-msgstr ""
+msgstr "cpuidle-Regler konnte nicht bestimmt werden\n"
#: utils/cpuidle-info.c:103
#, c-format
msgid "CPUidle governor: %s\n"
-msgstr ""
+msgstr "CPUidle-Regler: %s\n"
#: utils/cpuidle-info.c:122
#, c-format
msgid "CPU %u: Can't read C-state info\n"
-msgstr ""
+msgstr "CPU %u: C-Zustands-Informationen können nicht gelesen werden\n"
#. printf("Cstates: %d\n", cstates);
#: utils/cpuidle-info.c:127
#, c-format
msgid "active state: C0\n"
-msgstr ""
+msgstr "aktiver Zustand: C0\n"
#: utils/cpuidle-info.c:128
#, c-format
msgid "max_cstate: C%u\n"
-msgstr ""
+msgstr "max_cstate: C%u\n"
#: utils/cpuidle-info.c:129
-#, fuzzy, c-format
+#, c-format
msgid "maximum allowed latency: %lu usec\n"
-msgstr " Maximale Dauer eines Taktfrequenzwechsels: "
+msgstr "maximal erlaubte Latenz: %lu usec\n"
#: utils/cpuidle-info.c:130
#, c-format
msgid "states:\t\n"
-msgstr ""
+msgstr "Zustände:\t\n"
#: utils/cpuidle-info.c:132
#, c-format
msgid " C%d: type[C%d] "
-msgstr ""
+msgstr " C%d: Typ[C%d] "
#: utils/cpuidle-info.c:134
#, c-format
msgid "promotion[--] demotion[--] "
-msgstr ""
+msgstr "promotion[--] demotion[--] "
#: utils/cpuidle-info.c:135
#, c-format
msgid "latency[%03lu] "
-msgstr ""
+msgstr "Latenz[%03lu] "
#: utils/cpuidle-info.c:137
#, c-format
msgid "usage[%08lu] "
-msgstr ""
+msgstr "Aufruf[%08lu] "
#: utils/cpuidle-info.c:139
#, c-format
msgid "duration[%020Lu] \n"
-msgstr ""
+msgstr "Dauer[%020Lu] \n"
#: utils/cpuidle-info.c:147
-#, fuzzy, c-format
+#, c-format
msgid "Usage: cpupower idleinfo [options]\n"
-msgstr "Aufruf: cpufreq-info [Optionen]\n"
+msgstr "Aufruf: cpupower idleinfo [Optionen]\n"
#: utils/cpuidle-info.c:149
-#, fuzzy, c-format
+#, c-format
msgid " -s, --silent Only show general C-state information\n"
msgstr ""
-" -e, --debug Erzeugt detaillierte Informationen, hilfreich\n"
-" zum Aufspüren von Fehlern\n"
+" -s, --silent Nur allgemeine C-Zustands-Informationen anzeigen\n"
#: utils/cpuidle-info.c:150
-#, fuzzy, c-format
+#, c-format
msgid ""
-" -o, --proc Prints out information like provided by the /proc/"
-"acpi/processor/*/power\n"
+" -o, --proc Prints out information like provided by the "
+"/proc/acpi/processor/*/power\n"
" interface in older kernels\n"
msgstr ""
-" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
-"dem\n"
-" der /proc/cpufreq-Datei in 2.4. und frühen 2.6.\n"
-" Kernel-Versionen\n"
+" -o, --proc Gibt Informationen so aus, wie sie von der "
+"Schnittstelle\n"
+" /proc/acpi/processor/*/power in älteren Kerneln "
+"bereitgestellt werden\n"
#: utils/cpuidle-info.c:209
-#, fuzzy, c-format
+#, c-format
msgid "You can't specify more than one output-specific argument\n"
-msgstr ""
-"Man kann nicht mehr als einen --cpu-Parameter und/oder mehr als einen\n"
-"informationsspezifischen Parameter gleichzeitig angeben\n"
+msgstr "Sie können nicht mehr als ein ausgabenspezifisches Argument angeben\n"
#~ msgid ""
#~ " -c CPU, --cpu CPU CPU number which information shall be determined "
@@ -956,6 +972,6 @@ msgstr ""
#~ " -c CPU, --cpu CPU number of CPU where cpufreq settings shall be "
#~ "modified\n"
#~ msgstr ""
-#~ " -c CPU, --cpu CPU Nummer der CPU, deren Taktfrequenz-"
-#~ "Einstellung\n"
+#~ " -c CPU, --cpu CPU Nummer der CPU, deren "
+#~ "Taktfrequenz-Einstellung\n"
#~ " werden soll\n"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V34 10/29] hibernate: Disable when the kernel is locked down
From: Jiri Kosina @ 2019-06-24 13:21 UTC (permalink / raw)
To: Pavel Machek
Cc: Matthew Garrett, jmorris, linux-security-module, linux-kernel,
linux-api, Josh Boyer, David Howells, Matthew Garrett, rjw,
Joey Lee, linux-pm
In-Reply-To: <20190622175208.GB30317@amd>
On Sat, 22 Jun 2019, Pavel Machek wrote:
> > There is currently no way to verify the resume image when returning
> > from hibernate. This might compromise the signed modules trust model,
> > so until we can work with signed hibernate images we disable it when the
> > kernel is locked down.
>
> I keep getting these...
>
> IIRC suse has patches to verify the images.
Yeah, Joey Lee is taking care of those. CCing.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v2 2/2] thermal/drivers/cpu_cooling: Unregister with the policy
From: Daniel Lezcano @ 2019-06-24 13:17 UTC (permalink / raw)
To: viresh.kumar
Cc: rjw, edubezval, linux-kernel, Sudeep Holla, Amit Daniel Kachhap,
Javi Merino, Zhang Rui, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, Keerthy,
open list:CPU FREQUENCY DRIVERS - ARM BIG LITTLE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:TI BANDGAP AND THERMAL DRIVER
In-Reply-To: <20190624131715.1857-1-daniel.lezcano@linaro.org>
Currently the function cpufreq_cooling_register() returns a cooling
device pointer which is used back as a pointer to call the function
cpufreq_cooling_unregister(). Even if it is correct, it would make
sense to not leak the structure inside a cpufreq driver and keep the
code thermal code self-encapsulate. Moreover, that forces to add an
extra variable in each driver using this function.
Instead of passing the cooling device to unregister, pass the policy.
Because the cpufreq_cooling_unregister() function uses the policy to
unregister itself. The only purpose of the cooling device pointer is
to unregister the cpu cooling device.
As there is no more need of this pointer, remove it.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/arm_big_little.c | 9 +++------
drivers/cpufreq/cpufreq.c | 10 ++++------
drivers/thermal/cpu_cooling.c | 18 ++++++++++--------
drivers/thermal/imx_thermal.c | 12 ++++++------
.../thermal/ti-soc-thermal/ti-thermal-common.c | 10 +++++-----
include/linux/cpu_cooling.h | 6 +++---
include/linux/cpufreq.h | 3 ---
7 files changed, 31 insertions(+), 37 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 7fe52fcddcf1..718c63231e66 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -56,7 +56,6 @@ static bool bL_switching_enabled;
#define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 : freq)
#define VIRT_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq >> 1 : freq)
-static struct thermal_cooling_device *cdev[MAX_CLUSTERS];
static const struct cpufreq_arm_bL_ops *arm_bL_ops;
static struct clk *clk[MAX_CLUSTERS];
static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
@@ -501,10 +500,8 @@ static int bL_cpufreq_exit(struct cpufreq_policy *policy)
struct device *cpu_dev;
int cur_cluster = cpu_to_cluster(policy->cpu);
- if (cur_cluster < MAX_CLUSTERS) {
- cpufreq_cooling_unregister(cdev[cur_cluster]);
- cdev[cur_cluster] = NULL;
- }
+ if (cur_cluster < MAX_CLUSTERS)
+ cpufreq_cooling_unregister(policy);
cpu_dev = get_cpu_device(policy->cpu);
if (!cpu_dev) {
@@ -527,7 +524,7 @@ static void bL_cpufreq_ready(struct cpufreq_policy *policy)
if (cur_cluster >= MAX_CLUSTERS)
return;
- cdev[cur_cluster] = of_cpufreq_cooling_register(policy);
+ of_cpufreq_cooling_register(policy);
}
static struct cpufreq_driver bL_cpufreq_driver = {
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index aee024e42618..f07454249fbc 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1379,8 +1379,8 @@ static int cpufreq_online(unsigned int cpu)
cpufreq_driver->ready(policy);
if (cpufreq_thermal_control_enabled(cpufreq_driver))
- policy->cdev = of_cpufreq_cooling_register(policy);
-
+ of_cpufreq_cooling_register(policy);
+
pr_debug("initialization complete\n");
return 0;
@@ -1468,10 +1468,8 @@ static int cpufreq_offline(unsigned int cpu)
goto unlock;
}
- if (cpufreq_thermal_control_enabled(cpufreq_driver)) {
- cpufreq_cooling_unregister(policy->cdev);
- policy->cdev = NULL;
- }
+ if (cpufreq_thermal_control_enabled(cpufreq_driver))
+ cpufreq_cooling_unregister(policy);
if (cpufreq_driver->stop_cpu)
cpufreq_driver->stop_cpu(policy);
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 83486775e593..007c7c6bf845 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -78,6 +78,7 @@ struct cpufreq_cooling_device {
struct cpufreq_policy *policy;
struct list_head node;
struct time_in_idle *idle_time;
+ struct thermal_cooling_device *cdev;
};
static DEFINE_IDA(cpufreq_ida);
@@ -606,6 +607,7 @@ __cpufreq_cooling_register(struct device_node *np,
goto remove_ida;
cpufreq_cdev->clipped_freq = get_state_freq(cpufreq_cdev, 0);
+ cpufreq_cdev->cdev = cdev;
mutex_lock(&cooling_list_lock);
/* Register the notifier for first cpufreq cooling device */
@@ -699,18 +701,18 @@ EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
*
* This interface function unregisters the "thermal-cpufreq-%x" cooling device.
*/
-void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+void cpufreq_cooling_unregister(struct cpufreq_policy *policy)
{
struct cpufreq_cooling_device *cpufreq_cdev;
bool last;
- if (!cdev)
- return;
-
- cpufreq_cdev = cdev->devdata;
-
mutex_lock(&cooling_list_lock);
- list_del(&cpufreq_cdev->node);
+ list_for_each_entry(cpufreq_cdev, &cpufreq_cdev_list, node) {
+ if (cpufreq_cdev->policy == policy) {
+ list_del(&cpufreq_cdev->node);
+ break;
+ }
+ }
/* Unregister the notifier for the last cpufreq cooling device */
last = list_empty(&cpufreq_cdev_list);
mutex_unlock(&cooling_list_lock);
@@ -719,7 +721,7 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
cpufreq_unregister_notifier(&thermal_cpufreq_notifier_block,
CPUFREQ_POLICY_NOTIFIER);
- thermal_cooling_device_unregister(cdev);
+ thermal_cooling_device_unregister(cpufreq_cdev->cdev);
ida_simple_remove(&cpufreq_ida, cpufreq_cdev->id);
kfree(cpufreq_cdev->idle_time);
kfree(cpufreq_cdev);
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index bb6754a5342c..021c0948b740 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -203,7 +203,6 @@ static struct thermal_soc_data thermal_imx7d_data = {
struct imx_thermal_data {
struct cpufreq_policy *policy;
struct thermal_zone_device *tz;
- struct thermal_cooling_device *cdev;
enum thermal_device_mode mode;
struct regmap *tempmon;
u32 c1, c2; /* See formula in imx_init_calib() */
@@ -656,6 +655,7 @@ MODULE_DEVICE_TABLE(of, of_imx_thermal_match);
static int imx_thermal_register_legacy_cooling(struct imx_thermal_data *data)
{
struct device_node *np;
+ struct thermal_cooling_device *cdev;
int ret;
data->policy = cpufreq_cpu_get(0);
@@ -667,9 +667,9 @@ static int imx_thermal_register_legacy_cooling(struct imx_thermal_data *data)
np = of_get_cpu_node(data->policy->cpu, NULL);
if (!np || !of_find_property(np, "#cooling-cells", NULL)) {
- data->cdev = cpufreq_cooling_register(data->policy);
- if (IS_ERR(data->cdev)) {
- ret = PTR_ERR(data->cdev);
+ cdev = cpufreq_cooling_register(data->policy);
+ if (IS_ERR(cdev)) {
+ ret = PTR_ERR(cdev);
cpufreq_cpu_put(data->policy);
return ret;
}
@@ -680,7 +680,7 @@ static int imx_thermal_register_legacy_cooling(struct imx_thermal_data *data)
static void imx_thermal_unregister_legacy_cooling(struct imx_thermal_data *data)
{
- cpufreq_cooling_unregister(data->cdev);
+ cpufreq_cooling_unregister(data->policy);
cpufreq_cpu_put(data->policy);
}
@@ -872,7 +872,7 @@ static int imx_thermal_remove(struct platform_device *pdev)
clk_disable_unprepare(data->thermal_clk);
thermal_zone_device_unregister(data->tz);
- cpufreq_cooling_unregister(data->cdev);
+ cpufreq_cooling_unregister(data->policy);
cpufreq_cpu_put(data->policy);
return 0;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index b4f981daeaf2..170b70b6ec61 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -41,7 +41,6 @@ struct ti_thermal_data {
struct cpufreq_policy *policy;
struct thermal_zone_device *ti_thermal;
struct thermal_zone_device *pcb_tz;
- struct thermal_cooling_device *cool_dev;
struct ti_bandgap *bgp;
enum thermal_device_mode mode;
struct work_struct thermal_wq;
@@ -233,6 +232,7 @@ int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
{
struct ti_thermal_data *data;
struct device_node *np = bgp->dev->of_node;
+ struct thermal_cooling_device *cdev;
/*
* We are assuming here that if one deploys the zone
@@ -256,9 +256,9 @@ int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
}
/* Register cooling device */
- data->cool_dev = cpufreq_cooling_register(data->policy);
- if (IS_ERR(data->cool_dev)) {
- int ret = PTR_ERR(data->cool_dev);
+ cdev = cpufreq_cooling_register(data->policy);
+ if (IS_ERR(cdev)) {
+ int ret = PTR_ERR(cdev);
dev_err(bgp->dev, "Failed to register cpu cooling device %d\n",
ret);
cpufreq_cpu_put(data->policy);
@@ -277,7 +277,7 @@ int ti_thermal_unregister_cpu_cooling(struct ti_bandgap *bgp, int id)
data = ti_bandgap_get_sensor_data(bgp, id);
if (data) {
- cpufreq_cooling_unregister(data->cool_dev);
+ cpufreq_cooling_unregister(data->policy);
if (data->policy)
cpufreq_cpu_put(data->policy);
}
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index bae54bb7c048..89f469ee4be4 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -29,9 +29,9 @@ cpufreq_cooling_register(struct cpufreq_policy *policy);
/**
* cpufreq_cooling_unregister - function to remove cpufreq cooling device.
- * @cdev: thermal cooling device pointer.
+ * @policy: cpufreq policy
*/
-void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);
+void cpufreq_cooling_unregister(struct cpufreq_policy *policy);
#else /* !CONFIG_CPU_THERMAL */
static inline struct thermal_cooling_device *
@@ -41,7 +41,7 @@ cpufreq_cooling_register(struct cpufreq_policy *policy)
}
static inline
-void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+void cpufreq_cooling_unregister(struct cpufreq_policy *policy)
{
return;
}
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 53ec82d75565..81ac78353f79 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -144,9 +144,6 @@ struct cpufreq_policy {
/* For cpufreq driver's internal use */
void *driver_data;
-
- /* Pointer to the cooling device if used for thermal mitigation */
- struct thermal_cooling_device *cdev;
};
struct cpufreq_freqs {
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox