Jason,
Could you please review my patch below?
See also arm64 maintainer's comment:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.h…
Thanks,
-Takahiro AKASHI
I tried to verify kgdb in vanilla kernel on fast model, but it seems that
the single stepping with kgdb doesn't work correctly since its first
appearance at v3.15.
On v3.15, 'stepi' command after breaking the kernel at some breakpoint
steps forward to the next instruction, but the succeeding 'stepi' never
goes beyond that.
On v3.16, 'stepi' moves forward and stops at the next instruction just
after enable_dbg in el1_dbg, and never goes beyond that. This variance of
behavior seems to come in with the following patch in v3.16:
commit 2a2830703a23 ("arm64: debug: avoid accessing mdscr_el1 on fault
paths where possible")
This patch
(1) moves kgdb_disable_single_step() from 'c' command handling to single
step handler.
This makes sure that single stepping gets effective at every 's' command.
Please note that, under the current implementation, single step bit in
spsr, which is cleared by the first single stepping, will not be set
again for the consecutive 's' commands because single step bit in mdscr
is still kept on (that is, kernel_active_single_step() in
kgdb_arch_handle_exception() is true).
(2) re-implements kgdb_roundup_cpus() because the current implementation
enabled interrupts naively. See below.
(3) removes 'enable_dbg' in el1_dbg.
Single step bit in mdscr is turned on in do_handle_exception()->
kgdb_handle_expection() before returning to debugged context, and if
debug exception is enabled in el1_dbg, we will see unexpected single-
stepping in el1_dbg.
Since v3.18, the following patch does the same:
commit 1059c6bf8534 ("arm64: debug: don't re-enable debug exceptions
on return from el1_dbg)
(4) masks interrupts while single-stepping one instruction.
If an interrupt is caught during processing a single-stepping, debug
exception is unintentionally enabled by el1_irq's 'enable_dbg' before
returning to debugged context.
Thus, like in (2), we will see unexpected single-stepping in el1_irq.
Basically (1) and (2) are for v3.15, (3) and (4) for v3.1[67].
* issue fixed by (2):
Without (2), we would see another problem if a breakpoint is set at
interrupt-sensible places, like gic_handle_irq():
KGDB: re-enter error: breakpoint removed ffffffc000081258
------------[ cut here ]------------
WARNING: CPU: 0 PID: 650 at kernel/debug/debug_core.c:435
kgdb_handle_exception+0x1dc/0x1f4()
Modules linked in:
CPU: 0 PID: 650 Comm: sh Not tainted 3.17.0-rc2+ #177
Call trace:
[<ffffffc000087fac>] dump_backtrace+0x0/0x130
[<ffffffc0000880ec>] show_stack+0x10/0x1c
[<ffffffc0004d683c>] dump_stack+0x74/0xb8
[<ffffffc0000ab824>] warn_slowpath_common+0x8c/0xb4
[<ffffffc0000ab90c>] warn_slowpath_null+0x14/0x20
[<ffffffc000121bfc>] kgdb_handle_exception+0x1d8/0x1f4
[<ffffffc000092ffc>] kgdb_brk_fn+0x18/0x28
[<ffffffc0000821c8>] brk_handler+0x9c/0xe8
[<ffffffc0000811e8>] do_debug_exception+0x3c/0xac
Exception stack(0xffffffc07e027650 to 0xffffffc07e027770)
...
[<ffffffc000083cac>] el1_dbg+0x14/0x68
[<ffffffc00012178c>] kgdb_cpu_enter+0x464/0x5c0
[<ffffffc000121bb4>] kgdb_handle_exception+0x190/0x1f4
[<ffffffc000092ffc>] kgdb_brk_fn+0x18/0x28
[<ffffffc0000821c8>] brk_handler+0x9c/0xe8
[<ffffffc0000811e8>] do_debug_exception+0x3c/0xac
Exception stack(0xffffffc07e027ac0 to 0xffffffc07e027be0)
...
[<ffffffc000083cac>] el1_dbg+0x14/0x68
[<ffffffc00032e4b4>] __handle_sysrq+0x11c/0x190
[<ffffffc00032e93c>] write_sysrq_trigger+0x4c/0x60
[<ffffffc0001e7d58>] proc_reg_write+0x54/0x84
[<ffffffc000192fa4>] vfs_write+0x98/0x1c8
[<ffffffc0001939b0>] SyS_write+0x40/0xa0
Once some interrupt occurs, a breakpoint at gic_handle_irq() triggers kgdb.
Kgdb then calls kgdb_roundup_cpus() to sync with other cpus.
Current kgdb_roundup_cpus() unmasks interrupts temporarily to
use smp_call_function().
This eventually allows another interrupt to occur and likely results in
hitting a breakpoint at gic_handle_irq() again since debug exception is
always enabled in el1_irq.
We can avoid this issue by specifying "nokgdbroundup" in kernel parameter,
but this will also leave other cpus be in unknown state in terms of kgdb,
and may result in interfering with kgdb activity.
Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
---
arch/arm64/kernel/kgdb.c | 60 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 46 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a0d10c5..81b5910 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -19,9 +19,13 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/cpumask.h>
#include <linux/irq.h>
+#include <linux/irq_work.h>
#include <linux/kdebug.h>
#include <linux/kgdb.h>
+#include <linux/percpu.h>
+#include <asm/ptrace.h>
#include <asm/traps.h>
struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
@@ -95,6 +99,9 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
{ "fpcr", 4, -1 },
};
+static DEFINE_PER_CPU(unsigned int, kgdb_pstate);
+static DEFINE_PER_CPU(struct irq_work, kgdb_irq_work);
+
char *dbg_get_reg(int regno, void *mem, struct pt_regs *regs)
{
if (regno >= DBG_MAX_REG_NUM || regno < 0)
@@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
* over and over again.
*/
kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
- atomic_set(&kgdb_cpu_doing_single_step, -1);
- kgdb_single_step = 0;
-
- /*
- * Received continue command, disable single step
- */
- if (kernel_active_single_step())
- kernel_disable_single_step();
err = 0;
break;
case 's':
+ /* mask interrupts while single stepping */
+ __this_cpu_write(kgdb_pstate, linux_regs->pstate);
+ linux_regs->pstate |= PSR_I_BIT;
+
/*
* Update step address value with address passed
* with step packet.
@@ -198,8 +201,6 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
*/
kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
atomic_set(&kgdb_cpu_doing_single_step, raw_smp_processor_id());
- kgdb_single_step = 1;
-
/*
* Enable single step handling
*/
@@ -229,6 +230,18 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr)
static int kgdb_step_brk_fn(struct pt_regs *regs, unsigned int esr)
{
+ unsigned int pstate;
+
+ kernel_disable_single_step();
+ atomic_set(&kgdb_cpu_doing_single_step, -1);
+
+ /* restore interrupt mask status */
+ pstate = __this_cpu_read(kgdb_pstate);
+ if (pstate & PSR_I_BIT)
+ regs->pstate |= PSR_I_BIT;
+ else
+ regs->pstate &= ~PSR_I_BIT;
+
kgdb_handle_exception(1, SIGTRAP, 0, regs);
return 0;
}
@@ -249,16 +262,27 @@ static struct step_hook kgdb_step_hook = {
.fn = kgdb_step_brk_fn
};
-static void kgdb_call_nmi_hook(void *ignored)
+static void kgdb_roundup_hook(struct irq_work *work)
{
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
void kgdb_roundup_cpus(unsigned long flags)
{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
+ int cpu;
+ struct cpumask mask;
+ struct irq_work *work;
+
+ mask = *cpu_online_mask;
+ cpumask_clear_cpu(smp_processor_id(), &mask);
+ cpu = cpumask_first(&mask);
+ if (cpu >= nr_cpu_ids)
+ return;
+
+ for_each_cpu(cpu, &mask) {
+ work = per_cpu_ptr(&kgdb_irq_work, cpu);
+ irq_work_queue_on(work, cpu);
+ }
}
static int __kgdb_notify(struct die_args *args, unsigned long cmd)
@@ -299,6 +323,8 @@ static struct notifier_block kgdb_notifier = {
int kgdb_arch_init(void)
{
int ret = register_die_notifier(&kgdb_notifier);
+ int cpu;
+ struct irq_work *work;
if (ret != 0)
return ret;
@@ -306,6 +332,12 @@ int kgdb_arch_init(void)
register_break_hook(&kgdb_brkpt_hook);
register_break_hook(&kgdb_compiled_brkpt_hook);
register_step_hook(&kgdb_step_hook);
+
+ for_each_possible_cpu(cpu) {
+ work = per_cpu_ptr(&kgdb_irq_work, cpu);
+ init_irq_work(work, kgdb_roundup_hook);
+ }
+
return 0;
}
--
1.7.9.5
This patch was initially intended to address a KVM issue described in
Geoff's kexec patch set[1]. But now the title of patch#1 would be more
suitable for the entire code as it was overhauled and, since the 4th
version, the fix is implemented as kvm cpu hotplug after Mark's comment.
I confirmed that it works with kexec under the following scenarios:
- boot 1st kernel
- run a guest OS
- (stop a guest OS)
- reboot 2nd kernel by kexec
- run a guest OS
test target: MediaTek MT8173-EVB
version: kernel v4.0-rc1 + Geoff's kexec v8 + Ard's patch[2]
But I didn't test other complicated scenarios with cpu hotplug.
On arm, Frediano[3] is no longer working on this issue as he left his
company. So patch#1 also has a stub definition for arm.
Changes from v4:
* restructured the patchset as cpu_init_hyp_mode() and kvm_cpu_reset() were
renamed to kvm_arch_hardware_{enable,disable}() respectively
* omitted some obvious arguments from __cpu_reset_hyp_mode().
Changes from v3:
* modified to use kvm cpu hotplug framework directly instead of reboot
notifier hook
Changes from v2:
* modified kvm_virt_to_trampoline() macro to fix a page-alignment issue[4]
Changes from v1:
* modified kvm_cpu_reset() implementation:
- define a macro to translate va to addr in trampoline
- use __hyp_default_vectors instead of kvm_get_hyp_stub_vectors()
- shuffle the arguments in __cpu_reset_hyp_mode()
- optimize TLB flush operations
* changed a patch#2's name
* added a patch#5 to add stub code for arm
[1] http://lists.infradead.org/pipermail/kexec/2015-April/335533.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/334002.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322231.…
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/334910.html
AKASHI Takahiro (2):
arm64: kvm: allows kvm cpu hotplug
arm64: kvm: remove !KEXEC dependency
arch/arm/include/asm/kvm_host.h | 10 ++++++-
arch/arm/include/asm/kvm_mmu.h | 1 +
arch/arm/kvm/arm.c | 58 ++++++++++++-------------------------
arch/arm/kvm/mmu.c | 5 ++++
arch/arm64/include/asm/kvm_host.h | 11 ++++++-
arch/arm64/include/asm/kvm_mmu.h | 1 +
arch/arm64/include/asm/virt.h | 9 ++++++
arch/arm64/kvm/Kconfig | 1 -
arch/arm64/kvm/hyp-init.S | 33 +++++++++++++++++++++
arch/arm64/kvm/hyp.S | 32 +++++++++++++++++---
10 files changed, 114 insertions(+), 47 deletions(-)
--
1.7.9.5
This patch set enables kdump (crash dump kernel) support on arm64 on top of
Geoff's kexec patchset.
In this version, there are some arm64-specific usage/constraints:
1) "mem=" boot parameter must be specified on crash dump kernel
if the system starts on uefi.
2) Kvm will not be enabled on crash dump kernel even if configured
See commit messages and Documentation/kdump/kdump.txt for details.
The only concern I have is whether or not we can use the exact same kernel
as both system kernel and crash dump kernel. The current arm64 kernel is
not relocatable in the exact sense but I see no problems in using the same
binary when testing kdump.
I tested the code with
- ATF v1.1 + EDK2(UEFI) v3.0-rc0
- kernel v4.0 + Geoff' kexec v9
on
- Base fast model, and
- MediaTek MT8173-EVB
using my own kexec-tools [1], currently v0.12.
You may want to start a kernel with the following boot parameter:
crashkernel=64M (or so, on model)
and try
$ kexec -p --load <vmlinux> --append ...
$ echo c > /proc/sysrq-trigger
To examine vmcore (/proc/vmcore), you should use
- gdb v7.7 or later
- crash + a small patch (to recognize v4.0 kernel)
Changes from v1:
* rebased to Geoff's v9
* tested this patchset on real hardware and fixed bugs:
- added cache flush operation in ipi_cpu_stop() when shutting down
the system. Otherwise, data saved in vmcore's note sections by
crash_save_cpu() might not be flushed to dumped memory and crash command
fail to fetch correct data.
I will address Mark's commit[2] after Geoff takes care of it on kexec.
- modified to use ioremap_cache() instead of ioremap() when reading
crash memory. Otherwise, accessing /proc/vmcore on crash dump kernel
might cause an alignment fault.
* allows reserve_crashkernel() to handle "crashkernel=xyz[MG]" correctly,
thanks to Pratyush Anand. And it now also enforces memory limit.
* moved reserve_crashkernel() and reserve_elfcorehdr() to
arm64_memblock_init() to clarify that they should be called before
dma_contignuous_reserve().
[1] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/338171.html
AKASHI Takahiro (5):
arm64: kdump: reserve memory for crash dump kernel
arm64: kdump: implement machine_crash_shutdown()
arm64: kdump: do not go into EL2 before starting a crash dump kernel
arm64: add kdump support
arm64: enable kdump in the arm64 defconfig
Documentation/kdump/kdump.txt | 31 +++++++++++++-
arch/arm64/Kconfig | 12 ++++++
arch/arm64/configs/defconfig | 1 +
arch/arm64/include/asm/kexec.h | 34 ++++++++++++++-
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/crash_dump.c | 71 +++++++++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec.c | 55 +++++++++++++++++++++++-
arch/arm64/kernel/process.c | 7 +++-
arch/arm64/kernel/setup.c | 8 +++-
arch/arm64/kernel/smp.c | 12 +++++-
arch/arm64/mm/init.c | 84 +++++++++++++++++++++++++++++++++++++
11 files changed, 309 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/kernel/crash_dump.c
--
1.7.9.5
This is the sequel to the first episode that started here:
http://article.gmane.org/gmane.linux.ports.arm.kernel/401353
Now that most of the first set has been merged upstream, here's the last
set to complete the cleanup. This mainly includes the removal of the
backward compatibility support plus some cosmetic changes.
The hisi04 backend, though, is instead converted to raw SMP operations
as it currently doesn't benefit from MCPM at all and doesn't fit well
with the new backend structure.
This series can also be obtained from the following Git repository:
http://git.linaro.org/people/nicolas.pitre/linux.git mcpm
The diffstat shows more code removal again:
arch/arm/common/mcpm_entry.c | 281 +++++++++++++----------------
arch/arm/include/asm/mcpm.h | 73 +++-----
arch/arm/mach-exynos/suspend.c | 8 +-
arch/arm/mach-hisi/platmcpm.c | 127 +++++--------
drivers/cpuidle/cpuidle-big_little.c | 8 +-
5 files changed, 198 insertions(+), 299 deletions(-)
This patchset implements a clock driver for STM32F42xxx and STM32F43xxx
series devices.
There are a few small caveats at the present:
1. Relies on "Add support to STMicroeletronics STM32 family", v8 by
Maxime Coquelin:
http://thread.gmane.org/gmane.linux.kernel.cross-arch/27569
2. Allocating ~80 clock components appears to fragment memory enough
to prevent busybox (.text is ~300K, non-XIP) from running getty.
I have to use "init=/bin/sh" to avoid OOM problems.
3. Support for I2S and SAI is not included in this patchset.
Daniel Thompson (3):
dt-bindings: Document the STM32F4 clock bindings
clk: stm32: Add clock driver for STM32F4[23]xxx devices
ARM: dts: stm32f429: Adopt STM32F4 clock driver
.../devicetree/bindings/clock/st,stm32-rcc.txt | 65 ++++
arch/arm/boot/dts/stm32f429.dtsi | 83 ++---
drivers/clk/Makefile | 1 +
drivers/clk/clk-stm32f4.c | 365 +++++++++++++++++++++
4 files changed, 457 insertions(+), 57 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
create mode 100644 drivers/clk/clk-stm32f4.c
--
2.1.0
Jason/Thomas:
This would be a resend except Steven Rostedt noticed a redundant
memory barrier I had copied from the x86 code. The redundant barrier
is now removed and there are no other changes since the code was posted
a fortnight ago. Any chance of taking the first five of these patches
via the irqchip route? The x86 patch has an ack from Ingo, printk has no
explicit maintainer and I've done plenty of bisectability tests on the
patchset so leaving the last patch for the next dev. cycle should be
no trouble.
This patchset modifies the GIC driver to allow it, on supported
platforms, to route IPI interrupts to FIQ. It then uses this
feature to implement arch_trigger_all_cpu_backtrace for arm.
In order to neatly bring in the changes for the arm we also rearrange
some of the existing x86 NMI code to make it architecture neutral.
The patchset http://thread.gmane.org/gmane.linux.kernel/1897765 , which
makes sched_clock() NMI/FIQ-safe, should be treated as a prerequisite
for the sixth and final patch in the series (which enables the feature
on ARM). Although sched_clock() is not called directly by any of the
code that runs from a FIQ handler it is possible for sched_clock() to be
called indirectly when the function tracer is enabled.
The patches have been runtime tested on two systems capable of
supporting FIQ (Freescale i.MX6 and STiH416) and two that do not
(vexpress-a9 and Qualcomm Snapdragon 600), the changes to the x86
logic were tested on qemu and all patches have been compile tested
on x86, arm and arm64.
Note: On platforms not capable of supporting FIQ, the IPI to generate a
backtrace will fall back to using IRQ for propagation instead.
The backtrace logic contains a timeout to we will not permanently
wedge the requesting CPU if other CPUs are not responsive.
v19:
* Remove redundant memory barrier inherited from the x86 code (Steven
Rostedt).
v18:
* Move printk_nmi_ functions out of printk.c and into their own
file, nmi_callback.c (Joe Perches/Steven Rostedt).
* Rename printk_nmi_ functions so their name matches their new home
(Joe Perches)
v17:
* Rename bl_migration_lock/unlock to gic_migration_lock/unlock
(Nicolas Pitre).
v16:
* Significant clean up of the printk patches (Thomas Gleixner).
Replacing macros with real functions, CONFIG_ARCH_WANT_NMI_PRINTK
-> CONFIG_PRINTK_NMI, prefixing global functions with printk_nmi,
removing pointless exports, removing cpu_mask from the interfaces,
removal of just-in-time initialization of trace buffers, prevented
call sites having to save state, rolled up variable declarations
into single lines.
* Dropped the sched_clock() patches from *this* patchset and managed
them separately (http://thread.gmane.org/gmane.linux.kernel/1879261 ).
The cross-dependancies between the patches are minimal; the backtrace
code only calls sched_clock() if we are ftracing and backtracing is
normally only triggered to report information about about a broken
system (although users can type SysRq-l for amusement, most use it
to find out why the system it dead).
* Squashed together the final two patches. Essentially these duplicated
the x86 code and slavishly avoided changing it before, in the next
patch, fixing it to work better on ARM. It seems better that the code
just works first time!
v15:
* Added a patch to make sched_clock safe to call from NMI (Stephen
Boyd). Note that sched_clock() is not called by the NMI handlers that
have been added for the arm but it could be called if tools such as
ftrace are deployed.
* Fixed some warnings picked up during bisectability testing.
v14:
* Moved a nmi_vprintk() and friends from arch/x86/kernel/apic/hw_nmi.c
to printk.c (Steven Rostedt)
v13:
* Updated the code to print the backtrace to replicate Steven Rostedt's
x86 work to make SysRq-l safe. This is pretty much a total rewrite of
patches 4 and 5.
v12:
* Squash first two patches into a single one and re-describe
(Thomas Gleixner).
* Improve description of "irqchip: gic: Make gic_raise_softirq FIQ-safe"
(Thomas Gleixner).
v11:
* Optimized gic_raise_softirq() by replacing a register read with
a memory read (Jason Cooper).
v10:
* Add a further patch to optimize away some of the locking on systems
where CONFIG_BL_SWITCHER is not set (Marc Zyngier). Compiles OK with
exynos_defconfig (which is the only defconfig to set this option).
* Whitespace fixes in patch 4. That patch previously used spaces for
alignment of new constants but the rest of the file used tabs.
v9:
* Improved documentation and structure of initial patch (now initial
two patches) to make gic_raise_softirq() safe to call from FIQ
(Thomas Gleixner).
* Avoid masking interrupts during gic_raise_softirq(). The use of the
read lock makes this redundant (because we can safely re-enter the
function).
v8:
* Fixed build on arm64 causes by a spurious include file in irq-gic.c.
v7-2 (accidentally released twice with same number):
* Fixed boot regression on vexpress-a9 (reported by Russell King).
* Rebased on v3.18-rc3; removed one patch from set that is already
included in mainline.
* Dropped arm64/fiq.h patch from the set (still useful but not related
to issuing backtraces).
v7:
* Re-arranged code within the patch series to fix a regression
introduced midway through the series and corrected by a later patch
(testing by Olof's autobuilder). Tested offending patch in isolation
using defconfig identified by the autobuilder.
v6:
* Renamed svc_entry's call_trace argument to just trace (example code
from Russell King).
* Fixed mismatched ENDPROC() in __fiq_abt (example code from Russell
King).
* Modified usr_entry to optional avoid calling into the trace code and
used this in FIQ entry from usr path. Modified corresponding exit code
to avoid calling into trace code and the scheduler (example code from
Russell King).
* Ensured the default FIQ register state is restored when the default
FIQ handler is reinstalled (example code from Russell King).
* Renamed no_fiq_insn to dfl_fiq_insn to reflect the effect of adopting
a default FIQ handler.
* Re-instated fiq_safe_migration_lock and associated logic in
gic_raise_softirq(). gic_raise_softirq() is called by wake_up_klogd()
in the console unlock logic.
v5:
* Rebased on 3.17-rc4.
* Removed a spurious line from the final "glue it together" patch
that broke the build.
v4:
* Replaced push/pop with stmfd/ldmfd respectively (review of Nicolas
Pitre).
* Really fix bad pt_regs pointer generation in __fiq_abt.
* Remove fiq_safe_migration_lock and associated logic in
gic_raise_softirq() (review of Russell King)
* Restructured to introduce the default FIQ handler first, before the
new features (review of Russell King).
v3:
* Removed redundant header guards from arch/arm64/include/asm/fiq.h
(review of Catalin Marinas).
* Moved svc_exit_via_fiq macro to entry-header.S (review of Nicolas
Pitre).
v2:
* Restructured to sit nicely on a similar FYI patchset from Russell
King. It now effectively replaces the work in progress final patch
with something much more complete.
* Implemented (and tested) a Thumb-2 implementation of svc_exit_via_fiq
(review of Nicolas Pitre)
* Dropped the GIC group 0 workaround patch. The issue of FIQ interrupts
being acknowledged by the IRQ handler does still exist but should be
harmless because the IRQ handler will still wind up calling
ipi_cpu_backtrace().
* Removed any dependency on CONFIG_FIQ; all cpu backtrace effectively
becomes a platform feature (although the use of non-maskable
interrupts to implement it is best effort rather than guaranteed).
* Better comments highlighting usage of RAZ/WI registers (and parts of
registers) in the GIC code.
Changes *before* v1:
* This patchset is a hugely cut-down successor to "[PATCH v11 00/19]
arm: KGDB NMI/FIQ support". Thanks to Thomas Gleixner for suggesting
the new structure. For historic details see:
https://lkml.org/lkml/2014/9/2/227
* Fix bug in __fiq_abt (no longer passes a bad struct pt_regs value).
In fixing this we also remove the useless indirection previously
found in the fiq_handler macro.
* Make default fiq handler "always on" by migrating from fiq.c to
traps.c and replace do_unexp_fiq with the new handler (review
of Russell King).
* Add arm64 version of fiq.h (review of Russell King)
* Removed conditional branching and code from irq-gic.c, this is
replaced by much simpler code that relies on the GIC specification's
heavy use of read-as-zero/write-ignored (review of Russell King)
Daniel Thompson (6):
irqchip: gic: Optimize locking in gic_raise_softirq
irqchip: gic: Make gic_raise_softirq FIQ-safe
irqchip: gic: Introduce plumbing for IPI FIQ
printk: Simple implementation for NMI backtracing
x86/nmi: Use common printk functions
ARM: Add support for on-demand backtrace of other CPUs
arch/arm/Kconfig | 1 +
arch/arm/include/asm/hardirq.h | 2 +-
arch/arm/include/asm/irq.h | 5 +
arch/arm/include/asm/smp.h | 3 +
arch/arm/kernel/smp.c | 81 ++++++++++++++++
arch/arm/kernel/traps.c | 8 +-
arch/x86/Kconfig | 1 +
arch/x86/kernel/apic/hw_nmi.c | 101 ++------------------
drivers/irqchip/irq-gic.c | 203 +++++++++++++++++++++++++++++++++++++---
include/linux/irqchip/arm-gic.h | 8 ++
include/linux/printk.h | 20 ++++
init/Kconfig | 3 +
kernel/printk/Makefile | 1 +
kernel/printk/nmi_backtrace.c | 147 +++++++++++++++++++++++++++++
14 files changed, 473 insertions(+), 111 deletions(-)
create mode 100644 kernel/printk/nmi_backtrace.c
--
2.1.0
From: Kevin Hilman <khilman(a)linaro.org>
Using the current exynos_defconfig on the exynos5422-odroid-xu3, only
6 of 8 CPUs come online with MCPM boot. CPU0 is an A7, CPUs 1-4 are
A15s and CPU5-7 are the other A7s, but with the current code, CPUs 5
and 7 do not boot:
[...]
Exynos MCPM support installed
CPU1: update cpu_capacity 1535
CPU1: thread -1, cpu 0, socket 0, mpidr 80000000
CPU2: update cpu_capacity 1535
CPU2: thread -1, cpu 1, socket 0, mpidr 80000001
CPU3: update cpu_capacity 1535
CPU3: thread -1, cpu 2, socket 0, mpidr 80000002
CPU4: update cpu_capacity 1535
CPU4: thread -1, cpu 3, socket 0, mpidr 80000003
CPU5: failed to come online
CPU6: update cpu_capacity 448
CPU6: thread -1, cpu 2, socket 1, mpidr 80000102
CPU7: failed to come online
Brought up 6 CPUs
CPU: WARNING: CPU(s) started in wrong/inconsistent modes
(primary CPU mode 0x13)
CPU: This may indicate a broken bootloader or firmware.
Thanks to a tip from Abhilash, this patch gets all 8 CPUs booting
again, but the warning about CPUs started in inconsistent modes
remains. Also, not being terribly familiar with Exynos internals,
it's not at all obvious to me why this register write (done for *all*
secondaries) makes things work works for the 2 secondary CPUs that
didn't come online. It's also not obvious whether this is the right
general fix, since it doesn't seem to be needed on other 542x or 5800
platforms.
I suspect the "right" fix is in the bootloader someplace, but not
knowing this hardware well, I'm not sure if the fix is in u-boot
proper, or somewhere in the binary blobs (bl1/bl2/tz) that start
before u-boot. The u-boot I'm using is from the hardkernel u-boot
repo[1], and I'd welcome any suggestions to try. I'm able to rebuild
my own u-boot from there, but only have binaries for bl1/bl2/tz.
[1] branch "odroidxu3-v2012.07" of: https://github.com/hardkernel/u-boot.git
Cc: Mauro Ribeiro <mauro.ribeiro(a)hardkernel.com>
Cc: Abhilash Kesavan <a.kesavan(a)samsung.com>,
Cc: Andrew Bresticker <abrestic(a)chromium.org>
Cc: Doug Anderson <dianders(a)chromium.org>
Cc: Nicolas Pitre <nicolas.pitre(a)linaro.org>
Signed-off-by: Kevin Hilman <khilman(a)linaro.org>
---
arch/arm/mach-exynos/mcpm-exynos.c | 2 ++
arch/arm/mach-exynos/regs-pmu.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index b0d3c2e876fb..612a770d5284 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -88,6 +88,8 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
cluster >= EXYNOS5420_NR_CLUSTERS)
return -EINVAL;
+ pmu_raw_writel(0x1, S5P_PMU_SPARE2);
+
/*
* Since this is called with IRQs enabled, and no arch_spin_lock_irq
* variant exists, we need to disable IRQs manually here.
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index b5f4406fc1b5..70d9eb5a4fcc 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -49,6 +49,7 @@
#define S5P_INFORM5 0x0814
#define S5P_INFORM6 0x0818
#define S5P_INFORM7 0x081C
+#define S5P_PMU_SPARE2 0x0908
#define S5P_PMU_SPARE3 0x090C
#define EXYNOS_IROM_DATA2 0x0988
--
2.1.3
From: Rob Clark <robdclark(a)gmail.com>
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer. The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.
Signed-off-by: Rob Clark <robdclark(a)gmail.com>
[sumits: Minor updates wrt comments]
Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org>
---
v3: include Robin Murphy's fix[1] for handling '0' as a value for
max_segment_count
v2: minor updates wrt comments on the first version
[1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/
include/linux/device.h | 1 +
include/linux/dma-mapping.h | 19 +++++++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index fb506738f7b7..a32f9b67315c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
* sg limitations.
*/
unsigned int max_segment_size;
+ unsigned int max_segment_count; /* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
};
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb4bfa6..d3351a36d5ec 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct device *dev,
return -EIO;
}
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+ if (dev->dma_parms && dev->dma_parms->max_segment_count)
+ return dev->dma_parms->max_segment_count;
+ return DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+ unsigned int count)
+{
+ if (dev->dma_parms) {
+ dev->dma_parms->max_segment_count = count;
+ return 0;
+ }
+ return -EIO;
+}
+
static inline unsigned long dma_get_seg_boundary(struct device *dev)
{
return dev->dma_parms ?
--
1.9.1
Hi,
V5 got some more review comments, Acks, etc.. and they are all updated
in V6.
V5->V6:
- Acks/RBY from Rob and Nishanth added
- Lots of rewording suggested by Nishanth
- OPP Descriptor node is named OPP Table node now and so 'opp' is
replaced by 'opp_table' in examples, as suggested by Nishanth.
- OPP entries are named as 'oppX' instead of 'entry*' as suggested by
Nishanth.
- Phandles to slow and fast OPPs in 2/3 are named appropriately.
V4->V5:
- opp-microamp fixed and rewritten as per Mark's suggestions.
- shared-opp renamed as opp-shared, as that's the convention for other
properties.
- Dropped "[V4 3/3] OPP: Add 'opp-next' in operating-points-v2 bindings"
as that was NAK'd by Mike T..
- Added [V5 3/3] based on Nishanth's suggestions.
- Added an example for 2/3, multiple OPP nodes.
- Other minor formatting..
- Existing binding: "operating-points" isn't deprecated now as platforms
looking for simple bindings should be allowed to use them.
- opp-khz is changed to opp-hz, examples updated.
- turbo-mode explained
V3->V4:
- Dropped code changes as we are still concerned about bindings.
- separated out into three patches, some of which might be NAK'd. :)
- The first patch presents basic OPP stuff that was reviewed earlier. It
also has support for multiple regulators, with values for both current
and voltage.
- Second patch is based on a special concern that Stephen had about
multiple OPP tables, one of which the parsing code will select at
runtime.
- Third one separates out 'opp-next' or Intermediate freq support as
Mike T. had few concerns over it. He wanted the clock driver to take
care of this and so do not want it to be passed by DT and used by
cpufreq. Also, there were concerns like the platform may not want to
choose intermediate frequency as a target frequency for longer runs,
which wasn't prevented in earlier bindings. And so it is kept
separate to be NAK'd quietly, without much disturbances.
---------------x-------------------x------------------------
Current OPP (Operating performance point) device tree bindings have been
insufficient due to the inflexible nature of the original bindings. Over
time, we have realized that Operating Performance Point definitions and
usage is varied depending on the SoC and a "single size (just frequency,
voltage) fits all" model which the original bindings attempted and
failed.
The proposed next generation of the bindings addresses by providing a
expandable binding for OPPs and introduces the following common
shortcomings seen with the original bindings:
- Getting clock/voltage/current rails sharing information between CPUs.
Shared by all cores vs independent clock per core vs shared clock per
cluster.
- Support for specifying current levels along with voltages.
- Support for multiple regulators.
- Support for turbo modes.
- Other per OPP settings: transition latencies, disabled status, etc.?
- Expandability of OPPs in future.
This patchset introduces new bindings "operating-points-v2" to get these
problems solved. Refer to the bindings for more details.
We now have multiple versions of OPP binding and only one of them should
be used per device.
Viresh Kumar (3):
OPP: Add new bindings to address shortcomings of existing bindings
OPP: Allow multiple OPP tables to be passed via DT
OPP: Add binding for 'opp-suspend'
Documentation/devicetree/bindings/power/opp.txt | 439 +++++++++++++++++++++++-
1 file changed, 435 insertions(+), 4 deletions(-)
--
2.4.0