linaro-kernel May 2015

linaro-kernel@lists.linaro.org

44 participants
142 discussions

[PATCH 00/34] CPUFreq: Move freq change notifications out of drivers

by Viresh Kumar

Another 452 lines gone :) Total stats upto now for all the 5 patchsets: Viresh Kumar (186): ... 69 files changed, 700 insertions(+), 2451 deletions(-) Net: 1751 lines gone.. -----x-------------x---------------- Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code and so this patch introduces another flag: CPUFREQ_NO_NOTIFICATION, which will be set by such drivers. This is Fifth part of my cleanup work for CPUFreq, first three are (And obviously its rebased over them): 1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263 2: cpufreq: define generic routines for cpufreq drivers https://lkml.org/lkml/2013/8/10/48 3. CPUFreq: Implement light weight ->target(): for 3.13 https://lkml.org/lkml/2013/8/13/349 4. CPUFreq: set policy->cur in cpufreq core instead of drivers https://lkml.org/lkml/2013/8/14/288 All these are pushed here: https://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/… -- viresh Cc: Andrew Lunn <andrew(a)lunn.ch> Cc: David S. Miller <davem(a)davemloft.net> Cc: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> Cc: Eric Miao <eric.y.miao(a)gmail.com> Cc: Hans-Christian Egtvedt <egtvedt(a)samfundet.no> Cc: Jesper Nilsson <jesper.nilsson(a)axis.com> Cc: John Crispin <blogic(a)openwrt.org> Cc: Kukjin Kim <kgene.kim(a)samsung.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: linux-cris-kernel(a)axis.com Cc: Mikael Starvik <starvik(a)axis.com> Cc: Russell King <linux(a)arm.linux.org.uk> Cc: Santosh Shilimkar <santosh.shilimkar(a)ti.com> Cc: Sekhar Nori <nsekhar(a)ti.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Cc: sparclinux(a)vger.kernel.org Cc: spear-devel(a)list.st.com Cc: Stephen Warren <swarren(a)nvidia.com> Cc: Steven Miao <realmz6(a)gmail.com> Cc: Tony Luck <tony.luck(a)intel.com> Viresh Kumar (34): cpufreq: move freq change notifications to cpufreq core cpufreq: acpi: remove calls to cpufreq_notify_transition() cpufreq: arm_big_little: remove calls to cpufreq_notify_transition() cpufreq: at32ap: remove calls to cpufreq_notify_transition() cpufreq: blackfin: remove calls to cpufreq_notify_transition() cpufreq: cpu0: remove calls to cpufreq_notify_transition() cpufreq: cris: remove calls to cpufreq_notify_transition() cpufreq: davinci: remove calls to cpufreq_notify_transition() cpufreq: dbx500: remove calls to cpufreq_notify_transition() cpufreq: e_powersaver: remove calls to cpufreq_notify_transition() cpufreq: elanfreq: remove calls to cpufreq_notify_transition() cpufreq: exynos: remove calls to cpufreq_notify_transition() cpufreq: exynos5440: set CPUFREQ_NO_NOTIFICATION flag cpufreq: ia64-acpi: remove calls to cpufreq_notify_transition() cpufreq: imx6q: remove calls to cpufreq_notify_transition() cpufreq: kirkwood: remove calls to cpufreq_notify_transition() cpufreq: longhaul: set CPUFREQ_NO_NOTIFICATION flag cpufreq: loongson2: remove calls to cpufreq_notify_transition() cpufreq: maple: remove calls to cpufreq_notify_transition() cpufreq: omap: remove calls to cpufreq_notify_transition() cpufreq: p4-clockmod: remove calls to cpufreq_notify_transition() cpufreq: pasemi: remove calls to cpufreq_notify_transition() cpufreq: pmac: remove calls to cpufreq_notify_transition() cpufreq: powernow: remove calls to cpufreq_notify_transition() cpufreq: ppc: remove calls to cpufreq_notify_transition() cpufreq: pxa: remove calls to cpufreq_notify_transition() cpufreq: s3c: remove calls to cpufreq_notify_transition() cpufreq: s5pv210: remove calls to cpufreq_notify_transition() cpufreq: sa11x0: remove calls to cpufreq_notify_transition() cpufreq: sc520: remove calls to cpufreq_notify_transition() cpufreq: sparc: remove calls to cpufreq_notify_transition() cpufreq: SPEAr: remove calls to cpufreq_notify_transition() cpufreq: speedstep: remove calls to cpufreq_notify_transition() cpufreq: tegra: remove calls to cpufreq_notify_transition() drivers/cpufreq/acpi-cpufreq.c | 14 ++------- drivers/cpufreq/arm_big_little.c | 25 ++-------------- drivers/cpufreq/at32ap-cpufreq.c | 22 ++++++-------- drivers/cpufreq/blackfin-cpufreq.c | 22 +++++--------- drivers/cpufreq/cpufreq-cpu0.c | 33 ++++++++------------- drivers/cpufreq/cpufreq.c | 34 +++++++++++++++++++++ drivers/cpufreq/cris-artpec3-cpufreq.c | 8 ----- drivers/cpufreq/cris-etraxfs-cpufreq.c | 8 ----- drivers/cpufreq/davinci-cpufreq.c | 30 +++++++------------ drivers/cpufreq/dbx500-cpufreq.c | 22 +------------- drivers/cpufreq/e_powersaver.c | 23 ++------------- drivers/cpufreq/elanfreq.c | 13 -------- drivers/cpufreq/exynos-cpufreq.c | 28 +++++------------- drivers/cpufreq/exynos5440-cpufreq.c | 2 +- drivers/cpufreq/ia64-acpi-cpufreq.c | 19 ------------ drivers/cpufreq/imx6q-cpufreq.c | 39 ++++++++++-------------- drivers/cpufreq/kirkwood-cpufreq.c | 54 +++++++++++++--------------------- drivers/cpufreq/longhaul.c | 1 + drivers/cpufreq/loongson2_cpufreq.c | 16 ---------- drivers/cpufreq/maple-cpufreq.c | 18 +----------- drivers/cpufreq/omap-cpufreq.c | 39 +++++++++--------------- drivers/cpufreq/p4-clockmod.c | 10 ------- drivers/cpufreq/pasemi-cpufreq.c | 14 +-------- drivers/cpufreq/pmac32-cpufreq.c | 20 +++---------- drivers/cpufreq/pmac64-cpufreq.c | 18 +----------- drivers/cpufreq/powernow-k6.c | 8 ----- drivers/cpufreq/powernow-k7.c | 11 +------ drivers/cpufreq/powernow-k8.c | 15 +--------- drivers/cpufreq/ppc-corenet-cpufreq.c | 19 +----------- drivers/cpufreq/ppc_cbe_cpufreq.c | 19 +----------- drivers/cpufreq/pxa2xx-cpufreq.c | 27 ++++------------- drivers/cpufreq/pxa3xx-cpufreq.c | 12 -------- drivers/cpufreq/s3c2416-cpufreq.c | 21 +++---------- drivers/cpufreq/s3c64xx-cpufreq.c | 48 ++++++++++-------------------- drivers/cpufreq/s5pv210-cpufreq.c | 16 ++++------ drivers/cpufreq/sa1100-cpufreq.c | 17 ++++------- drivers/cpufreq/sa1110-cpufreq.c | 12 ++------ drivers/cpufreq/sc520_freq.c | 11 ------- drivers/cpufreq/sparc-us2e-cpufreq.c | 7 ----- drivers/cpufreq/sparc-us3-cpufreq.c | 7 ----- drivers/cpufreq/spear-cpufreq.c | 13 +------- drivers/cpufreq/speedstep-centrino.c | 20 +------------ drivers/cpufreq/speedstep-ich.c | 9 ------ drivers/cpufreq/speedstep-smi.c | 7 ----- drivers/cpufreq/tegra-cpufreq.c | 25 ++++------------ include/linux/cpufreq.h | 6 ++++ 46 files changed, 205 insertions(+), 657 deletions(-) -- 1.7.12.rc2.18.g61b472e

6 years, 7 months

[RESEND PATCH] arm64: kgdb: fix single stepping

by AKASHI Takahiro

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

7 years, 8 months

[PATCH v5 0/2] arm64: kvm: reset hyp context for kexec

by AKASHI Takahiro

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

8 years, 7 months

[v2 0/5] arm64: add kdump support

by AKASHI Takahiro

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

8 years, 9 months

[PATCH 0/5] Second round of MCPM refactoring

by Nicolas Pitre

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(-)

8 years, 10 months

[RFC PATCH 0/3] clk: stm32: Add clock driver for STM32F4[23]xxx devices

by Daniel Thompson

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

8 years, 11 months

[PATCH 4.0-rc5 v19 0/6] irq/arm: Implement arch_trigger_all_cpu_backtrace

by Daniel Thompson

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

8 years, 11 months

[RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?

by Kevin Hilman

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

8 years, 11 months

[RFCv3 1/2] device: add dma_params->max_segment_count

by Sumit Semwal

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

8 years, 12 months

[PATCH V6 0/3] OPP: Introduce OPP (V2) bindings

by Viresh Kumar

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

8 years, 12 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel May 2015