From: <Sergey.Semin@baikalelectronics.ru>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
Serge Semin <fancer.lancer@gmail.com>,
Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
Paul Burton <paulburton@kernel.org>,
Ralf Baechle <ralf@linux-mips.org>, <linux-mips@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: [PATCH 19/22] mips: Add udelay lpj numbers adjustment
Date: Fri, 6 Mar 2020 15:47:02 +0300 [thread overview]
Message-ID: <20200306124916.20636803079F@mail.baikalelectronics.ru> (raw)
In-Reply-To: <20200306124705.6595-1-Sergey.Semin@baikalelectronics.ru>
From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Loops-per-jiffies is a special number which represents a number of
noop-loop cycles per CPU-scheduler quantum - jiffies. As you
understand aside from CPU-specific implementation it depends on
the CPU frequency. So when a platform has the CPU frequency fixed,
we have no problem and the current udelay interface will work
just fine. But as soon as CPU-freq driver is enabled and the cores
frequency changes, we'll end up with distorted udelay's. In order
to fix this we have to accordinly adjust the per-CPU udelay_val
(the same as the global loops_per_jiffy) number. This can be done
in the CPU-freq transition event handler. We subscribe to that event
in the MIPS arch time-inititalization method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
---
arch/mips/kernel/time.c | 70 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c
index 37e9413a393d..ce89e18af024 100644
--- a/arch/mips/kernel/time.c
+++ b/arch/mips/kernel/time.c
@@ -18,12 +18,82 @@
#include <linux/smp.h>
#include <linux/spinlock.h>
#include <linux/export.h>
+#include <linux/cpufreq.h>
+#include <linux/delay.h>
#include <asm/cpu-features.h>
#include <asm/cpu-type.h>
#include <asm/div64.h>
#include <asm/time.h>
+#ifdef CONFIG_CPU_FREQ
+
+static DEFINE_PER_CPU(unsigned long, pcp_lpj_ref);
+static DEFINE_PER_CPU(unsigned long, pcp_lpj_ref_freq);
+static unsigned long glb_lpj_ref;
+static unsigned long glb_lpj_ref_freq;
+
+static int cpufreq_callback(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct cpufreq_freqs *freq = data;
+ struct cpumask *cpus = freq->policy->cpus;
+ unsigned long lpj;
+ int cpu;
+
+ /*
+ * Skip lpj numbers adjustment if the CPU-freq transition is safe for
+ * the loops delay. (Is this possible?)
+ */
+ if (freq->flags & CPUFREQ_CONST_LOOPS)
+ return NOTIFY_OK;
+
+ /* Save the initial values of the lpjes for future scaling. */
+ if (!glb_lpj_ref) {
+ glb_lpj_ref = boot_cpu_data.udelay_val;
+ glb_lpj_ref_freq = freq->old;
+
+ for_each_online_cpu(cpu) {
+ per_cpu(pcp_lpj_ref, cpu) =
+ cpu_data[cpu].udelay_val;
+ per_cpu(pcp_lpj_ref_freq, cpu) = freq->old;
+ }
+ }
+
+ /*
+ * Adjust global lpj variable and per-CPU udelay_val number in
+ * accordance with the new CPU frequency.
+ */
+ if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
+ (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
+ loops_per_jiffy = cpufreq_scale(glb_lpj_ref,
+ glb_lpj_ref_freq,
+ freq->new);
+
+ for_each_cpu(cpu, cpus) {
+ lpj = cpufreq_scale(per_cpu(pcp_lpj_ref, cpu),
+ per_cpu(pcp_lpj_ref_freq, cpu),
+ freq->new);
+ cpu_data[cpu].udelay_val = (unsigned int)lpj;
+ }
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block cpufreq_notifier = {
+ .notifier_call = cpufreq_callback,
+};
+
+static int __init register_cpufreq_notifier(void)
+{
+ return cpufreq_register_notifier(&cpufreq_notifier,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+core_initcall(register_cpufreq_notifier);
+
+#endif /* !CONFIG_CPU_FREQ */
+
/*
* forward reference
*/
--
2.25.1
next prev parent reply other threads:[~2020-03-06 12:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200306124705.6595-1-Sergey.Semin@baikalelectronics.ru>
2020-03-06 12:46 ` [PATCH 01/22] dt-bindings: Permit platform devices in the trivial-devices bindings Sergey.Semin
2020-03-06 13:56 ` Rob Herring
[not found] ` <20200306140550.0A68180307C4@mail.baikalelectronics.ru>
2020-03-10 1:09 ` Sergey Semin
2020-03-06 12:46 ` [PATCH 02/22] dt-bindings: Add MIPS CPC controller as a trivial devices Sergey.Semin
2020-03-06 12:46 ` [PATCH 03/22] dt-bindings: Add MIPS CDMM controller as a trivial device Sergey.Semin
2020-03-06 12:46 ` [PATCH 04/22] dt-bindings: Add vendor prefix for Baikal Electronics, JSC Sergey.Semin
2020-03-12 20:41 ` Rob Herring
2020-03-13 8:52 ` Sergey Semin
2020-03-12 20:44 ` Rob Herring
2020-03-13 9:40 ` Sergey Semin
2020-03-06 12:46 ` [PATCH 06/22] mips: cm: Add L2 ECC/parity errors reporting Sergey.Semin
2020-03-06 12:46 ` [PATCH 07/22] mips: Add MIPS32 Release 5 support Sergey.Semin
2020-03-06 12:46 ` [PATCH 08/22] mips: Add MIPS Warrior P5600 support Sergey.Semin
2020-03-06 12:46 ` [PATCH 10/22] mips: Add CP0 Write Merge config support Sergey.Semin
2020-03-06 12:46 ` [PATCH 11/22] mips: Add CONFIG/CONFIG6 reg fields macro Sergey.Semin
2020-03-06 12:46 ` [PATCH 12/22] mips: MAAR: Use more precise address mask Sergey.Semin
2020-03-06 12:46 ` [PATCH 13/22] mips: MAAR: Add XPA mode support Sergey.Semin
2020-03-06 12:46 ` [PATCH 14/22] mips: early_printk_8250: Use offset-sized IO-mem accessors Sergey.Semin
2020-03-06 12:46 ` [PATCH 15/22] mips: Use offset-sized IO-mem accessors in CPS debug printout Sergey.Semin
2020-03-06 12:46 ` [PATCH 16/22] mips: cdmm: Add mti,mips-cdmm dtb node support Sergey.Semin
2020-03-06 12:47 ` [PATCH 17/22] bus: cdmm: Add MIPS R5 arch support Sergey.Semin
2020-03-06 12:47 ` [PATCH 18/22] tty: mips_ejtag_fdc: Mark expected switch fall-through Sergey.Semin
2020-03-09 16:12 ` Jiri Slaby
[not found] ` <20200309161243.D5D5180307C7@mail.baikalelectronics.ru>
2020-03-10 1:06 ` Sergey Semin
2020-03-17 12:27 ` Jiri Slaby
2020-03-06 12:47 ` Sergey.Semin [this message]
2020-03-06 12:47 ` [PATCH 20/22] mips: csrc-r4k: Decrease r4k-clocksource rating if CPU_FREQ enabled Sergey.Semin
2020-03-06 12:47 ` [PATCH 21/22] mips: cevt-r4k: Update the r4k-clockevent frequency in sync with CPU Sergey.Semin
2020-03-10 1:01 ` [PATCH 00/22] mips: Prepare MIPS-arch code for Baikal-T1 SoC support Sergey Semin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200306124916.20636803079F@mail.baikalelectronics.ru \
--to=sergey.semin@baikalelectronics.ru \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=fancer.lancer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paulburton@kernel.org \
--cc=ralf@linux-mips.org \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®