* Re: [RFC PATCH 6/9] dt-bindings: opp: Add qcom-opp bindings with properties needed for CPR
From: Niklas Cassel @ 2019-07-05 10:56 UTC (permalink / raw)
To: Viresh Kumar
Cc: Andy Gross, David Brown, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rob Herring, Mark Rutland, linux-arm-msm,
jorge.ramirez-ortiz, linux-pm, devicetree, linux-kernel
In-Reply-To: <20190409092352.joayvxyo77e6lehl@vireshk-i7>
On Tue, Apr 09, 2019 at 02:53:52PM +0530, Viresh Kumar wrote:
> On 04-04-19, 07:09, Niklas Cassel wrote:
> > Add qcom-opp bindings with properties needed for Core Power Reduction (CPR).
> >
> > CPR is included in a great variety of Qualcomm SoC, e.g. msm8916 and msm8996,
> > and was first introduced in msm8974.
> >
> > Co-developed-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
> > Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
> > Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> > ---
> > .../devicetree/bindings/opp/qcom-opp.txt | 24 +++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> > new file mode 100644
> > index 000000000000..d24280467db7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> > @@ -0,0 +1,24 @@
> > +Qualcomm OPP bindings to describe OPP nodes
> > +
> > +The bindings are based on top of the operating-points-v2 bindings
> > +described in Documentation/devicetree/bindings/opp/opp.txt
> > +Additional properties are described below.
> > +
> > +* OPP Table Node
> > +
> > +Required properties:
> > +- compatible: Allow OPPs to express their compatibility. It should be:
> > + "operating-points-v2-qcom-level"
> > +
> > +* OPP Node
> > +
> > +Optional properties:
> > +- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. Even
> > + though a power domain doesn't need a opp-hz, there can be devices in the
> > + power domain that need to know the highest supported frequency for each
> > + corner/level (e.g. CPR), in order to properly initialize the hardware.
> > +
> > +- qcom,opp-fuse-level: A positive value representing the fuse corner/level
> > + associated with this OPP node. Sometimes several corners/levels shares
> > + a certain fuse corner/level. A fuse corner/level contains e.g. ref uV,
> > + min uV, and max uV.
>
> I know we discussed this sometime back and so you implemented it this way.
>
> Looking at the implementation of the CPR driver, I now wonder if that was a good
> choice. Technically a single domain can manage many devices, a big and a little
> CPU for example and then we will have different highest frequencies for both of
> them. How will we configure the CPR hardware in such a case ? Isn't the
> programming per-device ?
Hello Viresh,
I just posted this RFC as a real patch series:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=142447
Note that I disregarded your review comment above, because
this patch series only adds support for CPRv2, which is used
in e.g. msm8916 and qcs404.
There does not exist any QCOM SoC with CPRv2 for big little.
For big little, there is CPRv3, which is very different from CPRv2.
CPRv3 will require new and more complex DT bindings.
Right now we don't even have plans to upstream a driver for CPRv3.
Part of the reason is that CPR, for newer QCOM SoCs like sdm845,
is now performed automatically by the Operating State Manager (OSM),
for which we already have a kernel driver: drivers/cpufreq/qcom-cpufreq-hw.c
Kind regards,
Niklas
^ permalink raw reply
* Re: linux-next boot error: WARNING in corrupted
From: Dmitry Vyukov @ 2019-07-05 11:09 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, syzbot, Greg Kroah-Hartman, Len Brown, LKML,
linux-pm, Pavel Machek, syzkaller-bugs
In-Reply-To: <20190705105442.kpvvyxakpa6mrxlu@vireshk-i7>
On Fri, Jul 5, 2019 at 12:54 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 05-07-19, 16:11, Viresh Kumar wrote:
> > This fixes it for me (after faking the failure). @Rafael this needs to
> > be merged to the top commit:
> >
> > 0d4c2a013b32 cpufreq: Add QoS requests for userspace constraints
>
> @Rafael: I have sent V7 of this patch now after merging below diff
> (and improving it further). Thanks.
Please include:
Tested-by: syzbot+de771ae9390dffed7266@syzkaller.appspotmail.com
into the commit, or it will be messy to resolve this bug later.
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 13c2f119cc0c..5eecd54195a9 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -1228,12 +1228,6 @@ static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
> > goto err_min_qos_notifier;
> > }
> >
> > - policy->min_freq_req = kzalloc(2 * sizeof(*policy->min_freq_req),
> > - GFP_KERNEL);
> > - if (!policy->min_freq_req)
> > - goto err_max_qos_notifier;
> > -
> > - policy->max_freq_req = policy->min_freq_req + 1;
> > INIT_LIST_HEAD(&policy->policy_list);
> > init_rwsem(&policy->rwsem);
> > spin_lock_init(&policy->transition_lock);
> > @@ -1244,9 +1238,6 @@ static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
> > policy->cpu = cpu;
> > return policy;
> >
> > -err_max_qos_notifier:
> > - dev_pm_qos_remove_notifier(dev, &policy->nb_max,
> > - DEV_PM_QOS_MAX_FREQUENCY);
> > err_min_qos_notifier:
> > dev_pm_qos_remove_notifier(dev, &policy->nb_min,
> > DEV_PM_QOS_MIN_FREQUENCY);
> > @@ -1370,6 +1361,13 @@ static int cpufreq_online(unsigned int cpu)
> > add_cpu_dev_symlink(policy, j);
> > }
> >
> > + policy->min_freq_req = kzalloc(2 * sizeof(*policy->min_freq_req),
> > + GFP_KERNEL);
> > + if (!policy->min_freq_req)
> > + goto out_destroy_policy;
> > +
> > + policy->max_freq_req = policy->min_freq_req + 1;
> > +
> > ret = dev_pm_qos_add_request(dev, policy->min_freq_req,
> > DEV_PM_QOS_MIN_FREQUENCY,
> > policy->min);
>
> --
> viresh
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20190705105442.kpvvyxakpa6mrxlu%40vireshk-i7.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH V7 7/7] cpufreq: Add QoS requests for userspace constraints
From: Rafael J. Wysocki @ 2019-07-05 11:17 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Linux PM, Vincent Guittot, Matthias Kaehlcke,
Ulf Hansson, Rafael J . Wysocki, Linux Kernel Mailing List
In-Reply-To: <7589f158a5522ff04ba2b63daca77bcdd4952f74.1562323803.git.viresh.kumar@linaro.org>
On Fri, Jul 5, 2019 at 12:52 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> This implements QoS requests to manage userspace configuration of min
> and max frequency.
>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> V6->V7:
> - We can't call dev_pm_qos_remove_request() for a request which was
> never added. This happened in one of the error paths. Fixed that by
> allocating the requests only right before we try to add them and also
> take care of things properly during errors.
>
> @Rafael: Please apply this version instead of the diff I supplied on the
> WARN email earlier. This has proper protection in place at many places.
Applied, thanks!
^ permalink raw reply
* Re: iowait v.s. idle accounting is "inconsistent" - iowait is too low
From: Alan Jenkins @ 2019-07-05 11:25 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra, linux-kernel; +Cc: Doug Smythies, linux-pm
In-Reply-To: <000001d531a8$8931b2a0$9b9517e0$@net>
Hi, scheduler experts!
My cpu "iowait" time appears to be reported incorrectly. Do you know
why this could happen?
Doug helped me - it was he who noticed different behaviour on v4.15 vs
v4.16 vs v4.17+. So I have some confirmation of this. I don't think
Doug mentioned what hardware he ran the kernels on. lscpu says my
hardware is "Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz".
I tested using "dd" :-
dd if=bigfile bs=1M iflag=direct of=/dev/null
(1) E.g. I get the expected result if I pin "dd" to the "right" cpu.
Which cpu varies; it has often been cpu2. At the moment I have booted
5.2-rc5-ish. Here I run "dd" with "taskset -c 0", and "iowait" worked
as expected:
top - 11:01:47 up 15:10, 2 users, load average: 1.07, 0.86, 0.86
Tasks: 288 total, 1 running, 287 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.3 us, 3.3 sy, 0.0 ni, 0.0 id, 94.3 wa, 0.7 hi, 1.3 si, 0.0 st
%Cpu1 : 0.3 us, 0.7 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
%Cpu2 : 1.0 us, 0.7 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
%Cpu3 : 0.7 us, 0.3 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 7854.0 total, 432.2 free, 4616.4 used, 2805.4 buff/cache
MiB Swap: 2048.0 total, 1978.2 free, 69.8 used. 2498.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31849 alan-sy+ 20 0 216052 2836 1800 D 3.0 0.0 0:00.58 dd
24220 alan-sy+ 20 0 3339828 232160 126720 S 0.7 2.9 1:53.14 gnome-shell
...
(I have also used "atop" and "vmstat 3". "atop" shows both total and
per-cpu iowait, idle, etc. "vmstat 3" just shows a total, but all the
old values stay on-screen).
(2) But compare running "dd" with "taskset -c 1":
%Cpu0 : 0.3 us, 0.3 sy, 0.0 ni, 97.3 id, 0.0 wa, 0.7 hi, 1.3 si, 0.0 st
%Cpu1 : 0.3 us, 3.0 sy, 0.0 ni, 83.7 id, 12.6 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu2 : 1.0 us, 0.3 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 1.3 us, 0.7 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
(3) If I don't use "taskset", "dd" generally doesn't sit on the
"right" cpu, and so I get don't see the right "iowait". Here's "top -d
30". Over this longer interval, "dd" appears to spend a quarter of its
time on the "right" cpu:
%Cpu0 : 0.5 us, 1.2 sy, 0.0 ni, 74.4 id, 22.2 wa, 0.5 hi, 1.3 si, 0.0 st
%Cpu1 : 0.7 us, 1.3 sy, 0.0 ni, 92.3 id, 5.7 wa, 0.1 hi, 0.0 si, 0.0 st
%Cpu2 : 0.5 us, 0.9 sy, 0.0 ni, 95.1 id, 3.3 wa, 0.1 hi, 0.0 si, 0.0 st
%Cpu3 : 0.7 us, 0.9 sy, 0.0 ni, 94.6 id, 3.6 wa, 0.1 hi, 0.0 si, 0.0 st
This point (3) does not apply to 4.15. On 4.15, it seems "dd" naturally
sits on the "right" cpu, so I get the "right" iowait". But if I pin "dd"
to a different cpu, I get the "wrong" iowait again.
I bisected 4.15-4.16. The first "bad" commit was 806486c377e3
"sched/fair: Do not migrate if the prev_cpu is idle"
(4) I can get the "right" iowait regardless of which cpu, if I boot
with "nohz=off", or if I suppress nohz by dynamically disabling all
cpuidle states except for state0 (POLL).
This point (4) does not apply to 4.16. On 4.15 and 4.16, suppressing
nohz does not help. (So far, I did not test 4.15).
I bisected 4.16-4.17. The first "new" commit was 554c8aa8ecad "sched:
idle: Select idle state before stopping the tick"
(5) I seem to get the "right" iowait regardless of which cpu, if I run
inside a virtual machine. I tested stock Fedora v5.1.? inside a KVM
(virt-manager) virtual machine, which also had 4 cpus. Whereas
un-virtualized Fedora v5.1.? on my laptop, behaves as per points 1-4.
I read the documented limitations for "iowait" time. As far as I
understand them, they don't explain such inconsistent values.
> - iowait: In a word, iowait stands for waiting for I/O to complete. But there
> are several problems:
>
> 1. Cpu will not wait for I/O to complete, iowait is the time that a task is
> waiting for I/O to complete. When cpu goes into idle state for
> outstanding task io, another task will be scheduled on this CPU.
>
> 2. In a multi-core CPU, the task waiting for I/O to complete is not running
> on any CPU, so the iowait of each CPU is difficult to calculate.
>
> 3. The value of iowait field in /proc/stat will decrease in certain
> conditions
Thanks for all the kernels
Alan
^ permalink raw reply
* Re: iowait v.s. idle accounting is "inconsistent" - iowait is too low
From: Peter Zijlstra @ 2019-07-05 11:38 UTC (permalink / raw)
To: Alan Jenkins; +Cc: Ingo Molnar, linux-kernel, Doug Smythies, linux-pm
In-Reply-To: <e82b9d7c-81e5-dd80-b9c0-f5f065344e2f@gmail.com>
On Fri, Jul 05, 2019 at 12:25:46PM +0100, Alan Jenkins wrote:
> Hi, scheduler experts!
>
> My cpu "iowait" time appears to be reported incorrectly. Do you know why
> this could happen?
Because iowait is a magic random number that has no sane meaning.
Personally I'd prefer to just delete the whole thing, except ABI :/
Also see the comment near nr_iowait():
/*
* IO-wait accounting, and how its mostly bollocks (on SMP).
*
* The idea behind IO-wait account is to account the idle time that we could
* have spend running if it were not for IO. That is, if we were to improve the
* storage performance, we'd have a proportional reduction in IO-wait time.
*
* This all works nicely on UP, where, when a task blocks on IO, we account
* idle time as IO-wait, because if the storage were faster, it could've been
* running and we'd not be idle.
*
* This has been extended to SMP, by doing the same for each CPU. This however
* is broken.
*
* Imagine for instance the case where two tasks block on one CPU, only the one
* CPU will have IO-wait accounted, while the other has regular idle. Even
* though, if the storage were faster, both could've ran at the same time,
* utilising both CPUs.
*
* This means, that when looking globally, the current IO-wait accounting on
* SMP is a lower bound, by reason of under accounting.
*
* Worse, since the numbers are provided per CPU, they are sometimes
* interpreted per CPU, and that is nonsensical. A blocked task isn't strictly
* associated with any one particular CPU, it can wake to another CPU than it
* blocked on. This means the per CPU IO-wait number is meaningless.
*
* Task CPU affinities can make all that even more 'interesting'.
*/
^ permalink raw reply
* [PATCH] power: supply: bq25890_charger: Add the BQ25895 part
From: Angus Ainslie (Purism) @ 2019-07-05 11:37 UTC (permalink / raw)
To: angus.ainslie
Cc: krzk, Sebastian Reichel, linux-pm, linux-kernel,
Angus Ainslie (Purism)
The BQ25895 is almost identical to the BQ25890.
Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
---
drivers/power/supply/bq25890_charger.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/power/supply/bq25890_charger.c b/drivers/power/supply/bq25890_charger.c
index d333f2b321b9..9d1ec8d677de 100644
--- a/drivers/power/supply/bq25890_charger.c
+++ b/drivers/power/supply/bq25890_charger.c
@@ -22,6 +22,7 @@
#define BQ25890_IRQ_PIN "bq25890_irq"
#define BQ25890_ID 3
+#define BQ25895_ID 7
#define BQ25896_ID 0
enum bq25890_fields {
@@ -171,7 +172,7 @@ static const struct reg_field bq25890_reg_fields[] = {
[F_WD] = REG_FIELD(0x07, 4, 5),
[F_TMR_EN] = REG_FIELD(0x07, 3, 3),
[F_CHG_TMR] = REG_FIELD(0x07, 1, 2),
- [F_JEITA_ISET] = REG_FIELD(0x07, 0, 0),
+ [F_JEITA_ISET] = REG_FIELD(0x07, 0, 0), // reserved on BQ25895
/* REG08 */
[F_BATCMP] = REG_FIELD(0x08, 5, 7),
[F_VCLAMP] = REG_FIELD(0x08, 2, 4),
@@ -180,7 +181,7 @@ static const struct reg_field bq25890_reg_fields[] = {
[F_FORCE_ICO] = REG_FIELD(0x09, 7, 7),
[F_TMR2X_EN] = REG_FIELD(0x09, 6, 6),
[F_BATFET_DIS] = REG_FIELD(0x09, 5, 5),
- [F_JEITA_VSET] = REG_FIELD(0x09, 4, 4),
+ [F_JEITA_VSET] = REG_FIELD(0x09, 4, 4), // reserved on BQ25895
[F_BATFET_DLY] = REG_FIELD(0x09, 3, 3),
[F_BATFET_RST_EN] = REG_FIELD(0x09, 2, 2),
[F_PUMPX_UP] = REG_FIELD(0x09, 1, 1),
@@ -188,7 +189,7 @@ static const struct reg_field bq25890_reg_fields[] = {
/* REG0A */
[F_BOOSTV] = REG_FIELD(0x0A, 4, 7),
/* PFM_OTG_DIS 3 on BQ25896 */
- [F_BOOSTI] = REG_FIELD(0x0A, 0, 2),
+ [F_BOOSTI] = REG_FIELD(0x0A, 0, 2), // reserved on BQ25895
/* REG0B */
[F_VBUS_STAT] = REG_FIELD(0x0B, 5, 7),
[F_CHG_STAT] = REG_FIELD(0x0B, 3, 4),
@@ -392,6 +393,8 @@ static int bq25890_power_supply_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_MODEL_NAME:
if (bq->chip_id == BQ25890_ID)
val->strval = "BQ25890";
+ else if (bq->chip_id == BQ25895_ID)
+ val->strval = "BQ25895";
else if (bq->chip_id == BQ25896_ID)
val->strval = "BQ25896";
else
@@ -862,7 +865,8 @@ static int bq25890_probe(struct i2c_client *client,
return bq->chip_id;
}
- if ((bq->chip_id != BQ25890_ID) && (bq->chip_id != BQ25896_ID)) {
+ if ((bq->chip_id != BQ25890_ID) && (bq->chip_id != BQ25895_ID)
+ && (bq->chip_id != BQ25896_ID)) {
dev_err(dev, "Chip with ID=%d, not supported!\n", bq->chip_id);
return -ENODEV;
}
--
2.17.1
^ permalink raw reply related
* Re: iowait v.s. idle accounting is "inconsistent" - iowait is too low
From: Alan Jenkins @ 2019-07-05 13:37 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, linux-kernel, Doug Smythies, linux-pm
In-Reply-To: <20190705113806.GP3402@hirez.programming.kicks-ass.net>
On 05/07/2019 12:38, Peter Zijlstra wrote:
> On Fri, Jul 05, 2019 at 12:25:46PM +0100, Alan Jenkins wrote:
>> Hi, scheduler experts!
>>
>> My cpu "iowait" time appears to be reported incorrectly. Do you know why
>> this could happen?
> Because iowait is a magic random number that has no sane meaning.
> Personally I'd prefer to just delete the whole thing, except ABI :/
>
> Also see the comment near nr_iowait():
>
> /*
> * IO-wait accounting, and how its mostly bollocks (on SMP).
> *
> * The idea behind IO-wait account is to account the idle time that we could
> * have spend running if it were not for IO. That is, if we were to improve the
> * storage performance, we'd have a proportional reduction in IO-wait time.
> *
> * This all works nicely on UP, where, when a task blocks on IO, we account
> * idle time as IO-wait, because if the storage were faster, it could've been
> * running and we'd not be idle.
> *
> * This has been extended to SMP, by doing the same for each CPU. This however
> * is broken.
> *
> * Imagine for instance the case where two tasks block on one CPU, only the one
> * CPU will have IO-wait accounted, while the other has regular idle. Even
> * though, if the storage were faster, both could've ran at the same time,
> * utilising both CPUs.
> *
> * This means, that when looking globally, the current IO-wait accounting on
> * SMP is a lower bound, by reason of under accounting.
> *
> * Worse, since the numbers are provided per CPU, they are sometimes
> * interpreted per CPU, and that is nonsensical. A blocked task isn't strictly
> * associated with any one particular CPU, it can wake to another CPU than it
> * blocked on. This means the per CPU IO-wait number is meaningless.
> *
> * Task CPU affinities can make all that even more 'interesting'.
> */
Thanks. I take those as being different problems, but you mean there is
not much demand (or point) to "fix" my issue.
> (2) Compare running "dd" with "taskset -c 1":
>
> %Cpu1 : 0.3 us, 3.0 sy, 0.0 ni, 83.7 id, 12.6 wa, 0.0 hi, 0.3 si, 0.0 st
^ non-zero idle time for Cpu1, despite the pinned IO hog.
The block layer recently decided they could break "disk busy%" reporting
for slow devices (mechanical HDD), in order to reduce overheads for fast
devices. This means the summary view in "atop" now lacks any reliable
indicator.
I suppose I need to look in "iotop".
The new /proc/pressure/io seems to have caveats related to the iowait
issues... it seems even more complex to interpret for this case, and it
does not seem to work how I think it does.[1]
Regards
Alan
[1]
https://unix.stackexchange.com/questions/527342/why-does-the-new-linux-pressure-stall-information-for-io-not-show-as-100/
^ permalink raw reply
* Re: [PATCH V2 00/13] intel_rapl: RAPL abstraction and MMIO RAPL support
From: Pandruvada, Srinivas @ 2019-07-05 14:59 UTC (permalink / raw)
To: Zhang, Rui, rafael@kernel.org; +Cc: linux-pm@vger.kernel.org, rjw@rjwysocki.net
In-Reply-To: <CAJZ5v0jZEcSpGqeccZwOw6a_QMXKdcx4K2GBeC8P0Vn-9E6vyQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]
On Fri, 2019-07-05 at 10:57 +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 4, 2019 at 6:34 PM Zhang Rui <rui.zhang@intel.com> wrote:
> >
> > Besideis MSR interface, RAPL can also be controlled via the MMIO
> > interface,
> > by accessing the MCHBar registers exposed by the processor thermal
> > device.
> >
> > Currently, we only have RAPL MSR interface in Linux kernel, this
> > brings
> > problems on some platforms that BIOS performs a low power limits
> > via the
> > MMIO interface by default. This results in poor system performance,
> > and there is no way for us to change the MMIO MSR setting in Linux.
> >
> > To fix this, RAPL MMIO interface support is introduced in this
> > patch set.
> >
> > Patch 1/13 to patch 11/13 abstract the RAPL code, and move all the
> > shared
> > code into a separate file, intel_rapl_common.c, so that it can be
> > used
> > by both MSR and MMIO interfaces.
> > Patch 12/13 introduced RAPL support via MMIO registers, exposed by
> > the
> > processor thermal devices.
> > Patch 13/13 fixes a module autoloading issue found later.
> >
> > The patch series has been tested on Dell XPS 9360, a SKL platform.
> >
> > Note that this patch series are based on the -tip tree, which
> > contains the
> > latest RAPL changes for multi-die support.
> >
> > Changes in V2:
> > - add kerneldoc for struct rapl_if_priv.
> > - use intel_rapl_msr.c for RAPL MSR I/F driver, instead of
> > intel_rapl.c.
> > - changelog and coding style update.
>
> What tree is the series against?
>
> It doesn't apply either on top of my powercap branch or on top of
> 5.2-rc7 for me.
This needs linux tip tree. There are some package/die changes in tip
tree, which this patch depends on.
Thanks,
Srinivas
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3290 bytes --]
^ permalink raw reply
* Aw: Re: [PATCH v2 3/7] rtc: mt6397: improvements of rtc driver
From: Frank Wunderlich @ 2019-07-05 15:35 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Lee Jones, Rob Herring, Mark Rutland, Matthias Brugger, Sean Wang,
Sebastian Reichel, Alessandro Zummo, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, linux-pm, linux-rtc, Eddie Huang,
Thomas Gleixner, Richard Fontana, Allison Randal,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Rob Herring, Linus Walleij, Nicolas Ferre, Paul E . McKenney,
Josef Friedl
In-Reply-To: <20190704204336.GJ3692@piout.net>
Hi Alexander,
thank you for the Review
> Gesendet: Donnerstag, 04. Juli 2019 um 22:43 Uhr
> Von: "Alexandre Belloni" <alexandre.belloni@bootlin.com>
> > - rtc->rtc_dev = devm_rtc_allocate_device(rtc->dev);
> > - if (IS_ERR(rtc->rtc_dev))
> > - return PTR_ERR(rtc->rtc_dev);
> > + ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> > + mtk_rtc_irq_handler_thread,
> > + IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> > + "mt6397-rtc", rtc);
> >
>
> This change may lead to a crash and the allocation was intentionally
> placed before the irq request.
i got no crash till now, but i will try to move the allocation before irq-request
> > - ret = request_threaded_irq(rtc->irq, NULL,
> > - mtk_rtc_irq_handler_thread,
> > - IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> > - "mt6397-rtc", rtc);
> > if (ret) {
> > dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
> > rtc->irq, ret);
> > @@ -287,6 +281,10 @@ static int mtk_rtc_probe(struct platform_device *pdev)
> >
> > device_init_wakeup(&pdev->dev, 1);
> >
> > + rtc->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
> > + if (IS_ERR(rtc->rtc_dev))
> > + return PTR_ERR(rtc->rtc_dev);
> > +
> > rtc->rtc_dev->ops = &mtk_rtc_ops;
> > static const struct of_device_id mt6397_rtc_of_match[] = {
> > + { .compatible = "mediatek,mt6323-rtc", },
>
> Unrelated change, this is not an improvement and must be accompanied by
> a documentation change.
documentation is changed in 1/7 defining this compatible. i called it improvement because existing driver now supports another chip
regards Frank
^ permalink raw reply
* The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used
From: Thomas Lindroth @ 2019-07-05 17:22 UTC (permalink / raw)
To: linux-pm; +Cc: linux-kernel
On recent kernels the tick remains active on idle adaptive-tick CPUs when a small value is written to /dev/cpu_dma_latency to restrict the highest C-state. Before the idle loop redesign in 4.17 idle CPUs had the tick disabled even when C-state were restricted. Is this change intentional or a regression?
I use an x86_64 system built with CONFIG_NO_HZ_FULL that I recently upgraded to the 4.19 series from the 4.14 series. I noticed that adaptive-tick CPUs (nohz_full=1-7) still fire timer interrupts about 1000 times/s (CONFIG_HZ_1000=y) even when they are mostly idle. Some debugging showed that this only happens when a program is writing to /dev/cpu_dma_latency to restrict C-states. The old 4.14 kernel only have around 10 timer interrupts per second on idle adaptive-tick CPU even when C-states are restricted that way.
I would expect an adaptive-tick CPU to turn off the tick when it has 0 or 1 processes to run and enable the tick for >2 processes. Kernels after 4.17 instead have the tick on when 0 or >2 processes are running and the tick off in the 1 process case. Since the tick is off when a single process is running that workload isn't directly harmed by the change but if the CPU use hyperthreading the constant wakeups on an idle HT sibling will reduce performance on the other sibling.
They way I look for timer interrupts is by comparing the LOC line in /proc/interrupts or using the hrtimer_expire_entry tracepoint when function=tick_sched_timer. Both methods seem to give the same results.
I can reproduce the problem using an i7-4790K CPU with /sys/devices/system/cpu/cpuidle/current_driver:intel_idle. I can also reproduce the problem on an old core2duo laptop with current_driver:acpi_idle but I can't reproduce the problem in a virtual machine where current_driver:none. I also can't reproduce the problem if C-states are restricted using the intel_idle.max_cstate=1 kernel argument instead of /dev/cpu_dma_latency.
The commit that introduced the change is 554c8aa8ec "sched: idle: Select idle state before stopping the tick" in v4.17 and the problem exists at least up to kernel 5.1 using the menu cpuidle governor.
^ permalink raw reply
* Re: suspend broken in next-20190704 on Thinkpad X60
From: Pavel Machek @ 2019-07-05 18:50 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Linux-pm mailing list, kernel list,
Stephen Rothwell
In-Reply-To: <CAJZ5v0gn7FWpqW+WmCzj1=K-pjY=SjRNuEsMR3bRTSO8FzFG=Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]
On Fri 2019-07-05 00:59:35, Rafael J. Wysocki wrote:
> On Thu, Jul 4, 2019 at 9:20 PM Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> > Suspend is broken in next-20190704 on Thinkpad X60.
>
> Broken in what way? Any details?
>
> > It very very probably worked ok in 20190701.
>
> Well, please try the linux-next branch from linux-pm.git
> (git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git)
> alone and see if that fails.
So... let me try this one?
commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch)
tree cb5339fcaae2166832f91f4ce9f40575cc6cb6e5
parent 3836c60c063581294c3a82f8cbccf3f702951358 (diff)
parent 0a811974f3f79eea299af79c29595d8e1cb80a15 (diff)
download
linux-pm-1e2a4c9019eb53f62790fadf86c14a54f4cf4888.tar.gz
Merge branch 'pm-cpufreq-new' into
linux-nexttestinglinux-nextbleeding-edge
* pm-cpufreq-new:
That one is broken, too.
pavel@amd:~$ sudo pm-suspend
Machine suspends, resumes, but I don't get my prompt back.
Nothing suspect in dmesg:
[ 63.925151] usb 5-1: reset full-speed USB device number 2 using
uhci_hcd
[ 67.105121] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 67.106401] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES)
succeeded
[ 67.106410] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE
LOCK) filtered out
[ 67.106418] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
filtered out
[ 67.108575] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES)
succeeded
[ 67.108585] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE
LOCK) filtered out
[ 67.108593] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
filtered out
[ 67.109152] ata1.00: configured for UDMA/133
[ 71.672932] PM: resume devices took 8.668 seconds
[ 71.673955] OOM killer enabled.
[ 71.673961] Restarting tasks ... done.
[ 73.970718] wlan0: authenticate with 30:b5:c2:f5:9f:1e
[ 73.972610] wlan0: send auth to 30:b5:c2:f5:9f:1e (try 1/3)
[ 73.977518] wlan0: authenticated
[ 73.985092] wlan0: associate with 30:b5:c2:f5:9f:1e (try 1/3)
[ 73.989844] wlan0: RX AssocResp from 30:b5:c2:f5:9f:1e (capab=0x431
status=0 aid=2)
[ 74.002908] wlan0: associated
pavel@amd:~$
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [pm:linux-next 113/119] emac-phy.c:(.text+0x1d8): multiple definition of `acpi_sleep_state_supported'
From: kbuild test robot @ 2019-07-05 19:09 UTC (permalink / raw)
To: Dexuan Cui; +Cc: kbuild-all, linux-acpi, devel, linux-pm, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
head: 1e2a4c9019eb53f62790fadf86c14a54f4cf4888
commit: 1e2c3f0f1e93d73d2b0858940c689aa0a7058cf4 [113/119] ACPI: PM: Make acpi_sleep_state_supported() non-static
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1e2c3f0f1e93d73d2b0858940c689aa0a7058cf4
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/net/ethernet/qualcomm/emac/emac-phy.o: In function `acpi_sleep_state_supported':
>> emac-phy.c:(.text+0x1d8): multiple definition of `acpi_sleep_state_supported'
drivers/net/ethernet/qualcomm/emac/emac.o:emac.c:(.text+0xbf8): first defined here
drivers/net/ethernet/qualcomm/emac/emac-sgmii.o: In function `acpi_sleep_state_supported':
emac-sgmii.c:(.text+0x548): multiple definition of `acpi_sleep_state_supported'
drivers/net/ethernet/qualcomm/emac/emac.o:emac.c:(.text+0xbf8): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 44411 bytes --]
^ permalink raw reply
* RE: [pm:linux-next 113/119] emac-phy.c:(.text+0x1d8): multiple definition of `acpi_sleep_state_supported'
From: Dexuan Cui @ 2019-07-05 20:22 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all@01.org, linux-acpi@vger.kernel.org, devel@acpica.org,
linux-pm@vger.kernel.org, Rafael J. Wysocki
In-Reply-To: <201907060301.FFmawuvI%lkp@intel.com>
> From: kbuild test robot <lkp@intel.com>
> Sent: Friday, July 5, 2019 12:09 PM
...
> All errors (new ones prefixed by >>):
>
> drivers/net/ethernet/qualcomm/emac/emac-phy.o: In function
> `acpi_sleep_state_supported':
> >> emac-phy.c:(.text+0x1d8): multiple definition of
> `acpi_sleep_state_supported'
> drivers/net/ethernet/qualcomm/emac/emac.o:emac.c:(.text+0xbf8): first
> defined here
> drivers/net/ethernet/qualcomm/emac/emac-sgmii.o: In function
> `acpi_sleep_state_supported':
> emac-sgmii.c:(.text+0x548): multiple definition of
> `acpi_sleep_state_supported'
> drivers/net/ethernet/qualcomm/emac/emac.o:emac.c:(.text+0xbf8): first
> defined here
Thank for reporting the issue!
I posted a fix just now: https://lkml.org/lkml/2019/7/5/630
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH] Documentation: cpu-freq: Convert core.txt file to ReST format
From: Shreeya Patel @ 2019-07-05 21:04 UTC (permalink / raw)
To: skhan, rjw, viresh.kumar, corbet, linux-pm, linux-kernel,
linux-doc, linux-kernel-mentees
Convert core file to ReST format, in order to allow it to
be parsed by Sphinx. Make a minor change of correcting the wrong
function name cpufreq_put_cpu to cpufreq_cpu_put.
Also create an index.rst file in cpu-freq and add it's entry
in the main Documentation/index.rst file.
Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
---
Documentation/cpu-freq/core.rst | 114 +++++++++++++++++++++++++++++
Documentation/cpu-freq/core.txt | 120 -------------------------------
Documentation/cpu-freq/index.rst | 14 ++++
Documentation/index.rst | 1 +
4 files changed, 129 insertions(+), 120 deletions(-)
create mode 100644 Documentation/cpu-freq/core.rst
delete mode 100644 Documentation/cpu-freq/core.txt
create mode 100644 Documentation/cpu-freq/index.rst
diff --git a/Documentation/cpu-freq/core.rst b/Documentation/cpu-freq/core.rst
new file mode 100644
index 000000000000..b4cf48633797
--- /dev/null
+++ b/Documentation/cpu-freq/core.rst
@@ -0,0 +1,114 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+CPUFreq Core
+============
+
+Authors:
+
+- Dominik Brodowski <linux@brodo.de>,
+- David Kimdon <dwhedon@debian.org>,
+- Rafael J. Wysocki <rafael.j.wysocki@intel.com>,
+- Viresh Kumar <viresh.kumar@linaro.org>
+
+
+Clock scaling allows you to change the clock speed of the CPUs on the
+fly. This is a nice method to save battery power, because the lower
+the clock speed, the less power the CPU consumes.
+
+
+1. General Information
+----------------------
+
+The CPUFreq core code is located in :file:`drivers/cpufreq/cpufreq.c`. This
+cpufreq code offers a standardized interface for the CPUFreq
+architecture drivers (those pieces of code that do actual
+frequency transitions), as well as to "notifiers". These are device
+drivers or other part of the kernel that need to be informed of
+policy changes (ex. thermal modules like ACPI) or of all
+frequency changes (ex. timing code) or even need to force certain
+speed limits (like LCD drivers on ARM architecture). Additionally, the
+kernel "constant" :c:data:`loops_per_jiffy` is updated on frequency changes
+here.
+
+Reference counting of the cpufreq policies is done by :c:func:`cpufreq_cpu_put`
+and :c:func:`cpufreq_cpu_put`, which make sure that the cpufreq driver is
+correctly registered with the core, and will not be unloaded until
+:c:func:`cpufreq_cpu_put` is called. That also ensures that the respective cpufreq
+policy doesn't get freed while being used.
+
+2. CPUFreq notifiers
+--------------------
+
+CPUFreq notifiers conform to the standard kernel notifier interface.
+See :file:`linux/include/linux/notifier.h` for details on notifiers.
+
+There are two different CPUFreq notifiers - policy notifiers and
+transition notifiers.
+
+
+2.1 CPUFreq policy notifiers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These are notified when a new policy is intended to be set. Each
+CPUFreq policy notifier is called twice for a policy transition:
+
+ 1) During :c:macro:`CPUFREQ_ADJUST` all CPUFreq notifiers may change
+ the limit if they see a need for this - may it be thermal considerations
+ or hardware limitations.
+
+ 2) And during :c:macro:`CPUFREQ_NOTIFY` all notifiers are informed of the
+ new policy - if two hardware drivers failed to agree on a new policy
+ before this stage, the incompatible hardware shall be shut down, and the user
+ informed of this.
+
+The phase is specified in the second argument to the notifier.
+
+The third argument, a :c:data:`void *pointer`, points to a :c:type:`struct cpufreq_policy`
+consisting of several values, including min, max (the lower and upper
+frequencies (in kHz) of the new policy).
+
+
+2.2 CPUFreq transition notifiers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These are notified twice for each online CPU in the policy, when the
+CPUfreq driver switches the CPU core frequency and this change has no
+any external implications.
+
+The second argument specifies the phase - :c:macro:`CPUFREQ_PRECHANGE` or
+:c:macro:`CPUFREQ_POSTCHANGE`.
+
+The third argument is a :c:type:`struct cpufreq_freqs` with the following
+values:
+
+| cpu - number of the affected CPU
+| old - old frequency
+| new - new frequency
+| flags - flags of the cpufreq driver
+
+
+3. CPUFreq Table Generation with Operating Performance Point (OPP)
+------------------------------------------------------------------
+For details about OPP, see :file:`Documentation/power/opp.txt`
+
+:c:func:`dev_pm_opp_init_cpufreq_table` - This function provides a ready
+to use conversion routine to translate the OPP layer's internal information
+about the available frequencies into a format readily providable to cpufreq.
+
+WARNING: Do not use this function in interrupt context.
+
+ Example::
+
+ soc_pm_init()
+ {
+ /* Do things */
+ r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
+ if (!r)
+ policy->freq_table = freq_table;
+ /* Do other things */
+ }
+
+NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
+addition to CONFIG_PM_OPP.
+
+:c:func:`dev_pm_opp_free_cpufreq_table` - Free up the table allocated by :c:func:`dev_pm_opp_init_cpufreq_table`
diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
deleted file mode 100644
index 073f128af5a7..000000000000
--- a/Documentation/cpu-freq/core.txt
+++ /dev/null
@@ -1,120 +0,0 @@
- CPU frequency and voltage scaling code in the Linux(TM) kernel
-
-
- L i n u x C P U F r e q
-
- C P U F r e q C o r e
-
-
- Dominik Brodowski <linux@brodo.de>
- David Kimdon <dwhedon@debian.org>
- Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Viresh Kumar <viresh.kumar@linaro.org>
-
-
-
- Clock scaling allows you to change the clock speed of the CPUs on the
- fly. This is a nice method to save battery power, because the lower
- the clock speed, the less power the CPU consumes.
-
-
-Contents:
----------
-1. CPUFreq core and interfaces
-2. CPUFreq notifiers
-3. CPUFreq Table Generation with Operating Performance Point (OPP)
-
-1. General Information
-=======================
-
-The CPUFreq core code is located in drivers/cpufreq/cpufreq.c. This
-cpufreq code offers a standardized interface for the CPUFreq
-architecture drivers (those pieces of code that do actual
-frequency transitions), as well as to "notifiers". These are device
-drivers or other part of the kernel that need to be informed of
-policy changes (ex. thermal modules like ACPI) or of all
-frequency changes (ex. timing code) or even need to force certain
-speed limits (like LCD drivers on ARM architecture). Additionally, the
-kernel "constant" loops_per_jiffy is updated on frequency changes
-here.
-
-Reference counting of the cpufreq policies is done by cpufreq_cpu_get
-and cpufreq_cpu_put, which make sure that the cpufreq driver is
-correctly registered with the core, and will not be unloaded until
-cpufreq_put_cpu is called. That also ensures that the respective cpufreq
-policy doesn't get freed while being used.
-
-2. CPUFreq notifiers
-====================
-
-CPUFreq notifiers conform to the standard kernel notifier interface.
-See linux/include/linux/notifier.h for details on notifiers.
-
-There are two different CPUFreq notifiers - policy notifiers and
-transition notifiers.
-
-
-2.1 CPUFreq policy notifiers
-----------------------------
-
-These are notified when a new policy is intended to be set. Each
-CPUFreq policy notifier is called twice for a policy transition:
-
-1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
- they see a need for this - may it be thermal considerations or
- hardware limitations.
-
-2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
- - if two hardware drivers failed to agree on a new policy before this
- stage, the incompatible hardware shall be shut down, and the user
- informed of this.
-
-The phase is specified in the second argument to the notifier.
-
-The third argument, a void *pointer, points to a struct cpufreq_policy
-consisting of several values, including min, max (the lower and upper
-frequencies (in kHz) of the new policy).
-
-
-2.2 CPUFreq transition notifiers
---------------------------------
-
-These are notified twice for each online CPU in the policy, when the
-CPUfreq driver switches the CPU core frequency and this change has no
-any external implications.
-
-The second argument specifies the phase - CPUFREQ_PRECHANGE or
-CPUFREQ_POSTCHANGE.
-
-The third argument is a struct cpufreq_freqs with the following
-values:
-cpu - number of the affected CPU
-old - old frequency
-new - new frequency
-flags - flags of the cpufreq driver
-
-3. CPUFreq Table Generation with Operating Performance Point (OPP)
-==================================================================
-For details about OPP, see Documentation/power/opp.txt
-
-dev_pm_opp_init_cpufreq_table -
- This function provides a ready to use conversion routine to translate
- the OPP layer's internal information about the available frequencies
- into a format readily providable to cpufreq.
-
- WARNING: Do not use this function in interrupt context.
-
- Example:
- soc_pm_init()
- {
- /* Do things */
- r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
- if (!r)
- policy->freq_table = freq_table;
- /* Do other things */
- }
-
- NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
- addition to CONFIG_PM_OPP.
-
-dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table
diff --git a/Documentation/cpu-freq/index.rst b/Documentation/cpu-freq/index.rst
new file mode 100644
index 000000000000..fd81d4f501cc
--- /dev/null
+++ b/Documentation/cpu-freq/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================================
+CPU Frequency and Voltage Scaling Documentation
+===============================================
+
+.. class:: toc-title
+
+ Table of contents
+
+.. toctree::
+ :maxdepth: 2
+
+ core.rst
diff --git a/Documentation/index.rst b/Documentation/index.rst
index a7566ef62411..934206bc1daf 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -102,6 +102,7 @@ needed).
vm/index
bpf/index
misc-devices/index
+ cpu-freq/index
Architecture-specific documentation
-----------------------------------
--
2.17.1
^ permalink raw reply related
* Re: Re: [PATCH v2 3/7] rtc: mt6397: improvements of rtc driver
From: Alexandre Belloni @ 2019-07-05 21:24 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Lee Jones, Rob Herring, Mark Rutland, Matthias Brugger, Sean Wang,
Sebastian Reichel, Alessandro Zummo, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, linux-pm, linux-rtc, Eddie Huang,
Thomas Gleixner, Richard Fontana, Allison Randal,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Rob Herring, Linus Walleij, Nicolas Ferre, Paul E . McKenney,
Josef Friedl
In-Reply-To: <trinity-7b1977bd-252b-4482-b708-cf704a9d3da1-1562340946396@3c-app-gmx-bs68>
On 05/07/2019 17:35:46+0200, Frank Wunderlich wrote:
> Hi Alexander,
>
> thank you for the Review
>
> > Gesendet: Donnerstag, 04. Juli 2019 um 22:43 Uhr
> > Von: "Alexandre Belloni" <alexandre.belloni@bootlin.com>
> > > - rtc->rtc_dev = devm_rtc_allocate_device(rtc->dev);
> > > - if (IS_ERR(rtc->rtc_dev))
> > > - return PTR_ERR(rtc->rtc_dev);
> > > + ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> > > + mtk_rtc_irq_handler_thread,
> > > + IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> > > + "mt6397-rtc", rtc);
> > >
> >
> > This change may lead to a crash and the allocation was intentionally
> > placed before the irq request.
>
> i got no crash till now, but i will try to move the allocation before irq-request
>
Let's say the RTC has been used to start your platform, then the irq
handler will be called as soon as the irq is requested, leading to a
null pointer dereference.
> > > - ret = request_threaded_irq(rtc->irq, NULL,
> > > - mtk_rtc_irq_handler_thread,
> > > - IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> > > - "mt6397-rtc", rtc);
> > > if (ret) {
> > > dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
> > > rtc->irq, ret);
> > > @@ -287,6 +281,10 @@ static int mtk_rtc_probe(struct platform_device *pdev)
> > >
> > > device_init_wakeup(&pdev->dev, 1);
> > >
> > > + rtc->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
> > > + if (IS_ERR(rtc->rtc_dev))
> > > + return PTR_ERR(rtc->rtc_dev);
> > > +
> > > rtc->rtc_dev->ops = &mtk_rtc_ops;
>
>
> > > static const struct of_device_id mt6397_rtc_of_match[] = {
> > > + { .compatible = "mediatek,mt6323-rtc", },
> >
> > Unrelated change, this is not an improvement and must be accompanied by
> > a documentation change.
>
> documentation is changed in 1/7 defining this compatible. i called it improvement because existing driver now supports another chip
>
Yes and IIRC, I did comment that the rtc change also had to be separated
from 1/7.
Also, I really doubt this new compatible is necessary at all as you
could simply directly use mediatek,mt6397-rtc.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] Documentation: cpu-freq: Convert core.txt file to ReST format
From: Rafael J. Wysocki @ 2019-07-06 7:58 UTC (permalink / raw)
To: Shreeya Patel
Cc: skhan, Rafael J. Wysocki, Viresh Kumar, Jonathan Corbet, Linux PM,
Linux Kernel Mailing List, open list:DOCUMENTATION,
linux-kernel-mentees
In-Reply-To: <20190705210428.8039-1-shreeya.patel23498@gmail.com>
On Fri, Jul 5, 2019 at 11:04 PM Shreeya Patel
<shreeya.patel23498@gmail.com> wrote:
>
> Convert core file to ReST format, in order to allow it to
> be parsed by Sphinx. Make a minor change of correcting the wrong
> function name cpufreq_put_cpu to cpufreq_cpu_put.
> Also create an index.rst file in cpu-freq and add it's entry
> in the main Documentation/index.rst file.
>
> Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com>
I've said "no" no three previous attempts and this one is not different.
I don't want to have anything .rst in Documentation/cpu-freq/.
There is a *new* admin-guide doc for cpufreq already and what is
missing is a *new* driver-api one.
Thanks!
^ permalink raw reply
* Re: The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used
From: Rafael J. Wysocki @ 2019-07-06 8:17 UTC (permalink / raw)
To: Thomas Lindroth
Cc: Linux PM, Linux Kernel Mailing List, Peter Zijlstra,
Frederic Weisbecker
In-Reply-To: <79b247b3-e056-610e-9a07-e685dfdaa6c9@gmail.com>
On Fri, Jul 5, 2019 at 7:22 PM Thomas Lindroth
<thomas.lindroth@gmail.com> wrote:
>
> On recent kernels the tick remains active on idle adaptive-tick CPUs when a small value is written to /dev/cpu_dma_latency to restrict the highest C-state. Before the idle loop redesign in 4.17 idle CPUs had the tick disabled even when C-state were restricted. Is this change intentional or a regression?
It was intentional, but this kind of is a gray area.
At least for the menu governor you may argue that the decision on
whether or not to stop the tick should be based on the predicted idle
duration.
> I use an x86_64 system built with CONFIG_NO_HZ_FULL that I recently upgraded to the 4.19 series from the 4.14 series. I noticed that adaptive-tick CPUs (nohz_full=1-7) still fire timer interrupts about 1000 times/s (CONFIG_HZ_1000=y) even when they are mostly idle. Some debugging showed that this only happens when a program is writing to /dev/cpu_dma_latency to restrict C-states. The old 4.14 kernel only have around 10 timer interrupts per second on idle adaptive-tick CPU even when C-states are restricted that way.
>
> I would expect an adaptive-tick CPU to turn off the tick when it has 0 or 1 processes to run and enable the tick for >2 processes. Kernels after 4.17 instead have the tick on when 0 or >2 processes are running and the tick off in the 1 process case. Since the tick is off when a single process is running that workload isn't directly harmed by the change but if the CPU use hyperthreading the constant wakeups on an idle HT sibling will reduce performance on the other sibling.
>
> They way I look for timer interrupts is by comparing the LOC line in /proc/interrupts or using the hrtimer_expire_entry tracepoint when function=tick_sched_timer. Both methods seem to give the same results.
>
> I can reproduce the problem using an i7-4790K CPU with /sys/devices/system/cpu/cpuidle/current_driver:intel_idle. I can also reproduce the problem on an old core2duo laptop with current_driver:acpi_idle but I can't reproduce the problem in a virtual machine where current_driver:none. I also can't reproduce the problem if C-states are restricted using the intel_idle.max_cstate=1 kernel argument instead of /dev/cpu_dma_latency.
>
> The commit that introduced the change is 554c8aa8ec "sched: idle: Select idle state before stopping the tick" in v4.17 and the problem exists at least up to kernel 5.1 using the menu cpuidle governor.
Restoring the previous behavior in this case should be relatively
straightforward. I'll send you a patch to do that later.
^ permalink raw reply
* Re: [PATCH V2 00/13] intel_rapl: RAPL abstraction and MMIO RAPL support
From: Rafael J. Wysocki @ 2019-07-06 8:19 UTC (permalink / raw)
To: Pandruvada, Srinivas
Cc: Zhang, Rui, rafael@kernel.org, linux-pm@vger.kernel.org,
rjw@rjwysocki.net
In-Reply-To: <97215b43ce11766f83847531b05def8d94f645f0.camel@intel.com>
On Fri, Jul 5, 2019 at 4:59 PM Pandruvada, Srinivas
<srinivas.pandruvada@intel.com> wrote:
>
> On Fri, 2019-07-05 at 10:57 +0200, Rafael J. Wysocki wrote:
> > On Thu, Jul 4, 2019 at 6:34 PM Zhang Rui <rui.zhang@intel.com> wrote:
> > >
> > > Besideis MSR interface, RAPL can also be controlled via the MMIO
> > > interface,
> > > by accessing the MCHBar registers exposed by the processor thermal
> > > device.
> > >
> > > Currently, we only have RAPL MSR interface in Linux kernel, this
> > > brings
> > > problems on some platforms that BIOS performs a low power limits
> > > via the
> > > MMIO interface by default. This results in poor system performance,
> > > and there is no way for us to change the MMIO MSR setting in Linux.
> > >
> > > To fix this, RAPL MMIO interface support is introduced in this
> > > patch set.
> > >
> > > Patch 1/13 to patch 11/13 abstract the RAPL code, and move all the
> > > shared
> > > code into a separate file, intel_rapl_common.c, so that it can be
> > > used
> > > by both MSR and MMIO interfaces.
> > > Patch 12/13 introduced RAPL support via MMIO registers, exposed by
> > > the
> > > processor thermal devices.
> > > Patch 13/13 fixes a module autoloading issue found later.
> > >
> > > The patch series has been tested on Dell XPS 9360, a SKL platform.
> > >
> > > Note that this patch series are based on the -tip tree, which
> > > contains the
> > > latest RAPL changes for multi-die support.
> > >
> > > Changes in V2:
> > > - add kerneldoc for struct rapl_if_priv.
> > > - use intel_rapl_msr.c for RAPL MSR I/F driver, instead of
> > > intel_rapl.c.
> > > - changelog and coding style update.
> >
> > What tree is the series against?
> >
> > It doesn't apply either on top of my powercap branch or on top of
> > 5.2-rc7 for me.
> This needs linux tip tree. There are some package/die changes in tip
> tree, which this patch depends on.
OK, so the changes in -tip need to go in first.
Thanks!
^ permalink raw reply
* Re: suspend broken in next-20190704 on Thinkpad X60
From: Rafael J. Wysocki @ 2019-07-06 8:33 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, Rafael J. Wysocki, Linux-pm mailing list,
kernel list, Stephen Rothwell
In-Reply-To: <20190705185001.GA4068@amd>
On Fri, Jul 5, 2019 at 8:50 PM Pavel Machek <pavel@ucw.cz> wrote:
>
> On Fri 2019-07-05 00:59:35, Rafael J. Wysocki wrote:
> > On Thu, Jul 4, 2019 at 9:20 PM Pavel Machek <pavel@ucw.cz> wrote:
> > >
> > > Hi!
> > >
> > > Suspend is broken in next-20190704 on Thinkpad X60.
> >
> > Broken in what way? Any details?
> >
> > > It very very probably worked ok in 20190701.
> >
> > Well, please try the linux-next branch from linux-pm.git
> > (git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git)
> > alone and see if that fails.
>
> So... let me try this one?
>
> commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch)
> tree cb5339fcaae2166832f91f4ce9f40575cc6cb6e5
> parent 3836c60c063581294c3a82f8cbccf3f702951358 (diff)
> parent 0a811974f3f79eea299af79c29595d8e1cb80a15 (diff)
> download
> linux-pm-1e2a4c9019eb53f62790fadf86c14a54f4cf4888.tar.gz
> Merge branch 'pm-cpufreq-new' into
> linux-nexttestinglinux-nextbleeding-edge
> * pm-cpufreq-new:
>
> That one is broken, too.
>
> pavel@amd:~$ sudo pm-suspend
>
> Machine suspends, resumes, but I don't get my prompt back.
I'm not sure what you mean here. I'm guessing that you don't get back
to the console from which you ran the pm-suspend command, but is X
restored, for example? Is there any way to get into the system in
that state?
Anyway, if 5.2-rc7 is OK, something in this branch causes the problem
to happen for you.
I would try
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244
to narrow down the scope somewhat.
^ permalink raw reply
* Re: The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used
From: Rafael J. Wysocki @ 2019-07-06 11:06 UTC (permalink / raw)
To: Thomas Lindroth
Cc: Linux PM, Linux Kernel Mailing List, Peter Zijlstra,
Frederic Weisbecker
In-Reply-To: <CAJZ5v0grOas+Wh0h09fKZmUnOJ3PRX2Fc=2fv7=zCFJiZ09-Bg@mail.gmail.com>
On Saturday, July 6, 2019 10:17:15 AM CEST Rafael J. Wysocki wrote:
> On Fri, Jul 5, 2019 at 7:22 PM Thomas Lindroth
> <thomas.lindroth@gmail.com> wrote:
> >
> > On recent kernels the tick remains active on idle adaptive-tick CPUs when a small
> > value is written to /dev/cpu_dma_latency to restrict the highest C-state. Before the
> > idle loop redesign in 4.17 idle CPUs had the tick disabled even when C-state were
> > restricted. Is this change intentional or a regression?
>
> It was intentional, but this kind of is a gray area.
>
> At least for the menu governor you may argue that the decision on
> whether or not to stop the tick should be based on the predicted idle
> duration.
But also see below.
> > I use an x86_64 system built with CONFIG_NO_HZ_FULL that I recently upgraded to the 4.19 series from the 4.14 series.
> > I noticed that adaptive-tick CPUs (nohz_full=1-7) still fire timer interrupts about 1000 times/s (CONFIG_HZ_1000=y) even
> > when they are mostly idle. Some debugging showed that this only happens when a program is writing to
> > /dev/cpu_dma_latency to restrict C-states. The old 4.14 kernel only have around 10 timer interrupts per second on idle
> > adaptive-tick CPU even when C-states are restricted that way.
> >
> > I would expect an adaptive-tick CPU to turn off the tick when it has 0 or 1 processes to run and enable the tick for >2
> > processes. Kernels after 4.17 instead have the tick on when 0 or >2 processes are running and the tick off in the 1 process
> > case. Since the tick is off when a single process is running that workload isn't directly harmed by the change but if the CPU
> > use hyperthreading the constant wakeups on an idle HT sibling will reduce performance on the other sibling.
So it looks like the idle loop needs a special case for adaptive-tick CPUs.
> >
> > They way I look for timer interrupts is by comparing the LOC line in /proc/interrupts or using the hrtimer_expire_entry
> > tracepoint when function=tick_sched_timer. Both methods seem to give the same results.
> >
> > I can reproduce the problem using an i7-4790K CPU with /sys/devices/system/cpu/cpuidle/current_driver:intel_idle. I can
> > also reproduce the problem on an old core2duo laptop with current_driver:acpi_idle but I can't reproduce the problem
> > in a virtual machine where current_driver:none. I also can't reproduce the problem if C-states are restricted using the
> > intel_idle.max_cstate=1 kernel argument instead of /dev/cpu_dma_latency.
> >
> > The commit that introduced the change is 554c8aa8ec "sched: idle: Select idle state before stopping the tick" in v4.17
> > and the problem exists at least up to kernel 5.1 using the menu cpuidle governor.
>
> Restoring the previous behavior in this case should be relatively
> straightforward. I'll send you a patch to do that later.
The patch is below, but note that it adds the tick stopping overhead to the idle loop
for CPUs that are not adaptive-tick and when PM QoS latency constraints are used
which is not desirable in general.
Please test it, but as I said above, the real solution appears to be to treat adaptive-tick
CPUs in a special way in the idle loop.
---
| 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
Index: linux-pm/drivers/cpuidle/governors/menu.c
===================================================================
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -302,9 +302,10 @@ static int menu_select(struct cpuidle_dr
!drv->states[0].disabled && !dev->states_usage[0].disable)) {
/*
* In this case state[0] will be used no matter what, so return
- * it right away and keep the tick running.
+ * it right away and keep the tick running if state[0] is a
+ * polling one.
*/
- *stop_tick = false;
+ *stop_tick = !!(drv->states[0].flags & CPUIDLE_FLAG_POLLING);
return 0;
}
@@ -395,16 +396,9 @@ static int menu_select(struct cpuidle_dr
return idx;
}
- if (s->exit_latency > latency_req) {
- /*
- * If we break out of the loop for latency reasons, use
- * the target residency of the selected state as the
- * expected idle duration so that the tick is retained
- * as long as that target residency is low enough.
- */
- predicted_us = drv->states[idx].target_residency;
+ if (s->exit_latency > latency_req)
break;
- }
+
idx = i;
}
^ permalink raw reply
* Re: The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used
From: Thomas Lindroth @ 2019-07-06 13:02 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PM, Linux Kernel Mailing List, Peter Zijlstra,
Frederic Weisbecker
In-Reply-To: <7332404.L1nL2KBT3s@kreacher>
On 7/6/19 1:06 PM, Rafael J. Wysocki wrote:
> The patch is below, but note that it adds the tick stopping overhead to the idle loop
> for CPUs that are not adaptive-tick and when PM QoS latency constraints are used
> which is not desirable in general.
>
> Please test it, but as I said above, the real solution appears to be to treat adaptive-tick
> CPUs in a special way in the idle loop.
>
> ---
> drivers/cpuidle/governors/menu.c | 16 +++++-----------
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> Index: linux-pm/drivers/cpuidle/governors/menu.c
> ===================================================================
> --- linux-pm.orig/drivers/cpuidle/governors/menu.c
> +++ linux-pm/drivers/cpuidle/governors/menu.c
> @@ -302,9 +302,10 @@ static int menu_select(struct cpuidle_dr
> !drv->states[0].disabled && !dev->states_usage[0].disable)) {
> /*
> * In this case state[0] will be used no matter what, so return
> - * it right away and keep the tick running.
> + * it right away and keep the tick running if state[0] is a
> + * polling one.
> */
> - *stop_tick = false;
> + *stop_tick = !!(drv->states[0].flags & CPUIDLE_FLAG_POLLING);
> return 0;
> }
>
> @@ -395,16 +396,9 @@ static int menu_select(struct cpuidle_dr
>
> return idx;
> }
> - if (s->exit_latency > latency_req) {
> - /*
> - * If we break out of the loop for latency reasons, use
> - * the target residency of the selected state as the
> - * expected idle duration so that the tick is retained
> - * as long as that target residency is low enough.
> - */
> - predicted_us = drv->states[idx].target_residency;
> + if (s->exit_latency > latency_req)
> break;
> - }
> +
> idx = i;
> }
I tested the patch and it appears to work. Idle CPUs now have ticks disabled even
when /dev/cpu_dma_latency is used.
I also want to thank you for your work on the idle loop redesign. Overall it works
much better than before. I used to have a problem where idle CPUs would end up
doing C0 polling for a long time resulting in a big performance drop on the HT
sibling. When benchmarking I always had to offline siblings to get consistent
results. That problem was fixed in the redesign.
^ permalink raw reply
* Re: suspend broken in next-20190704 on Thinkpad X60
From: Pavel Machek @ 2019-07-06 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Linux-pm mailing list, kernel list,
Stephen Rothwell
In-Reply-To: <CAJZ5v0irbn-Xd47KExw=h7On7KShCm6rThCo0q4-zn=o_x6_HQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]
Hi!
> > > > Suspend is broken in next-20190704 on Thinkpad X60.
> > >
> > > Broken in what way? Any details?
> > >
> > > > It very very probably worked ok in 20190701.
> > >
> > > Well, please try the linux-next branch from linux-pm.git
> > > (git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git)
> > > alone and see if that fails.
> >
> > So... let me try this one?
> >
> > commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch)
> > tree cb5339fcaae2166832f91f4ce9f40575cc6cb6e5
> > parent 3836c60c063581294c3a82f8cbccf3f702951358 (diff)
> > parent 0a811974f3f79eea299af79c29595d8e1cb80a15 (diff)
> > download
> > linux-pm-1e2a4c9019eb53f62790fadf86c14a54f4cf4888.tar.gz
> > Merge branch 'pm-cpufreq-new' into
> > linux-nexttestinglinux-nextbleeding-edge
> > * pm-cpufreq-new:
> >
> > That one is broken, too.
> >
> > pavel@amd:~$ sudo pm-suspend
> >
> > Machine suspends, resumes, but I don't get my prompt back.
>
> I'm not sure what you mean here. I'm guessing that you don't get back
> to the console from which you ran the pm-suspend command, but is X
> restored, for example? Is there any way to get into the system in
> that state?
X is restored, and the rest of system works, but "pm-suspend" command
never completes, so I don't get shell prompt back in that window.
> Anyway, if 5.2-rc7 is OK, something in this branch causes the problem
> to happen for you.
>
> I would try
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244
>
> to narrow down the scope somewhat.
next-20190701 is ok, next-20190704 is broken. Can we use that to
narrow it down?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: suspend broken in next-20190704 on Thinkpad X60
From: Pavel Machek @ 2019-07-06 15:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Linux-pm mailing list, kernel list,
Stephen Rothwell
In-Reply-To: <CAJZ5v0irbn-Xd47KExw=h7On7KShCm6rThCo0q4-zn=o_x6_HQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
Hi!
> > commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch)
> > tree cb5339fcaae2166832f91f4ce9f40575cc6cb6e5
> > parent 3836c60c063581294c3a82f8cbccf3f702951358 (diff)
> > parent 0a811974f3f79eea299af79c29595d8e1cb80a15 (diff)
> > download
> > linux-pm-1e2a4c9019eb53f62790fadf86c14a54f4cf4888.tar.gz
> > Merge branch 'pm-cpufreq-new' into
> > linux-nexttestinglinux-nextbleeding-edge
> > * pm-cpufreq-new:
> >
> > That one is broken, too.
> >
> > pavel@amd:~$ sudo pm-suspend
> >
> > Machine suspends, resumes, but I don't get my prompt back.
>
> I'm not sure what you mean here. I'm guessing that you don't get back
> to the console from which you ran the pm-suspend command, but is X
> restored, for example? Is there any way to get into the system in
> that state?
>
> Anyway, if 5.2-rc7 is OK, something in this branch causes the problem
> to happen for you.
>
> I would try
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244
That one is good.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Aw: Re: Re: [PATCH v2 3/7] rtc: mt6397: improvements of rtc driver
From: Frank Wunderlich @ 2019-07-06 16:15 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Lee Jones, Rob Herring, Mark Rutland, Matthias Brugger, Sean Wang,
Sebastian Reichel, Alessandro Zummo, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, linux-pm, linux-rtc, Eddie Huang,
Thomas Gleixner, Richard Fontana, Allison Randal,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Rob Herring, Linus Walleij, Nicolas Ferre, Paul E . McKenney,
Josef Friedl
In-Reply-To: <20190705212448.GB12409@piout.net>
> Gesendet: Freitag, 05. Juli 2019 um 23:24 Uhr
> Von: "Alexandre Belloni" <alexandre.belloni@bootlin.com>
> Let's say the RTC has been used to start your platform, then the irq
> handler will be called as soon as the irq is requested, leading to a
> null pointer dereference.
i cannot test this with my platform, but i have changed it in my repo
https://github.com/frank-w/BPI-R2-4.14/commits/5.2-poweroff-mainline
> Yes and IIRC, I did comment that the rtc change also had to be separated
> from 1/7.
also this is put in separate commit, can you take a look before i post v3?
> Also, I really doubt this new compatible is necessary at all as you
> could simply directly use mediatek,mt6397-rtc.
imho this can confuse because the wrong chip-name is used in dts
regards Frank
^ permalink raw reply
* Re: suspend broken in next-20190704 on Thinkpad X60
From: Pavel Machek @ 2019-07-06 19:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Linux-pm mailing list, kernel list,
Stephen Rothwell
In-Reply-To: <CAJZ5v0irbn-Xd47KExw=h7On7KShCm6rThCo0q4-zn=o_x6_HQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
Hi!
> > > > Suspend is broken in next-20190704 on Thinkpad X60.
> > >
> > > Broken in what way? Any details?
> > >
> > > > It very very probably worked ok in 20190701.
> > >
> > > Well, please try the linux-next branch from linux-pm.git
> > > (git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git)
> > > alone and see if that fails.
> >
> > So... let me try this one?
> >
> > commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch)
...
> I'm not sure what you mean here. I'm guessing that you don't get back
> to the console from which you ran the pm-suspend command, but is X
> restored, for example? Is there any way to get into the system in
> that state?
>
> Anyway, if 5.2-rc7 is OK, something in this branch causes the problem
> to happen for you.
>
> I would try
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244
>
> to narrow down the scope somewhat.
pavel@amd:/data/l/linux-next-32$ git bisect log
# bad: [1e2a4c9019eb53f62790fadf86c14a54f4cf4888] Merge branch
'pm-cpufreq-new' into linux-next
# good: [f012a132824fc870b90980540f727c76fc72e244] Merge branches
'acpica', 'acpi-osl', 'acpi-tables', 'acpi-misc' and 'acpi-tools' into
linux-next
git bisect start '1e2a4c9019eb53f62790fadf86c14a54f4cf4888'
'f012a132824fc870b90980540f727c76fc72e244'
# good: [48a8a5f9a326d1c1a5505d51fb98086e5003f37e] Add linux-next
specific files for 20190701
git bisect good 48a8a5f9a326d1c1a5505d51fb98086e5003f37e
I think I can handle this... when I'm near the AC power.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
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