* [PATCH v6 2/7] MIPS: JZ4780: Introduce SMP support.
From: 周琰杰 (Zhou Yanjie) @ 2020-02-20 16:24 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-clk, devicetree, tglx, ralf, paulburton,
jiaxun.yang, chenhc, sboyd, mturquette, mark.rutland, robh+dt,
daniel.lezcano, paul, geert+renesas, krzk, ebiederm,
miquel.raynal, keescook, sernia.zhou, zhenwenjin, dongsheng.qiu
In-Reply-To: <1582215889-113034-1-git-send-email-zhouyanjie@wanyeetech.com>
Forward port smp support from kernel 3.18.3 of CI20_linux
to upstream kernel 5.6.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
Notes:
v1->v2:
1.Remove unnecessary "plat_irq_dispatch(void)" in irq-ingenic.c.
2.Add a timeout check for "jz4780_boot_secondary()" to avoid a dead loop.
3.Replace hard code in smp.c with macro.
v2->v3:
1.Remove unnecessary "extern void (*r4k_blast_dcache)(void)" in smp.c.
2.Use "for_each_of_cpu_node" instead "for_each_compatible_node" in smp.c.
3.Use "of_cpu_node_to_id" instead "of_property_read_u32_index" in smp.c.
4.Move LCR related operations to jz4780-cgu.c.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
1.Splitting changes involving "jz4780-cgu.c" into separate commit.
2.Use "request_irq()" replace "setup_irq()".
v5->v6:
In order to have a kernel that works on multiple SoCs at the same
time, use "IS_ENABLED()" replace "#ifdef".
arch/mips/include/asm/mach-jz4740/smp.h | 81 ++++++++++
arch/mips/jz4740/Kconfig | 3 +
arch/mips/jz4740/Makefile | 5 +
arch/mips/jz4740/prom.c | 4 +
arch/mips/jz4740/smp-entry.S | 57 +++++++
arch/mips/jz4740/smp.c | 254 ++++++++++++++++++++++++++++++++
arch/mips/kernel/idle.c | 36 ++++-
7 files changed, 439 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/include/asm/mach-jz4740/smp.h
create mode 100644 arch/mips/jz4740/smp-entry.S
create mode 100644 arch/mips/jz4740/smp.c
diff --git a/arch/mips/include/asm/mach-jz4740/smp.h b/arch/mips/include/asm/mach-jz4740/smp.h
new file mode 100644
index 00000000..af3c21b
--- /dev/null
+++ b/arch/mips/include/asm/mach-jz4740/smp.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
+ * JZ4780 SMP definitions
+ */
+
+#ifndef __MIPS_ASM_MACH_JZ4740_JZ4780_SMP_H__
+#define __MIPS_ASM_MACH_JZ4740_JZ4780_SMP_H__
+
+#define read_c0_corectrl() __read_32bit_c0_register($12, 2)
+#define write_c0_corectrl(val) __write_32bit_c0_register($12, 2, val)
+
+#define read_c0_corestatus() __read_32bit_c0_register($12, 3)
+#define write_c0_corestatus(val) __write_32bit_c0_register($12, 3, val)
+
+#define read_c0_reim() __read_32bit_c0_register($12, 4)
+#define write_c0_reim(val) __write_32bit_c0_register($12, 4, val)
+
+#define read_c0_mailbox0() __read_32bit_c0_register($20, 0)
+#define write_c0_mailbox0(val) __write_32bit_c0_register($20, 0, val)
+
+#define read_c0_mailbox1() __read_32bit_c0_register($20, 1)
+#define write_c0_mailbox1(val) __write_32bit_c0_register($20, 1, val)
+
+#define smp_clr_pending(mask) do { \
+ unsigned int stat; \
+ stat = read_c0_corestatus(); \
+ stat &= ~((mask) & 0xff); \
+ write_c0_corestatus(stat); \
+ } while (0)
+
+/*
+ * Core Control register
+ */
+#define CORECTRL_SLEEP1M_SHIFT 17
+#define CORECTRL_SLEEP1M (_ULCAST_(0x1) << CORECTRL_SLEEP1M_SHIFT)
+#define CORECTRL_SLEEP0M_SHIFT 16
+#define CORECTRL_SLEEP0M (_ULCAST_(0x1) << CORECTRL_SLEEP0M_SHIFT)
+#define CORECTRL_RPC1_SHIFT 9
+#define CORECTRL_RPC1 (_ULCAST_(0x1) << CORECTRL_RPC1_SHIFT)
+#define CORECTRL_RPC0_SHIFT 8
+#define CORECTRL_RPC0 (_ULCAST_(0x1) << CORECTRL_RPC0_SHIFT)
+#define CORECTRL_SWRST1_SHIFT 1
+#define CORECTRL_SWRST1 (_ULCAST_(0x1) << CORECTRL_SWRST1_SHIFT)
+#define CORECTRL_SWRST0_SHIFT 0
+#define CORECTRL_SWRST0 (_ULCAST_(0x1) << CORECTRL_SWRST0_SHIFT)
+
+/*
+ * Core Status register
+ */
+#define CORESTATUS_SLEEP1_SHIFT 17
+#define CORESTATUS_SLEEP1 (_ULCAST_(0x1) << CORESTATUS_SLEEP1_SHIFT)
+#define CORESTATUS_SLEEP0_SHIFT 16
+#define CORESTATUS_SLEEP0 (_ULCAST_(0x1) << CORESTATUS_SLEEP0_SHIFT)
+#define CORESTATUS_IRQ1P_SHIFT 9
+#define CORESTATUS_IRQ1P (_ULCAST_(0x1) << CORESTATUS_IRQ1P_SHIFT)
+#define CORESTATUS_IRQ0P_SHIFT 8
+#define CORESTATUS_IRQ0P (_ULCAST_(0x1) << CORESTATUS_IRQ8P_SHIFT)
+#define CORESTATUS_MIRQ1P_SHIFT 1
+#define CORESTATUS_MIRQ1P (_ULCAST_(0x1) << CORESTATUS_MIRQ1P_SHIFT)
+#define CORESTATUS_MIRQ0P_SHIFT 0
+#define CORESTATUS_MIRQ0P (_ULCAST_(0x1) << CORESTATUS_MIRQ0P_SHIFT)
+
+/*
+ * Reset Entry & IRQ Mask register
+ */
+#define REIM_ENTRY_SHIFT 16
+#define REIM_ENTRY (_ULCAST_(0xffff) << REIM_ENTRY_SHIFT)
+#define REIM_IRQ1M_SHIFT 9
+#define REIM_IRQ1M (_ULCAST_(0x1) << REIM_IRQ1M_SHIFT)
+#define REIM_IRQ0M_SHIFT 8
+#define REIM_IRQ0M (_ULCAST_(0x1) << REIM_IRQ0M_SHIFT)
+#define REIM_MBOXIRQ1M_SHIFT 1
+#define REIM_MBOXIRQ1M (_ULCAST_(0x1) << REIM_MBOXIRQ1M_SHIFT)
+#define REIM_MBOXIRQ0M_SHIFT 0
+#define REIM_MBOXIRQ0M (_ULCAST_(0x1) << REIM_MBOXIRQ0M_SHIFT)
+
+extern void jz4780_smp_init(void);
+extern void jz4780_secondary_cpu_entry(void);
+
+#endif /* __MIPS_ASM_MACH_JZ4740_JZ4780_SMP_H__ */
diff --git a/arch/mips/jz4740/Kconfig b/arch/mips/jz4740/Kconfig
index 412d2fa..0239597 100644
--- a/arch/mips/jz4740/Kconfig
+++ b/arch/mips/jz4740/Kconfig
@@ -34,9 +34,12 @@ config MACH_JZ4770
config MACH_JZ4780
bool
+ select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select MIPS_CPU_SCACHE
+ select NR_CPUS_DEFAULT_2
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_HIGHMEM
+ select SYS_SUPPORTS_SMP
config MACH_X1000
bool
diff --git a/arch/mips/jz4740/Makefile b/arch/mips/jz4740/Makefile
index 6de14c0..0a0f024 100644
--- a/arch/mips/jz4740/Makefile
+++ b/arch/mips/jz4740/Makefile
@@ -12,3 +12,8 @@ CFLAGS_setup.o = -I$(src)/../../../scripts/dtc/libfdt
# PM support
obj-$(CONFIG_PM) += pm.o
+
+# SMP support
+
+obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_SMP) += smp-entry.o
diff --git a/arch/mips/jz4740/prom.c b/arch/mips/jz4740/prom.c
index ff4555c..026259e 100644
--- a/arch/mips/jz4740/prom.c
+++ b/arch/mips/jz4740/prom.c
@@ -8,10 +8,14 @@
#include <asm/bootinfo.h>
#include <asm/fw/fw.h>
+#include <asm/mach-jz4740/smp.h>
void __init prom_init(void)
{
fw_init_cmdline();
+
+ if (IS_ENABLED(CONFIG_MACH_JZ4780) && IS_ENABLED(CONFIG_SMP))
+ jz4780_smp_init();
}
void __init prom_free_prom_memory(void)
diff --git a/arch/mips/jz4740/smp-entry.S b/arch/mips/jz4740/smp-entry.S
new file mode 100644
index 00000000..20049a3
--- /dev/null
+++ b/arch/mips/jz4740/smp-entry.S
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
+ * JZ4780 SMP entry point
+ */
+
+#include <asm/addrspace.h>
+#include <asm/asm.h>
+#include <asm/asmmacro.h>
+#include <asm/cacheops.h>
+#include <asm/mipsregs.h>
+
+#define CACHE_SIZE (32 * 1024)
+#define CACHE_LINESIZE 32
+
+.extern jz4780_cpu_entry_sp
+.extern jz4780_cpu_entry_gp
+
+.section .text.smp-entry
+.balign 0x10000
+.set noreorder
+LEAF(jz4780_secondary_cpu_entry)
+ mtc0 zero, CP0_CAUSE
+
+ li t0, ST0_CU0
+ mtc0 t0, CP0_STATUS
+
+ /* cache setup */
+ li t0, KSEG0
+ ori t1, t0, CACHE_SIZE
+ mtc0 zero, CP0_TAGLO, 0
+1: cache Index_Store_Tag_I, 0(t0)
+ cache Index_Store_Tag_D, 0(t0)
+ bne t0, t1, 1b
+ addiu t0, t0, CACHE_LINESIZE
+
+ /* kseg0 cache attribute */
+ mfc0 t0, CP0_CONFIG, 0
+ ori t0, t0, CONF_CM_CACHABLE_NONCOHERENT
+ mtc0 t0, CP0_CONFIG, 0
+
+ /* pagemask */
+ mtc0 zero, CP0_PAGEMASK, 0
+
+ /* retrieve sp */
+ la t0, jz4780_cpu_entry_sp
+ lw sp, 0(t0)
+
+ /* retrieve gp */
+ la t0, jz4780_cpu_entry_gp
+ lw gp, 0(t0)
+
+ /* jump to the kernel in kseg0 */
+ la t0, smp_bootstrap
+ jr t0
+ nop
+ END(jz4780_secondary_cpu_entry)
diff --git a/arch/mips/jz4740/smp.c b/arch/mips/jz4740/smp.c
new file mode 100644
index 00000000..5fe0cf3
--- /dev/null
+++ b/arch/mips/jz4740/smp.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2013, Paul Burton <paul.burton@imgtec.com>
+ * JZ4780 SMP
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/sched.h>
+#include <linux/sched/task_stack.h>
+#include <linux/smp.h>
+#include <linux/tick.h>
+#include <asm/mach-jz4740/smp.h>
+#include <asm/smp-ops.h>
+
+static struct clk *cpu_clock_gates[CONFIG_NR_CPUS] = { NULL };
+
+u32 jz4780_cpu_entry_sp;
+u32 jz4780_cpu_entry_gp;
+
+static struct cpumask cpu_running;
+
+static DEFINE_SPINLOCK(smp_lock);
+
+static irqreturn_t mbox_handler(int irq, void *dev_id)
+{
+ int cpu = smp_processor_id();
+ u32 action, status;
+
+ spin_lock(&smp_lock);
+
+ switch (cpu) {
+ case 0:
+ action = read_c0_mailbox0();
+ write_c0_mailbox0(0);
+ break;
+ case 1:
+ action = read_c0_mailbox1();
+ write_c0_mailbox1(0);
+ break;
+ default:
+ panic("unhandled cpu %d!", cpu);
+ }
+
+ /* clear pending mailbox interrupt */
+ status = read_c0_corestatus();
+ status &= ~(CORESTATUS_MIRQ0P << cpu);
+ write_c0_corestatus(status);
+
+ spin_unlock(&smp_lock);
+
+ if (action & SMP_RESCHEDULE_YOURSELF)
+ scheduler_ipi();
+ if (action & SMP_CALL_FUNCTION)
+ generic_smp_call_function_interrupt();
+
+ return IRQ_HANDLED;
+}
+
+static void jz4780_smp_setup(void)
+{
+ u32 addr, reim;
+ int cpu;
+
+ reim = read_c0_reim();
+
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ __cpu_number_map[cpu] = cpu;
+ __cpu_logical_map[cpu] = cpu;
+ set_cpu_possible(cpu, true);
+ }
+
+ /* mask mailbox interrupts for this core */
+ reim &= ~REIM_MBOXIRQ0M;
+ write_c0_reim(reim);
+
+ /* clear mailboxes & pending mailbox IRQs */
+ write_c0_mailbox0(0);
+ write_c0_mailbox1(0);
+ write_c0_corestatus(0);
+
+ /* set reset entry point */
+ addr = KSEG1ADDR((u32)&jz4780_secondary_cpu_entry);
+ WARN_ON(addr & ~REIM_ENTRY);
+ reim &= ~REIM_ENTRY;
+ reim |= addr & REIM_ENTRY;
+
+ /* unmask mailbox interrupts for this core */
+ reim |= REIM_MBOXIRQ0M;
+ write_c0_reim(reim);
+ set_c0_status(STATUSF_IP3);
+ irq_enable_hazard();
+
+ cpumask_set_cpu(cpu, &cpu_running);
+}
+
+static void jz4780_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *cpu_node;
+ unsigned cpu, ctrl;
+ int err;
+
+ /* setup the mailbox IRQ */
+ err = request_irq(MIPS_CPU_IRQ_BASE + 3, mbox_handler,
+ IRQF_PERCPU | IRQF_NO_THREAD, "core mailbox", NULL);
+ if (err)
+ pr_err("request_irq() on core mailbox failed\n");
+
+ init_cpu_present(cpu_possible_mask);
+
+ ctrl = read_c0_corectrl();
+
+ for (cpu = 0; cpu < max_cpus; cpu++) {
+ /* use reset entry point from REIM register */
+ ctrl |= CORECTRL_RPC0 << cpu;
+ }
+
+ for_each_of_cpu_node(cpu_node) {
+ cpu = of_cpu_node_to_id(cpu_node);
+ if (cpu < 0) {
+ pr_err("Failed to read index of %s\n",
+ cpu_node->full_name);
+ continue;
+ }
+
+ cpu_clock_gates[cpu] = of_clk_get(cpu_node, 0);
+ if (IS_ERR(cpu_clock_gates[cpu])) {
+ cpu_clock_gates[cpu] = NULL;
+ continue;
+ }
+
+ err = clk_prepare(cpu_clock_gates[cpu]);
+ if (err)
+ pr_err("Failed to prepare CPU clock gate\n");
+ }
+
+ write_c0_corectrl(ctrl);
+}
+
+static int jz4780_boot_secondary(int cpu, struct task_struct *idle)
+{
+ unsigned long flags;
+ u32 ctrl;
+
+ spin_lock_irqsave(&smp_lock, flags);
+
+ /* ensure the core is in reset */
+ ctrl = read_c0_corectrl();
+ ctrl |= CORECTRL_SWRST0 << cpu;
+ write_c0_corectrl(ctrl);
+
+ /* ungate core clock */
+ if (cpu_clock_gates[cpu])
+ clk_enable(cpu_clock_gates[cpu]);
+
+ /* set entry sp/gp register values */
+ jz4780_cpu_entry_sp = __KSTK_TOS(idle);
+ jz4780_cpu_entry_gp = (u32)task_thread_info(idle);
+ smp_wmb();
+
+ /* take the core out of reset */
+ ctrl &= ~(CORECTRL_SWRST0 << cpu);
+ write_c0_corectrl(ctrl);
+
+ cpumask_set_cpu(cpu, &cpu_running);
+
+ spin_unlock_irqrestore(&smp_lock, flags);
+
+ return 0;
+}
+
+static void jz4780_init_secondary(void)
+{
+}
+
+static void jz4780_smp_finish(void)
+{
+ u32 reim;
+
+ spin_lock(&smp_lock);
+
+ /* unmask mailbox interrupts for this core */
+ reim = read_c0_reim();
+ reim |= REIM_MBOXIRQ0M << smp_processor_id();
+ write_c0_reim(reim);
+
+ spin_unlock(&smp_lock);
+
+ /* unmask interrupts for this core */
+ change_c0_status(ST0_IM, STATUSF_IP3 | STATUSF_IP2 |
+ STATUSF_IP1 | STATUSF_IP0);
+ irq_enable_hazard();
+
+ /* force broadcast timer */
+ tick_broadcast_force();
+}
+
+static void jz4780_send_ipi_single_locked(int cpu, unsigned int action)
+{
+ u32 mbox;
+
+ switch (cpu) {
+ case 0:
+ mbox = read_c0_mailbox0();
+ write_c0_mailbox0(mbox | action);
+ break;
+ case 1:
+ mbox = read_c0_mailbox1();
+ write_c0_mailbox1(mbox | action);
+ break;
+ default:
+ panic("unhandled cpu %d!", cpu);
+ }
+}
+
+static void jz4780_send_ipi_single(int cpu, unsigned int action)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&smp_lock, flags);
+ jz4780_send_ipi_single_locked(cpu, action);
+ spin_unlock_irqrestore(&smp_lock, flags);
+}
+
+static void jz4780_send_ipi_mask(const struct cpumask *mask,
+ unsigned int action)
+{
+ unsigned long flags;
+ int cpu;
+
+ spin_lock_irqsave(&smp_lock, flags);
+
+ for_each_cpu(cpu, mask)
+ jz4780_send_ipi_single_locked(cpu, action);
+
+ spin_unlock_irqrestore(&smp_lock, flags);
+}
+
+static struct plat_smp_ops jz4780_smp_ops = {
+ .send_ipi_single = jz4780_send_ipi_single,
+ .send_ipi_mask = jz4780_send_ipi_mask,
+ .init_secondary = jz4780_init_secondary,
+ .smp_finish = jz4780_smp_finish,
+ .boot_secondary = jz4780_boot_secondary,
+ .smp_setup = jz4780_smp_setup,
+ .prepare_cpus = jz4780_smp_prepare_cpus,
+};
+
+void jz4780_smp_init(void)
+{
+ register_smp_ops(&jz4780_smp_ops);
+}
diff --git a/arch/mips/kernel/idle.c b/arch/mips/kernel/idle.c
index 37f8e78..a3afd98 100644
--- a/arch/mips/kernel/idle.c
+++ b/arch/mips/kernel/idle.c
@@ -18,6 +18,7 @@
#include <asm/cpu-type.h>
#include <asm/idle.h>
#include <asm/mipsregs.h>
+#include <asm/r4kcache.h>
/*
* Not all of the MIPS CPUs have the "wait" instruction available. Moreover,
@@ -88,6 +89,34 @@ static void __cpuidle rm7k_wait_irqoff(void)
}
/*
+ * The Ingenic jz4780 SMP variant has to write back dirty cache lines before
+ * executing wait. The CPU & cache clock will be gated until we return from
+ * the wait, and if another core attempts to access data from our data cache
+ * during this time then it will lock up.
+ */
+void jz4780_smp_wait_irqoff(void)
+{
+ unsigned long pending = read_c0_cause() & read_c0_status() & CAUSEF_IP;
+
+ /*
+ * Going to idle has a significant overhead due to the cache flush so
+ * try to avoid it if we'll immediately be woken again due to an IRQ.
+ */
+ if (!need_resched() && !pending) {
+ r4k_blast_dcache();
+
+ __asm__(
+ " .set push \n"
+ " .set mips3 \n"
+ " sync \n"
+ " wait \n"
+ " .set pop \n");
+ }
+
+ local_irq_enable();
+}
+
+/*
* Au1 'wait' is only useful when the 32kHz counter is used as timer,
* since coreclock (and the cp0 counter) stops upon executing it. Only an
* interrupt can wake it, so they must be enabled before entering idle modes.
@@ -172,7 +201,6 @@ void __init check_wait(void)
case CPU_CAVIUM_OCTEON_PLUS:
case CPU_CAVIUM_OCTEON2:
case CPU_CAVIUM_OCTEON3:
- case CPU_XBURST:
case CPU_LOONGSON32:
case CPU_XLR:
case CPU_XLP:
@@ -246,6 +274,12 @@ void __init check_wait(void)
cpu_wait = r4k_wait;
*/
break;
+ case CPU_XBURST:
+ if (IS_ENABLED(CONFIG_MACH_JZ4780) &&
+ IS_ENABLED(CONFIG_SMP) && (NR_CPUS > 1))
+ cpu_wait = jz4780_smp_wait_irqoff;
+ else
+ cpu_wait = r4k_wait;
default:
break;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v6 4/7] clocksource: Ingenic: Add high resolution timer support for SMP.
From: 周琰杰 (Zhou Yanjie) @ 2020-02-20 16:24 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-clk, devicetree, tglx, ralf, paulburton,
jiaxun.yang, chenhc, sboyd, mturquette, mark.rutland, robh+dt,
daniel.lezcano, paul, geert+renesas, krzk, ebiederm,
miquel.raynal, keescook, sernia.zhou, zhenwenjin, dongsheng.qiu
In-Reply-To: <1582215889-113034-1-git-send-email-zhouyanjie@wanyeetech.com>
Enable clock event handling on per CPU core basis.
Make sure that interrupts raised on the first core execute
event handlers on the correct CPU core.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
1.Adjust function naming to make it more reasonable.
2.Replace function smp_call_function_single() with
smp_call_function_single_async() in order to resolve
the warning below:
[ 0.350942] smp: Brought up 1 node, 2 CPUs
[ 0.365497] ------------[ cut here ]------------
[ 0.365522] WARNING: CPU: 0 PID: 1 at kernel/smp.c:300 smp_call_function_single+0x110/0x200
[ 0.365533] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc1+ #5
[ 0.365537] Stack : 00000000 59c73bcd 00000037 80074e80 80000000 80670000 805a0000 80620590
[ 0.365557] 8065ce38 8fc0dc8c 806d0000 00000000 80670000 00000001 8fc0dc20 59c73bcd
[ 0.365574] 00000000 00000000 806f0000 80670000 00000000 806dab00 00000000 2d302e35
[ 0.365591] 203a6d6d 806e0000 806e0000 70617773 80670000 00000000 00000000 00000009
[ 0.365610] 00000000 8fc94e20 8fc0de30 80690000 00000018 803592dc 00000000 806d0000
[ 0.365627] ...
[ 0.365634] Call Trace:
[ 0.365647] [<8001b9a0>] show_stack+0x6c/0x12c
[ 0.365663] [<804aed20>] dump_stack+0x98/0xc8
[ 0.365673] [<8003044c>] __warn+0xc4/0xe8
[ 0.365682] [<800304f4>] warn_slowpath_fmt+0x84/0xb8
[ 0.365690] [<800a886c>] smp_call_function_single+0x110/0x200
[ 0.365703] ---[ end trace 5785856ca39c79d5 ]---
[ 0.365557] 8065ce38 8fc0dc8c 806d0000 00000000 80670000 00000001 8fc0dc20 59c73bcd
[ 0.365574] 00000000 00000000 806f0000 80670000 00000000 806dab00 00000000 2d302e35
[ 0.365591] 203a6d6d 806e0000 806e0000 70617773 80670000 00000000 00000000 00000009
[ 0.365610] 00000000 8fc94e20 8fc0de30 80690000 00000018 803592dc 00000000 806d0000
[ 0.365627] ...
[ 0.365634] Call Trace:
[ 0.365647] [<8001b9a0>] show_stack+0x6c/0x12c
[ 0.365663] [<804aed20>] dump_stack+0x98/0xc8
[ 0.365673] [<8003044c>] __warn+0xc4/0xe8
[ 0.365682] [<800304f4>] warn_slowpath_fmt+0x84/0xb8
[ 0.365690] [<800a886c>] smp_call_function_single+0x110/0x200
[ 0.365703] ---[ end trace 5785856ca39c79d5 ]---
v2->v3:
No Change.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
Move the check for (evt->event_handler) from "ingenic_per_cpu_event_handler"
to "ingenic_tcu_cevt_cb".
v5->v6:
No change.
drivers/clocksource/ingenic-timer.c | 113 +++++++++++++++++++++++++++++-------
1 file changed, 91 insertions(+), 22 deletions(-)
diff --git a/drivers/clocksource/ingenic-timer.c b/drivers/clocksource/ingenic-timer.c
index 4bbdb3d..e396326 100644
--- a/drivers/clocksource/ingenic-timer.c
+++ b/drivers/clocksource/ingenic-timer.c
@@ -1,7 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * JZ47xx SoCs TCU IRQ driver
+ * XBurst SoCs TCU IRQ driver
* Copyright (C) 2019 Paul Cercueil <paul@crapouillou.net>
+ * Copyright (C) 2020 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
*/
#include <linux/bitops.h>
@@ -21,18 +22,23 @@
#include <dt-bindings/clock/ingenic,tcu.h>
+static DEFINE_PER_CPU(call_single_data_t, ingenic_cevt_csd);
+
struct ingenic_soc_info {
unsigned int num_channels;
};
struct ingenic_tcu {
struct regmap *map;
+ struct device_node *np;
struct clk *timer_clk, *cs_clk;
+ unsigned int timer_local[NR_CPUS];
unsigned int timer_channel, cs_channel;
struct clock_event_device cevt;
struct clocksource cs;
- char name[4];
+ char name[8];
unsigned long pwm_channels_mask;
+ int cpu;
};
static struct ingenic_tcu *ingenic_tcu;
@@ -81,6 +87,24 @@ static int ingenic_tcu_cevt_set_next(unsigned long next,
return 0;
}
+static void ingenic_per_cpu_event_handler(void *info)
+{
+ struct clock_event_device *cevt = (struct clock_event_device *) info;
+
+ cevt->event_handler(cevt);
+}
+
+static void ingenic_tcu_per_cpu_cb(struct clock_event_device *evt)
+{
+ struct ingenic_tcu *tcu = to_ingenic_tcu(evt);
+ call_single_data_t *csd;
+
+ csd = &per_cpu(ingenic_cevt_csd, tcu->cpu);
+ csd->info = (void *) evt;
+ csd->func = ingenic_per_cpu_event_handler;
+ smp_call_function_single_async(tcu->cpu, csd);
+}
+
static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
{
struct clock_event_device *evt = dev_id;
@@ -89,7 +113,7 @@ static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
regmap_write(tcu->map, TCU_REG_TECR, BIT(tcu->timer_channel));
if (evt->event_handler)
- evt->event_handler(evt);
+ ingenic_tcu_per_cpu_cb(evt);
return IRQ_HANDLED;
}
@@ -105,14 +129,21 @@ static struct clk * __init ingenic_tcu_get_clock(struct device_node *np, int id)
return of_clk_get_from_provider(&args);
}
-static int __init ingenic_tcu_timer_init(struct device_node *np,
- struct ingenic_tcu *tcu)
+static int ingenic_tcu_setup_per_cpu_cevt(struct device_node *np,
+ unsigned int channel)
{
- unsigned int timer_virq, channel = tcu->timer_channel;
+ unsigned int timer_virq;
struct irq_domain *domain;
+ struct ingenic_tcu *tcu;
unsigned long rate;
int err;
+ tcu = kzalloc(sizeof(*tcu), GFP_KERNEL);
+ if (!tcu)
+ return -ENOMEM;
+
+ tcu->map = ingenic_tcu->map;
+
tcu->timer_clk = ingenic_tcu_get_clock(np, channel);
if (IS_ERR(tcu->timer_clk))
return PTR_ERR(tcu->timer_clk);
@@ -139,13 +170,15 @@ static int __init ingenic_tcu_timer_init(struct device_node *np,
goto err_clk_disable;
}
- snprintf(tcu->name, sizeof(tcu->name), "TCU");
+ snprintf(tcu->name, sizeof(tcu->name), "TCU%u", channel);
err = request_irq(timer_virq, ingenic_tcu_cevt_cb, IRQF_TIMER,
tcu->name, &tcu->cevt);
if (err)
goto err_irq_dispose_mapping;
+ tcu->cpu = smp_processor_id();
+ tcu->timer_channel = channel;
tcu->cevt.cpumask = cpumask_of(smp_processor_id());
tcu->cevt.features = CLOCK_EVT_FEAT_ONESHOT;
tcu->cevt.name = tcu->name;
@@ -166,6 +199,25 @@ static int __init ingenic_tcu_timer_init(struct device_node *np,
return err;
}
+static int ingenic_tcu_setup_cevt(unsigned int cpu)
+{
+ int ret;
+
+ ret = ingenic_tcu_setup_per_cpu_cevt(ingenic_tcu->np,
+ ingenic_tcu->timer_local[cpu]);
+ if (ret)
+ goto err_tcu_clocksource_cleanup;
+
+ return 0;
+
+err_tcu_clocksource_cleanup:
+ clocksource_unregister(&ingenic_tcu->cs);
+ clk_disable_unprepare(ingenic_tcu->cs_clk);
+ clk_put(ingenic_tcu->cs_clk);
+ kfree(ingenic_tcu);
+ return ret;
+}
+
static int __init ingenic_tcu_clocksource_init(struct device_node *np,
struct ingenic_tcu *tcu)
{
@@ -239,6 +291,7 @@ static int __init ingenic_tcu_init(struct device_node *np)
const struct ingenic_soc_info *soc_info = id->data;
struct ingenic_tcu *tcu;
struct regmap *map;
+ unsigned cpu = 0;
long rate;
int ret;
@@ -252,13 +305,18 @@ static int __init ingenic_tcu_init(struct device_node *np)
if (!tcu)
return -ENOMEM;
- /* Enable all TCU channels for PWM use by default except channels 0/1 */
- tcu->pwm_channels_mask = GENMASK(soc_info->num_channels - 1, 2);
+ /*
+ * Enable all TCU channels for PWM use by default except channels 0/1,
+ * and channel 2 if target CPU is JZ4780 and SMP is selected.
+ */
+ tcu->pwm_channels_mask = GENMASK(soc_info->num_channels - 1,
+ NR_CPUS + 1);
of_property_read_u32(np, "ingenic,pwm-channels-mask",
(u32 *)&tcu->pwm_channels_mask);
- /* Verify that we have at least two free channels */
- if (hweight8(tcu->pwm_channels_mask) > soc_info->num_channels - 2) {
+ /* Verify that we have at least NR_CPUS + 1 free channels */
+ if (hweight8(tcu->pwm_channels_mask) >
+ soc_info->num_channels - NR_CPUS + 1) {
pr_crit("%s: Invalid PWM channel mask: 0x%02lx\n", __func__,
tcu->pwm_channels_mask);
ret = -EINVAL;
@@ -266,13 +324,27 @@ static int __init ingenic_tcu_init(struct device_node *np)
}
tcu->map = map;
+ tcu->np = np;
ingenic_tcu = tcu;
- tcu->timer_channel = find_first_zero_bit(&tcu->pwm_channels_mask,
+ tcu->timer_local[cpu] = find_first_zero_bit(&tcu->pwm_channels_mask,
soc_info->num_channels);
- tcu->cs_channel = find_next_zero_bit(&tcu->pwm_channels_mask,
- soc_info->num_channels,
- tcu->timer_channel + 1);
+
+ if (NR_CPUS > 1) {
+ for (cpu = 1; cpu < NR_CPUS; cpu++)
+ tcu->timer_local[cpu] = find_next_zero_bit(
+ &tcu->pwm_channels_mask,
+ soc_info->num_channels,
+ tcu->timer_local[cpu - 1] + 1);
+
+ tcu->cs_channel = find_next_zero_bit(&tcu->pwm_channels_mask,
+ soc_info->num_channels,
+ tcu->timer_local[cpu-1] + 1);
+ } else {
+ tcu->cs_channel = find_next_zero_bit(&tcu->pwm_channels_mask,
+ soc_info->num_channels,
+ tcu->timer_local[cpu] + 1);
+ }
ret = ingenic_tcu_clocksource_init(np, tcu);
if (ret) {
@@ -280,9 +352,10 @@ static int __init ingenic_tcu_init(struct device_node *np)
goto err_free_ingenic_tcu;
}
- ret = ingenic_tcu_timer_init(np, tcu);
- if (ret)
- goto err_tcu_clocksource_cleanup;
+ /* Setup clock events on each CPU core */
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "Ingenic XBurst: online",
+ ingenic_tcu_setup_cevt, NULL);
+ WARN_ON(ret < 0);
/* Register the sched_clock at the end as there's no way to undo it */
rate = clk_get_rate(tcu->cs_clk);
@@ -290,10 +363,6 @@ static int __init ingenic_tcu_init(struct device_node *np)
return 0;
-err_tcu_clocksource_cleanup:
- clocksource_unregister(&tcu->cs);
- clk_disable_unprepare(tcu->cs_clk);
- clk_put(tcu->cs_clk);
err_free_ingenic_tcu:
kfree(tcu);
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 7/7] MIPS: CI20: Update defconfig to support SMP.
From: 周琰杰 (Zhou Yanjie) @ 2020-02-20 16:24 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-clk, devicetree, tglx, ralf, paulburton,
jiaxun.yang, chenhc, sboyd, mturquette, mark.rutland, robh+dt,
daniel.lezcano, paul, geert+renesas, krzk, ebiederm,
miquel.raynal, keescook, sernia.zhou, zhenwenjin, dongsheng.qiu
In-Reply-To: <1582215889-113034-1-git-send-email-zhouyanjie@wanyeetech.com>
Add "CONFIG_SMP=y" and "CONFIG_NR_CPUS=2" to support SMP.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
No change.
v2->v3:
No change.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
No change.
v5->v6:
No change.
arch/mips/configs/ci20_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index be41df2..3aadb2e 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -1,3 +1,5 @@
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_KERNEL_XZ=y
CONFIG_SYSVIPC=y
--
2.7.4
^ permalink raw reply related
* [PATCH v6 3/7] MIPS: CI20: Modify DTS to support high resolution timer for SMP.
From: 周琰杰 (Zhou Yanjie) @ 2020-02-20 16:24 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-clk, devicetree, tglx, ralf, paulburton,
jiaxun.yang, chenhc, sboyd, mturquette, mark.rutland, robh+dt,
daniel.lezcano, paul, geert+renesas, krzk, ebiederm,
miquel.raynal, keescook, sernia.zhou, zhenwenjin, dongsheng.qiu
In-Reply-To: <1582215889-113034-1-git-send-email-zhouyanjie@wanyeetech.com>
Modify DTS, change tcu channel from 2 to 3, channel #0 and #1 for
per core local timer, #2 for clocksource.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
No change.
v2->v3:
No change.
v3->v4:
Rebase on top of kernel 5.6-rc1.
v4->v5:
Move [5/6] in v4 to this patch, to ensure that we can
git-bisect without ending up with a broken kernel.
v5->v6:
No change.
arch/mips/boot/dts/ingenic/ci20.dts | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts b/arch/mips/boot/dts/ingenic/ci20.dts
index 37b9316..29437aa 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -455,7 +455,14 @@
};
&tcu {
- /* 3 MHz for the system timer and clocksource */
- assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER1>;
- assigned-clock-rates = <3000000>, <3000000>;
+ /* 3 MHz for the system timers, 750kHz for the clocksource */
+ assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER1>,
+ <&tcu TCU_CLK_TIMER2>;
+ assigned-clock-rates = <3000000>, <3000000>, <750000>;
+
+ /*
+ * Use channel #0 and #1 for the per core system timer,
+ * and use channel #2 for the clocksource.
+ */
+ ingenic,pwm-channels-mask = <0xF8>;
};
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v3 09/27] qcow2: Add l2_entry_size()
From: Max Reitz @ 2020-02-20 16:24 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <7927a81fc619c3e842fdf91f1909dc3ca444ba3c.1577014346.git.berto@igalia.com>
[-- Attachment #1.1: Type: text/plain, Size: 825 bytes --]
On 22.12.19 12:36, Alberto Garcia wrote:
> qcow2 images with subclusters have 128-bit L2 entries. The first 64
> bits contain the same information as traditional images and the last
> 64 bits form a bitmap with the status of each individual subcluster.
>
> Because of that we cannot assume that L2 entries are sizeof(uint64_t)
> anymore. This function returns the proper value for the image.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2-cluster.c | 12 ++++++------
> block/qcow2-refcount.c | 14 ++++++++------
> block/qcow2.c | 8 ++++----
> block/qcow2.h | 9 +++++++++
> 4 files changed, 27 insertions(+), 16 deletions(-)
Assuming qcow2_calc_prealloc_size() and qcow2_measure are fixed up in
patch 26:
Reviewed-by: Max Reitz <mreitz@redhat.com>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v6 0/7] Introduce SMP support for CI20 (based on JZ4780).
From: 周琰杰 (Zhou Yanjie) @ 2020-02-20 16:24 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-clk, devicetree, tglx, ralf, paulburton,
jiaxun.yang, chenhc, sboyd, mturquette, mark.rutland, robh+dt,
daniel.lezcano, paul, geert+renesas, krzk, ebiederm,
miquel.raynal, keescook, sernia.zhou, zhenwenjin, dongsheng.qiu
In-Reply-To: <1582215889-113034-1-git-send-email-zhouyanjie@wanyeetech.com>
Introduce SMP support for MIPS Creator CI20, which is
based on Ingenic JZ4780 SoC.
周琰杰 (Zhou Yanjie) (7):
clk: JZ4780: Add function for enable the second core.
MIPS: JZ4780: Introduce SMP support.
MIPS: CI20: Modify DTS to support high resolution timer for SMP.
clocksource: Ingenic: Add high resolution timer support for SMP.
dt-bindings: MIPS: Document Ingenic SoCs binding.
MIPS: Ingenic: Add 'cpus' node for Ingenic SoCs.
MIPS: CI20: Update defconfig to support SMP.
.../bindings/mips/ingenic/ingenic,cpu.yaml | 61 +++++
.../bindings/mips/ingenic/ingenic,soc.yaml | 34 +++
arch/mips/boot/dts/ingenic/ci20.dts | 13 +-
arch/mips/boot/dts/ingenic/jz4740.dtsi | 14 ++
arch/mips/boot/dts/ingenic/jz4770.dtsi | 15 +-
arch/mips/boot/dts/ingenic/jz4780.dtsi | 23 ++
arch/mips/boot/dts/ingenic/x1000.dtsi | 14 ++
arch/mips/configs/ci20_defconfig | 2 +
arch/mips/include/asm/mach-jz4740/smp.h | 81 +++++++
arch/mips/jz4740/Kconfig | 3 +
arch/mips/jz4740/Makefile | 5 +
arch/mips/jz4740/prom.c | 4 +
arch/mips/jz4740/smp-entry.S | 57 +++++
arch/mips/jz4740/smp.c | 254 +++++++++++++++++++++
arch/mips/kernel/idle.c | 36 ++-
drivers/clk/ingenic/jz4780-cgu.c | 55 ++++-
drivers/clocksource/ingenic-timer.c | 113 +++++++--
17 files changed, 752 insertions(+), 32 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
create mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,soc.yaml
create mode 100644 arch/mips/include/asm/mach-jz4740/smp.h
create mode 100644 arch/mips/jz4740/smp-entry.S
create mode 100644 arch/mips/jz4740/smp.c
--
2.7.4
^ permalink raw reply
* Re: question about iommu_need_mapping
From: Jerry Snitselaar @ 2020-02-20 16:24 UTC (permalink / raw)
To: Lu Baolu; +Cc: iommu, linux-kernel
In-Reply-To: <af5a148e-76bc-4aa4-dd1c-b04a5ffc56b1@linux.intel.com>
On Thu Feb 20 20, Lu Baolu wrote:
>Hi Jerry,
>
>On 2020/2/20 7:55, Jerry Snitselaar wrote:
>>Is it possible for a device to end up with dev->archdata.iommu == NULL
>>on iommu_need_mapping in the following instance:
>>
>>1. iommu_group has dma domain for default
>>2. device gets private identity domain in intel_iommu_add_device
>>3. iommu_need_mapping gets called with that device.
>>4. dmar_remove_one_dev_info sets dev->archdata.iommu = NULL via
>>unlink_domain_info.
>>5. request_default_domain_for_dev exits after checking that
>>group->default_domain
>> exists, and group->default_domain->type is dma.
>>6. iommu_request_dma_domain_for_dev returns 0 from
>>request_default_domain_for_dev
>> and a private dma domain isn't created for the device.
>>
>
>Yes. It's possible.
>
>>The case I was seeing went away with commit 9235cb13d7d1 ("iommu/vt-d:
>>Allow devices with RMRRs to use identity domain"), because it changed
>>which domain the group and devices were using, but it seems like it is
>>still a possibility with the code. Baolu, you mentioned possibly
>>removing the domain switch. Commit 98b2fffb5e27 ("iommu/vt-d: Handle
>>32bit device with identity default domain") makes it sound like the
>>domain switch is required.
>
>It's more "nice to have" than "required" if the iommu driver doesn't
>disable swiotlb explicitly. The device access of system memory higher
>than the device's addressing capability could go through the bounced
>buffer implemented in swiotlb.
>
>Best regards,
>baolu
Hi Baolu,
Would this mean switching to bounce_dma_ops instead?
Regards,
Jerry
>_______________________________________________
>iommu mailing list
>iommu@lists.linux-foundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: question about iommu_need_mapping
From: Jerry Snitselaar @ 2020-02-20 16:24 UTC (permalink / raw)
To: Lu Baolu; +Cc: Joerg Roedel, iommu, linux-kernel
In-Reply-To: <af5a148e-76bc-4aa4-dd1c-b04a5ffc56b1@linux.intel.com>
On Thu Feb 20 20, Lu Baolu wrote:
>Hi Jerry,
>
>On 2020/2/20 7:55, Jerry Snitselaar wrote:
>>Is it possible for a device to end up with dev->archdata.iommu == NULL
>>on iommu_need_mapping in the following instance:
>>
>>1. iommu_group has dma domain for default
>>2. device gets private identity domain in intel_iommu_add_device
>>3. iommu_need_mapping gets called with that device.
>>4. dmar_remove_one_dev_info sets dev->archdata.iommu = NULL via
>>unlink_domain_info.
>>5. request_default_domain_for_dev exits after checking that
>>group->default_domain
>> exists, and group->default_domain->type is dma.
>>6. iommu_request_dma_domain_for_dev returns 0 from
>>request_default_domain_for_dev
>> and a private dma domain isn't created for the device.
>>
>
>Yes. It's possible.
>
>>The case I was seeing went away with commit 9235cb13d7d1 ("iommu/vt-d:
>>Allow devices with RMRRs to use identity domain"), because it changed
>>which domain the group and devices were using, but it seems like it is
>>still a possibility with the code. Baolu, you mentioned possibly
>>removing the domain switch. Commit 98b2fffb5e27 ("iommu/vt-d: Handle
>>32bit device with identity default domain") makes it sound like the
>>domain switch is required.
>
>It's more "nice to have" than "required" if the iommu driver doesn't
>disable swiotlb explicitly. The device access of system memory higher
>than the device's addressing capability could go through the bounced
>buffer implemented in swiotlb.
>
>Best regards,
>baolu
Hi Baolu,
Would this mean switching to bounce_dma_ops instead?
Regards,
Jerry
>_______________________________________________
>iommu mailing list
>iommu@lists.linux-foundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH] fstests: add a another gap extent testcase for btrfs
From: Filipe Manana @ 2020-02-20 16:24 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs, kernel-team, fstests
In-Reply-To: <20200220143855.3883650-1-josef@toxicpanda.com>
On Thu, Feb 20, 2020 at 2:39 PM Josef Bacik <josef@toxicpanda.com> wrote:
>
> This is a testcase for a corner that I missed when trying to fix gap
> extents for btrfs. We would end up with gaps if we hole punched past
> isize and then extended past the gap in a specific way. This is a
> simple reproducer to show the problem, and has been properly fixed by my
> patches now.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
> tests/btrfs/204 | 85 +++++++++++++++++++++++++++++++++++++++++++++
> tests/btrfs/204.out | 5 +++
> tests/btrfs/group | 1 +
> 3 files changed, 91 insertions(+)
> create mode 100755 tests/btrfs/204
> create mode 100644 tests/btrfs/204.out
>
> diff --git a/tests/btrfs/204 b/tests/btrfs/204
> new file mode 100755
> index 00000000..0d5c4bed
> --- /dev/null
> +++ b/tests/btrfs/204
> @@ -0,0 +1,85 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020 Facebook. All Rights Reserved.
> +#
> +# FS QA Test 204
> +#
> +# Validate that without no-holes we do not get a i_size that is after a gap in
> +# the file extents on disk when punching a hole past i_size. This is fixed by
> +# the following patches
> +#
> +# btrfs: use the file extent tree infrastructure
> +# btrfs: replace all uses of btrfs_ordered_update_i_size
> +#
> +seq=`basename $0`
> +seqres=$RESULT_DIR/$seq
> +echo "QA output created by $seq"
> +
> +here=`pwd`
> +tmp=/tmp/$$
> +status=1 # failure is the default!
> +trap "_cleanup; exit \$status" 0 1 2 3 15
> +
> +_cleanup()
> +{
> + cd /
> + rm -f $tmp.*
> +}
> +
> +# get standard environment, filters and checks
> +. ./common/rc
> +. ./common/filter
> +. ./common/dmlogwrites
> +
> +# remove previous $seqres.full before test
> +rm -f $seqres.full
> +
> +# real QA test starts here
> +
> +# Modify as appropriate.
> +_supported_fs generic
> +_supported_os Linux
> +_require_test
> +_require_scratch
> +_require_log_writes
_require_xfs_io_command "falloc" "-k"
_require_xfs_io_command "fpunch"
> +
> +_log_writes_init $SCRATCH_DEV
> +_log_writes_mkfs "-O ^no-holes" >> $seqres.full 2>&1
> +
> +# There's not a straightforward way to commit the transaction without also
> +# flushing dirty pages, so shorten the commit interval to 1 so we're sure to get
> +# a commit with our broken file
> +_log_writes_mount -o commit=1
> +
> +# This creates a gap extent because fpunch doesn't insert hole extents past
> +# i_size
> +xfs_io -f -c "falloc -k 4k 8k" $SCRATCH_MNT/file
> +xfs_io -f -c "fpunch 4k 4k" $SCRATCH_MNT/file
> +
> +# The pwrite extends the i_size to cover the gap extent, and then the truncate
> +# sets the disk_i_size to 12k because it assumes everything was a-ok.
> +xfs_io -f -c "pwrite 0 4k" $SCRATCH_MNT/file | _filter_xfs_io
> +xfs_io -f -c "pwrite 0 8k" $SCRATCH_MNT/file | _filter_xfs_io
> +xfs_io -f -c "truncate 12k" $SCRATCH_MNT/file
> +
> +# Wait for a transaction commit
> +sleep 2
> +
> +_log_writes_unmount
> +_log_writes_remove
> +
> +cur=$(_log_writes_find_next_fua 0)
> +echo "cur=$cur" >> $seqres.full
> +while [ ! -z "$cur" ]; do
> + _log_writes_replay_log_range $cur $SCRATCH_DEV >> $seqres.full
> +
> + # We only care about the fs consistency, so just run fsck, we don't have
> + # to mount the fs to validate it
> + _check_scratch_fs
> +
> + cur=$(_log_writes_find_next_fua $(($cur + 1)))
> +done
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/btrfs/204.out b/tests/btrfs/204.out
> new file mode 100644
> index 00000000..44c7c8ae
> --- /dev/null
> +++ b/tests/btrfs/204.out
> @@ -0,0 +1,5 @@
> +QA output created by 204
> +wrote 4096/4096 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +wrote 8192/8192 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> diff --git a/tests/btrfs/group b/tests/btrfs/group
> index 6acc6426..7a840177 100644
> --- a/tests/btrfs/group
> +++ b/tests/btrfs/group
> @@ -206,3 +206,4 @@
> 201 auto quick punch log
> 202 auto quick subvol snapshot
> 203 auto quick send clone
> +204 auto quick log replay
"prealloc" and "punch" groups as well.
Since this just tests another variant of the same problem, maybe it
could be added to btrfs/172, since that test is very recent and you
authored it as well.
Anyway, I don't have a strong preference.
The test itself looks good to me, and with the _require_xfs_io_command
thing added and the groups (maybe Eryu can add these at commit time):
Reviewed-by: Filipe Manana <fdmanana@suse.com>
> --
> 2.24.1
>
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply
* Re: [RFC PATCH v3 08/27] qcow2: Add offset_to_sc_index()
From: Max Reitz @ 2020-02-20 16:19 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <e0747406459f85893c213381c165b4234c3cde96.1577014346.git.berto@igalia.com>
[-- Attachment #1.1: Type: text/plain, Size: 371 bytes --]
On 22.12.19 12:36, Alberto Garcia wrote:
> For a given offset, return the subcluster number within its cluster
> (i.e. with 32 subclusters per cluster it returns a number between 0
> and 31).
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2.h | 5 +++++
> 1 file changed, 5 insertions(+)
Reviewed-by: Max Reitz <mreitz@redhat.com>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v7 21/24] iomap: Restructure iomap_readpages_actor
From: Matthew Wilcox @ 2020-02-20 16:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-fsdevel, linux-ext4, linux-erofs,
linux-btrfs
In-Reply-To: <20200220154741.GB19577@infradead.org>
On Thu, Feb 20, 2020 at 07:47:41AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 19, 2020 at 01:01:00PM -0800, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > By putting the 'have we reached the end of the page' condition at the end
> > of the loop instead of the beginning, we can remove the 'submit the last
> > page' code from iomap_readpages(). Also check that iomap_readpage_actor()
> > didn't return 0, which would lead to an endless loop.
>
> I'm obviously biassed a I wrote the original code, but I find the new
> very much harder to understand (not that the previous one was easy, this
> is tricky code..).
Agreed, I found the original code hard to understand. I think this is
easier because now cur_page doesn't leak outside this loop, so it has
an obvious lifecycle.
I'm kind of optimistic for Dave Howells' iov_iter addition of an
ITER_MAPPING. That might simplify all of this code.
^ permalink raw reply
* Re: [PATCH v7 21/24] iomap: Restructure iomap_readpages_actor
From: Matthew Wilcox @ 2020-02-20 16:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200220154741.GB19577@infradead.org>
On Thu, Feb 20, 2020 at 07:47:41AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 19, 2020 at 01:01:00PM -0800, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > By putting the 'have we reached the end of the page' condition at the end
> > of the loop instead of the beginning, we can remove the 'submit the last
> > page' code from iomap_readpages(). Also check that iomap_readpage_actor()
> > didn't return 0, which would lead to an endless loop.
>
> I'm obviously biassed a I wrote the original code, but I find the new
> very much harder to understand (not that the previous one was easy, this
> is tricky code..).
Agreed, I found the original code hard to understand. I think this is
easier because now cur_page doesn't leak outside this loop, so it has
an obvious lifecycle.
I'm kind of optimistic for Dave Howells' iov_iter addition of an
ITER_MAPPING. That might simplify all of this code.
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 21/24] iomap: Restructure iomap_readpages_actor
From: Matthew Wilcox @ 2020-02-20 16:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200220154741.GB19577@infradead.org>
On Thu, Feb 20, 2020 at 07:47:41AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 19, 2020 at 01:01:00PM -0800, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > By putting the 'have we reached the end of the page' condition at the end
> > of the loop instead of the beginning, we can remove the 'submit the last
> > page' code from iomap_readpages(). Also check that iomap_readpage_actor()
> > didn't return 0, which would lead to an endless loop.
>
> I'm obviously biassed a I wrote the original code, but I find the new
> very much harder to understand (not that the previous one was easy, this
> is tricky code..).
Agreed, I found the original code hard to understand. I think this is
easier because now cur_page doesn't leak outside this loop, so it has
an obvious lifecycle.
I'm kind of optimistic for Dave Howells' iov_iter addition of an
ITER_MAPPING. That might simplify all of this code.
^ permalink raw reply
* [Cluster-devel] [PATCH v7 21/24] iomap: Restructure iomap_readpages_actor
From: Matthew Wilcox @ 2020-02-20 16:24 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200220154741.GB19577@infradead.org>
On Thu, Feb 20, 2020 at 07:47:41AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 19, 2020 at 01:01:00PM -0800, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > By putting the 'have we reached the end of the page' condition at the end
> > of the loop instead of the beginning, we can remove the 'submit the last
> > page' code from iomap_readpages(). Also check that iomap_readpage_actor()
> > didn't return 0, which would lead to an endless loop.
>
> I'm obviously biassed a I wrote the original code, but I find the new
> very much harder to understand (not that the previous one was easy, this
> is tricky code..).
Agreed, I found the original code hard to understand. I think this is
easier because now cur_page doesn't leak outside this loop, so it has
an obvious lifecycle.
I'm kind of optimistic for Dave Howells' iov_iter addition of an
ITER_MAPPING. That might simplify all of this code.
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Durrant, Paul @ 2020-02-20 16:23 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Valentin, Eduardo, peterz@infradead.org, benh@kernel.crashing.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, pavel@ucw.cz,
hpa@zytor.com, tglx@linutronix.de, sstabellini@kernel.org,
fllinden@amaozn.com, x86@kernel.org, mingo@redhat.com,
xen-devel@lists.xenproject.org, Singh, Balbir,
len.brown@intel.com, jgross@suse.com, konrad.wilk@oracle.com,
Agarwal, Anchal, bp@alien8.de, boris.ostrovsky@oracle.com,
axboe@kernel.dk, netdev@vger.kernel.org, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Kamata, Munehisa, vkuznets@redhat.com,
davem@davemloft.net, Woodhouse, David
In-Reply-To: <20200220154507.GO4679@Air-de-Roger>
> -----Original Message-----
> From: Roger Pau Monné <roger.pau@citrix.com>
> Sent: 20 February 2020 15:45
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: Agarwal, Anchal <anchalag@amazon.com>; Valentin, Eduardo
> <eduval@amazon.com>; len.brown@intel.com; peterz@infradead.org;
> benh@kernel.crashing.org; x86@kernel.org; linux-mm@kvack.org;
> pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de; sstabellini@kernel.org;
> fllinden@amaozn.com; Kamata, Munehisa <kamatam@amazon.com>;
> mingo@redhat.com; xen-devel@lists.xenproject.org; Singh, Balbir
> <sblbir@amazon.com>; axboe@kernel.dk; konrad.wilk@oracle.com;
> bp@alien8.de; boris.ostrovsky@oracle.com; jgross@suse.com;
> netdev@vger.kernel.org; linux-pm@vger.kernel.org; rjw@rjwysocki.net;
> linux-kernel@vger.kernel.org; vkuznets@redhat.com; davem@davemloft.net;
> Woodhouse, David <dwmw@amazon.co.uk>
> Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks
> for PM suspend and hibernation
>
> On Thu, Feb 20, 2020 at 08:54:36AM +0000, Durrant, Paul wrote:
> > > -----Original Message-----
> > > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> > > Roger Pau Monné
> > > Sent: 20 February 2020 08:39
> > > To: Agarwal, Anchal <anchalag@amazon.com>
> > > Cc: Valentin, Eduardo <eduval@amazon.com>; len.brown@intel.com;
> > > peterz@infradead.org; benh@kernel.crashing.org; x86@kernel.org; linux-
> > > mm@kvack.org; pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de;
> > > sstabellini@kernel.org; fllinden@amaozn.com; Kamata, Munehisa
> > > <kamatam@amazon.com>; mingo@redhat.com; xen-
> devel@lists.xenproject.org;
> > > Singh, Balbir <sblbir@amazon.com>; axboe@kernel.dk;
> > > konrad.wilk@oracle.com; bp@alien8.de; boris.ostrovsky@oracle.com;
> > > jgross@suse.com; netdev@vger.kernel.org; linux-pm@vger.kernel.org;
> > > rjw@rjwysocki.net; linux-kernel@vger.kernel.org; vkuznets@redhat.com;
> > > davem@davemloft.net; Woodhouse, David <dwmw@amazon.co.uk>
> > > Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add
> callbacks
> > > for PM suspend and hibernation
> > >
> > > Thanks for this work, please see below.
> > >
> > > On Wed, Feb 19, 2020 at 06:04:24PM +0000, Anchal Agarwal wrote:
> > > > On Tue, Feb 18, 2020 at 10:16:11AM +0100, Roger Pau Monné wrote:
> > > > > On Mon, Feb 17, 2020 at 11:05:53PM +0000, Anchal Agarwal wrote:
> > > > > > On Mon, Feb 17, 2020 at 11:05:09AM +0100, Roger Pau Monné wrote:
> > > > > > > On Fri, Feb 14, 2020 at 11:25:34PM +0000, Anchal Agarwal
> wrote:
> > > > > > Quiescing the queue seemed a better option here as we want to
> make
> > > sure ongoing
> > > > > > requests dispatches are totally drained.
> > > > > > I should accept that some of these notion is borrowed from how
> nvme
> > > freeze/unfreeze
> > > > > > is done although its not apple to apple comparison.
> > > > >
> > > > > That's fine, but I would still like to requests that you use the
> same
> > > > > logic (as much as possible) for both the Xen and the PM initiated
> > > > > suspension.
> > > > >
> > > > > So you either apply this freeze/unfreeze to the Xen suspension
> (and
> > > > > drop the re-issuing of requests on resume) or adapt the same
> approach
> > > > > as the Xen initiated suspension. Keeping two completely different
> > > > > approaches to suspension / resume on blkfront is not suitable long
> > > > > term.
> > > > >
> > > > I agree with you on overhaul of xen suspend/resume wrt blkfront is a
> > > good
> > > > idea however, IMO that is a work for future and this patch series
> should
> > > > not be blocked for it. What do you think?
> > >
> > > It's not so much that I think an overhaul of suspend/resume in
> > > blkfront is needed, it's just that I don't want to have two completely
> > > different suspend/resume paths inside blkfront.
> > >
> > > So from my PoV I think the right solution is to either use the same
> > > code (as much as possible) as it's currently used by Xen initiated
> > > suspend/resume, or to also switch Xen initiated suspension to use the
> > > newly introduced code.
> > >
> > > Having two different approaches to suspend/resume in the same driver
> > > is a recipe for disaster IMO: it adds complexity by forcing developers
> > > to take into account two different suspend/resume approaches when
> > > there's no need for it.
> >
> > I disagree. S3 or S4 suspend/resume (or perhaps we should call them
> power state transitions to avoid confusion) are quite different from Xen
> suspend/resume.
> > Power state transitions ought to be, and indeed are, visible to the
> software running inside the guest. Applications, as well as drivers, can
> receive notification and take whatever action they deem appropriate.
> > Xen suspend/resume OTOH is used when a guest is migrated and the code
> should go to all lengths possible to make any software running inside the
> guest (other than Xen specific enlightened code, such as PV drivers)
> completely unaware that anything has actually happened.
>
> So from what you say above PM state transitions are notified to all
> drivers, and Xen suspend/resume is only notified to PV drivers, and
> here we are speaking about blkfront which is a PV driver, and should
> get notified in both cases. So I'm unsure why the same (or at least
> very similar) approach can't be used in both cases.
>
> The suspend/resume approach proposed by this patch is completely
> different than the one used by a xenbus initiated suspend/resume, and
> I don't see a technical reason that warrants this difference.
>
Within an individual PV driver it may well be ok to use common mechanisms for connecting to the backend but issues will arise if any subsequent action is visible to the guest. E.g. a network frontend needs to issue gratuitous ARPs without anything else in the network stack (or monitoring the network stack) knowing that it has happened.
> I'm not saying that the approach used here is wrong, it's just that I
> don't see the point in having two different ways to do suspend/resume
> in the same driver, unless there's a technical reason for it, which I
> don't think has been provided.
The technical justification is that the driver needs to know what kind of suspend or resume it is doing, so that it doesn't do the wrong thing. There may also be differences in the state of the system e.g. in Windows, at least some of the resume-from-xen-suspend code runs with interrupts disabled (which is necessary to make sure enough state is restored before things become visible to other kernel code).
>
> I would be fine with switching xenbus initiated suspend/resume to also
> use the approach proposed here: freeze the queues and drain the shared
> rings before suspending.
>
I think abstracting away at the xenbus level to some degree is probably feasible, but some sort of flag should be passed to the individual drivers so they know what circumstances they are operating under.
> > So, whilst it may be possible to use common routines to, for example,
> re-establish PV frontend/backend communication, PV frontend code should be
> acutely aware of the circumstances they are operating in. I can cite
> example code in the Windows PV driver, which have supported guest S3/S4
> power state transitions since day 1.
>
> Hm, please bear with me, as I'm not sure I fully understand. Why isn't
> the current suspend/resume logic suitable for PM transitions?
>
I don’t know the details for Linux but it may well be to do with assumptions made about the system e.g. the ability to block waiting for something to happen on another CPU (which may have already been quiesced in a PM context).
> As said above, I'm happy to switch xenbus initiated suspend/resume to
> use the logic in this patch, but unless there's a technical reason for
> it I don't see why blkfront should have two completely different
> approaches to suspend/resume depending on whether it's a PM or a
> xenbus state change.
>
Hopefully what I said above illustrates why it may not be 100% common.
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* RE: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Durrant, Paul @ 2020-02-20 16:23 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Agarwal, Anchal, Valentin, Eduardo, len.brown@intel.com,
peterz@infradead.org, benh@kernel.crashing.org, x86@kernel.org,
linux-mm@kvack.org, pavel@ucw.cz, hpa@zytor.com,
tglx@linutronix.de, sstabellini@kernel.org, fllinden@amaozn.com,
Kamata, Munehisa, mingo@redhat.com,
xen-devel@lists.xenproject.org, Singh, Balbir, axboe@kernel.dk,
konrad.wilk@oracle.com, bp@alien8.de, boris.ostrovsky@oracle.com,
jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
vkuznets@redhat.com, davem@davemloft.net, Woodhouse, David
In-Reply-To: <20200220154507.GO4679@Air-de-Roger>
> -----Original Message-----
> From: Roger Pau Monné <roger.pau@citrix.com>
> Sent: 20 February 2020 15:45
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: Agarwal, Anchal <anchalag@amazon.com>; Valentin, Eduardo
> <eduval@amazon.com>; len.brown@intel.com; peterz@infradead.org;
> benh@kernel.crashing.org; x86@kernel.org; linux-mm@kvack.org;
> pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de; sstabellini@kernel.org;
> fllinden@amaozn.com; Kamata, Munehisa <kamatam@amazon.com>;
> mingo@redhat.com; xen-devel@lists.xenproject.org; Singh, Balbir
> <sblbir@amazon.com>; axboe@kernel.dk; konrad.wilk@oracle.com;
> bp@alien8.de; boris.ostrovsky@oracle.com; jgross@suse.com;
> netdev@vger.kernel.org; linux-pm@vger.kernel.org; rjw@rjwysocki.net;
> linux-kernel@vger.kernel.org; vkuznets@redhat.com; davem@davemloft.net;
> Woodhouse, David <dwmw@amazon.co.uk>
> Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks
> for PM suspend and hibernation
>
> On Thu, Feb 20, 2020 at 08:54:36AM +0000, Durrant, Paul wrote:
> > > -----Original Message-----
> > > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> > > Roger Pau Monné
> > > Sent: 20 February 2020 08:39
> > > To: Agarwal, Anchal <anchalag@amazon.com>
> > > Cc: Valentin, Eduardo <eduval@amazon.com>; len.brown@intel.com;
> > > peterz@infradead.org; benh@kernel.crashing.org; x86@kernel.org; linux-
> > > mm@kvack.org; pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de;
> > > sstabellini@kernel.org; fllinden@amaozn.com; Kamata, Munehisa
> > > <kamatam@amazon.com>; mingo@redhat.com; xen-
> devel@lists.xenproject.org;
> > > Singh, Balbir <sblbir@amazon.com>; axboe@kernel.dk;
> > > konrad.wilk@oracle.com; bp@alien8.de; boris.ostrovsky@oracle.com;
> > > jgross@suse.com; netdev@vger.kernel.org; linux-pm@vger.kernel.org;
> > > rjw@rjwysocki.net; linux-kernel@vger.kernel.org; vkuznets@redhat.com;
> > > davem@davemloft.net; Woodhouse, David <dwmw@amazon.co.uk>
> > > Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add
> callbacks
> > > for PM suspend and hibernation
> > >
> > > Thanks for this work, please see below.
> > >
> > > On Wed, Feb 19, 2020 at 06:04:24PM +0000, Anchal Agarwal wrote:
> > > > On Tue, Feb 18, 2020 at 10:16:11AM +0100, Roger Pau Monné wrote:
> > > > > On Mon, Feb 17, 2020 at 11:05:53PM +0000, Anchal Agarwal wrote:
> > > > > > On Mon, Feb 17, 2020 at 11:05:09AM +0100, Roger Pau Monné wrote:
> > > > > > > On Fri, Feb 14, 2020 at 11:25:34PM +0000, Anchal Agarwal
> wrote:
> > > > > > Quiescing the queue seemed a better option here as we want to
> make
> > > sure ongoing
> > > > > > requests dispatches are totally drained.
> > > > > > I should accept that some of these notion is borrowed from how
> nvme
> > > freeze/unfreeze
> > > > > > is done although its not apple to apple comparison.
> > > > >
> > > > > That's fine, but I would still like to requests that you use the
> same
> > > > > logic (as much as possible) for both the Xen and the PM initiated
> > > > > suspension.
> > > > >
> > > > > So you either apply this freeze/unfreeze to the Xen suspension
> (and
> > > > > drop the re-issuing of requests on resume) or adapt the same
> approach
> > > > > as the Xen initiated suspension. Keeping two completely different
> > > > > approaches to suspension / resume on blkfront is not suitable long
> > > > > term.
> > > > >
> > > > I agree with you on overhaul of xen suspend/resume wrt blkfront is a
> > > good
> > > > idea however, IMO that is a work for future and this patch series
> should
> > > > not be blocked for it. What do you think?
> > >
> > > It's not so much that I think an overhaul of suspend/resume in
> > > blkfront is needed, it's just that I don't want to have two completely
> > > different suspend/resume paths inside blkfront.
> > >
> > > So from my PoV I think the right solution is to either use the same
> > > code (as much as possible) as it's currently used by Xen initiated
> > > suspend/resume, or to also switch Xen initiated suspension to use the
> > > newly introduced code.
> > >
> > > Having two different approaches to suspend/resume in the same driver
> > > is a recipe for disaster IMO: it adds complexity by forcing developers
> > > to take into account two different suspend/resume approaches when
> > > there's no need for it.
> >
> > I disagree. S3 or S4 suspend/resume (or perhaps we should call them
> power state transitions to avoid confusion) are quite different from Xen
> suspend/resume.
> > Power state transitions ought to be, and indeed are, visible to the
> software running inside the guest. Applications, as well as drivers, can
> receive notification and take whatever action they deem appropriate.
> > Xen suspend/resume OTOH is used when a guest is migrated and the code
> should go to all lengths possible to make any software running inside the
> guest (other than Xen specific enlightened code, such as PV drivers)
> completely unaware that anything has actually happened.
>
> So from what you say above PM state transitions are notified to all
> drivers, and Xen suspend/resume is only notified to PV drivers, and
> here we are speaking about blkfront which is a PV driver, and should
> get notified in both cases. So I'm unsure why the same (or at least
> very similar) approach can't be used in both cases.
>
> The suspend/resume approach proposed by this patch is completely
> different than the one used by a xenbus initiated suspend/resume, and
> I don't see a technical reason that warrants this difference.
>
Within an individual PV driver it may well be ok to use common mechanisms for connecting to the backend but issues will arise if any subsequent action is visible to the guest. E.g. a network frontend needs to issue gratuitous ARPs without anything else in the network stack (or monitoring the network stack) knowing that it has happened.
> I'm not saying that the approach used here is wrong, it's just that I
> don't see the point in having two different ways to do suspend/resume
> in the same driver, unless there's a technical reason for it, which I
> don't think has been provided.
The technical justification is that the driver needs to know what kind of suspend or resume it is doing, so that it doesn't do the wrong thing. There may also be differences in the state of the system e.g. in Windows, at least some of the resume-from-xen-suspend code runs with interrupts disabled (which is necessary to make sure enough state is restored before things become visible to other kernel code).
>
> I would be fine with switching xenbus initiated suspend/resume to also
> use the approach proposed here: freeze the queues and drain the shared
> rings before suspending.
>
I think abstracting away at the xenbus level to some degree is probably feasible, but some sort of flag should be passed to the individual drivers so they know what circumstances they are operating under.
> > So, whilst it may be possible to use common routines to, for example,
> re-establish PV frontend/backend communication, PV frontend code should be
> acutely aware of the circumstances they are operating in. I can cite
> example code in the Windows PV driver, which have supported guest S3/S4
> power state transitions since day 1.
>
> Hm, please bear with me, as I'm not sure I fully understand. Why isn't
> the current suspend/resume logic suitable for PM transitions?
>
I don’t know the details for Linux but it may well be to do with assumptions made about the system e.g. the ability to block waiting for something to happen on another CPU (which may have already been quiesced in a PM context).
> As said above, I'm happy to switch xenbus initiated suspend/resume to
> use the logic in this patch, but unless there's a technical reason for
> it I don't see why blkfront should have two completely different
> approaches to suspend/resume depending on whether it's a PM or a
> xenbus state change.
>
Hopefully what I said above illustrates why it may not be 100% common.
Paul
^ permalink raw reply
* Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h
From: Christian Borntraeger @ 2020-02-20 16:23 UTC (permalink / raw)
To: Christoph Hellwig, Halil Pasic
Cc: linux-s390, Janosch Frank, Michael S. Tsirkin, Jason Wang,
Cornelia Huck, Ram Pai, linux-kernel, virtualization, iommu,
David Gibson, Michael Mueller, Lendacky, Thomas,
Viktor Mihajlovski, Robin Murphy
In-Reply-To: <20200220161146.GA12709@lst.de>
On 20.02.20 17:11, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 05:06:05PM +0100, Halil Pasic wrote:
>> Currently force_dma_unencrypted() is only used by the direct
>> implementation of the DMA API, and thus resides in dma-direct.h. But
>> there is nothing dma-direct specific about it: if one was -- for
>> whatever reason -- to implement custom DMA ops that have to in the
>> encrypted/protected scenarios dma-direct currently deals with, one would
>> need exactly this kind of information.
>
> I really don't think it has business being anywhre else, and your completely
> bogus second patch just proves the point.
From a users perspective it makes absolutely perfect sense to use the
bounce buffers when they are NEEDED.
Forcing the user to specify iommu_platform just because you need bounce buffers
really feels wrong. And obviously we have a severe performance issue
because of the indirections.
Now: I understand that you want to get this fixes differently, but maybe you
could help to outline how this could be fixed proper.
Christian
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h
From: Christian Borntraeger @ 2020-02-20 16:23 UTC (permalink / raw)
To: Christoph Hellwig, Halil Pasic
Cc: Michael S. Tsirkin, Jason Wang, Marek Szyprowski, Robin Murphy,
linux-s390, virtualization, linux-kernel, iommu, Janosch Frank,
Viktor Mihajlovski, Cornelia Huck, Ram Pai, Thiago Jung Bauermann,
David Gibson, Lendacky, Thomas, Michael Mueller
In-Reply-To: <20200220161146.GA12709@lst.de>
On 20.02.20 17:11, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 05:06:05PM +0100, Halil Pasic wrote:
>> Currently force_dma_unencrypted() is only used by the direct
>> implementation of the DMA API, and thus resides in dma-direct.h. But
>> there is nothing dma-direct specific about it: if one was -- for
>> whatever reason -- to implement custom DMA ops that have to in the
>> encrypted/protected scenarios dma-direct currently deals with, one would
>> need exactly this kind of information.
>
> I really don't think it has business being anywhre else, and your completely
> bogus second patch just proves the point.
From a users perspective it makes absolutely perfect sense to use the
bounce buffers when they are NEEDED.
Forcing the user to specify iommu_platform just because you need bounce buffers
really feels wrong. And obviously we have a severe performance issue
because of the indirections.
Now: I understand that you want to get this fixes differently, but maybe you
could help to outline how this could be fixed proper.
Christian
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Andrew F. Davis @ 2020-02-20 16:23 UTC (permalink / raw)
To: Tony Lindgren; +Cc: kbuild-all, linux-kernel, kbuild test robot, linux-omap
In-Reply-To: <20200220162012.GI37466@atomide.com>
On 2/20/20 11:20 AM, Tony Lindgren wrote:
> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
>>> Andrew,
>>>
>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
>>>> date: 3 weeks ago
>>>> config: arm-randconfig-a001-20200213 (attached as .config)
>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.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 c37baa06f8a970e4a533d41f7d33e5e57de5ad25
>>>> # save the attached .config to linux build tree
>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
>>>>
>>>> If you fix the issue, kindly add following tag
>>>> Reported-by: kbuild test robot <lkp@intel.com>
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
>>>
>>> Have you looked at this one? Looks like there's still an unhandled
>>> randconfig build case.
>>>
>>
>>
>> I've had a quick look, all the ARM config does:
>>
>> select HAVE_ARM_SMCCC if CPU_V7
>>
>> so I don't think this will happen in any real config, but if we want to
>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
>> on it.
>
> Seems to happen at least with omap2 only config where we don't have
> CPU_V7. Something like below seems to fix it.
>
> If that looks OK to you, I'll send out a proper fix.
>
This looks fine to me.
A better later fix might be to later stub out the actual __arm_smccc_smc
in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
get the fix.
Andrew
> Regards,
>
> Tony
>
> 8< -----------------------
> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> --- a/arch/arm/mach-omap2/omap-secure.c
> +++ b/arch/arm/mach-omap2/omap-secure.c
> @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> return ret;
> }
>
> +#ifdef CONFIG_HAVE_ARM_SMCCC
> void omap_smccc_smc(u32 fn, u32 arg)
> {
> struct arm_smccc_res res;
> @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> 0, 0, 0, 0, 0, 0, &res);
> WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> }
> +#else
> +void omap_smccc_smc(u32 fn, u32 arg)
> +{
> +}
> +#endif
>
> void omap_smc1(u32 fn, u32 arg)
> {
>
^ permalink raw reply
* Re: omap-secure.c:undefined reference to `__arm_smccc_smc'
From: Andrew F. Davis @ 2020-02-20 16:23 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200220162012.GI37466@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]
On 2/20/20 11:20 AM, Tony Lindgren wrote:
> * Andrew F. Davis <afd@ti.com> [200220 16:04]:
>> On 2/20/20 10:54 AM, Tony Lindgren wrote:
>>> Andrew,
>>>
>>> * kbuild test robot <lkp@intel.com> [200213 10:27]:
>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>>> head: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9
>>>> commit: c37baa06f8a970e4a533d41f7d33e5e57de5ad25 ARM: OMAP2+: Fix undefined reference to omap_secure_init
>>>> date: 3 weeks ago
>>>> config: arm-randconfig-a001-20200213 (attached as .config)
>>>> compiler: arm-linux-gnueabi-gcc (GCC) 7.5.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 c37baa06f8a970e4a533d41f7d33e5e57de5ad25
>>>> # save the attached .config to linux build tree
>>>> GCC_VERSION=7.5.0 make.cross ARCH=arm
>>>>
>>>> If you fix the issue, kindly add following tag
>>>> Reported-by: kbuild test robot <lkp@intel.com>
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>> arch/arm/mach-omap2/omap-secure.o: In function `omap_smccc_smc':
>>>>>> omap-secure.c:(.text+0x94): undefined reference to `__arm_smccc_smc'
>>>
>>> Have you looked at this one? Looks like there's still an unhandled
>>> randconfig build case.
>>>
>>
>>
>> I've had a quick look, all the ARM config does:
>>
>> select HAVE_ARM_SMCCC if CPU_V7
>>
>> so I don't think this will happen in any real config, but if we want to
>> prevent randconfig issue this we could force ARCH_OMAP2PLUS to "depend"
>> on it.
>
> Seems to happen at least with omap2 only config where we don't have
> CPU_V7. Something like below seems to fix it.
>
> If that looks OK to you, I'll send out a proper fix.
>
This looks fine to me.
A better later fix might be to later stub out the actual __arm_smccc_smc
in common code if CONFIG_HAVE_ARM_SMCCC is not set, so any platform will
get the fix.
Andrew
> Regards,
>
> Tony
>
> 8< -----------------------
> diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c
> --- a/arch/arm/mach-omap2/omap-secure.c
> +++ b/arch/arm/mach-omap2/omap-secure.c
> @@ -77,6 +77,7 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
> return ret;
> }
>
> +#ifdef CONFIG_HAVE_ARM_SMCCC
> void omap_smccc_smc(u32 fn, u32 arg)
> {
> struct arm_smccc_res res;
> @@ -85,6 +86,11 @@ void omap_smccc_smc(u32 fn, u32 arg)
> 0, 0, 0, 0, 0, 0, &res);
> WARN(res.a0, "Secure function call 0x%08x failed\n", fn);
> }
> +#else
> +void omap_smccc_smc(u32 fn, u32 arg)
> +{
> +}
> +#endif
>
> void omap_smc1(u32 fn, u32 arg)
> {
>
^ permalink raw reply
* Re: S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Martin Jansa @ 2020-02-20 16:23 UTC (permalink / raw)
To: Adrian Bunk; +Cc: openembeded-devel
In-Reply-To: <20200220161159.GB30034@localhost>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
On Thu, Feb 20, 2020 at 06:11:59PM +0200, Adrian Bunk wrote:
> On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
> > On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> > > On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> > > >...
> > > > Any idea why these aren't shown in our build?
> > > >...
> > >
> > > What is your mirror configuration?
> > >
> > > Default configuration downloads the tarball from [1].
> >
> > Maybe I'm missing your point, but these aren't fetch issues.
> >...
>
> MIRRORS = "" (and deleting the downloaded tar) is what I needed for
> getting a build failure.
OK, I see now, sorry.
That explains why it's not shown in khem's builds and might be broken
well before thud already, the tarball created here today:
$ tar xvf ../downloads/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
gpio/
gpio/trunk/
gpio/trunk/doc/
gpio/trunk/doc/hardware/
gpio/trunk/doc/hardware/GTA01Bv3/
gpio/trunk/doc/hardware/GTA01Bv3/gpio.txt
gpio/trunk/doc/hardware/GTA01Bv3/pmu-voltage.txt
...
while the corresponding tarball on mirror:
http://sources.openembedded.org/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
$ tar xvf gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
gpio/
gpio/gpio-s3c6410.c
gpio/Makefile
gpio/gpio.c
gpio/gpio-glamo.c
gpio/README
Will check when it got broken before thud.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply
* [PATCH RESEND v6 15/16] mm/gup: Allow to react to fatal signals
From: Peter Xu @ 2020-02-20 16:02 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Peter Xu, Martin Cracauer, Mike Rapoport, Hugh Dickins,
Jerome Glisse, Kirill A . Shutemov, Matthew Wilcox,
Pavel Emelyanov, Brian Geffon, Maya Gokhale, Denis Plotnikov,
Andrea Arcangeli, Johannes Weiner, Dr . David Alan Gilbert,
Linus Torvalds, Mike Kravetz, Marty McFadden, David Hildenbrand,
Bobby Powers, Mel Gorman
In-Reply-To: <20200220155353.8676-1-peterx@redhat.com>
The existing gup code does not react to the fatal signals in many code
paths. For example, in one retry path of gup we're still using
down_read() rather than down_read_killable(). Also, when doing page
faults we don't pass in FAULT_FLAG_KILLABLE as well, which means that
within the faulting process we'll wait in non-killable way as well.
These were spotted by Linus during the code review of some other
patches.
Let's allow the gup code to react to fatal signals to improve the
responsiveness of threads when during gup and being killed.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
mm/gup.c | 12 +++++++++---
mm/hugetlb.c | 3 ++-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index ec2b76f44a01..3f0cb14334ac 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -648,7 +648,7 @@ static int faultin_page(struct task_struct *tsk, struct vm_area_struct *vma,
if (*flags & FOLL_REMOTE)
fault_flags |= FAULT_FLAG_REMOTE;
if (locked)
- fault_flags |= FAULT_FLAG_ALLOW_RETRY;
+ fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
if (*flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT;
if (*flags & FOLL_TRIED) {
@@ -991,7 +991,7 @@ int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
address = untagged_addr(address);
if (unlocked)
- fault_flags |= FAULT_FLAG_ALLOW_RETRY;
+ fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
retry:
vma = find_extend_vma(mm, address);
@@ -1113,7 +1113,13 @@ static __always_inline long __get_user_pages_locked(struct task_struct *tsk,
break;
*locked = 1;
- down_read(&mm->mmap_sem);
+ ret = down_read_killable(&mm->mmap_sem);
+ if (ret) {
+ BUG_ON(ret > 0);
+ if (!pages_done)
+ pages_done = ret;
+ break;
+ }
ret = __get_user_pages(tsk, mm, start, 1, flags | FOLL_TRIED,
pages, NULL, locked);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ac9a28d51674..c342b091a7a4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4338,7 +4338,8 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
if (flags & FOLL_WRITE)
fault_flags |= FAULT_FLAG_WRITE;
if (locked)
- fault_flags |= FAULT_FLAG_ALLOW_RETRY;
+ fault_flags |= FAULT_FLAG_ALLOW_RETRY |
+ FAULT_FLAG_KILLABLE;
if (flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY |
FAULT_FLAG_RETRY_NOWAIT;
--
2.24.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH v6 3/6] public/xen.h: add a definition for a 'valid domid' mask
From: Ian Jackson @ 2020-02-20 16:22 UTC (permalink / raw)
To: Paul Durrant
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
Andrew Cooper, George Dunlap, Jan Beulich,
xen-devel@lists.xenproject.org
In-Reply-To: <20200219093754.2924-4-pdurrant@amazon.com>
Paul Durrant writes ("[PATCH v6 3/6] public/xen.h: add a definition for a 'valid domid' mask"):
> A subsequent patch will modify libxl to allow selection of a random domid
> value when creating domains. Valid values are limited to a width of 15 bits,
> so add an appropriate mask definition to the public header.
This is fine by me but I wonder if hypervisor maintainers would like
more rationale.
In the conversation where I asked you to split this out I wrote:
> > This is useful for programs which need to [explanation],
> > including for example, libxl, which is going to want to
> > randomly generate domids.
> >
> > Maybe it needs some explanation of why this belongs in the Xen
> > public headers rather than in some header available to libxc,
> > libxl and other tools stuff ?
Your commit message seems to me to explain the former but not the
latter. I don't know if hypervisor maintainers want the latter.
Anyway,
Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 49/52] drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call
From: Noralf Trønnes @ 2020-02-20 16:22 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: David Airlie, Intel Graphics Development, Maxime Ripard,
Eric Anholt, Thomas Zimmermann, Daniel Vetter, Kamlesh Gurudasani,
Sam Ravnborg, David Lechner
In-Reply-To: <20200219102122.1607365-50-daniel.vetter@ffwll.ch>
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback from all
> drivers, and remove the mipi_dbi_release() function.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: David Lechner <david@lechnology.com>
> Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> ---
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 49/52] drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call
From: Noralf Trønnes @ 2020-02-20 16:22 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: David Airlie, Intel Graphics Development, Thomas Zimmermann,
Daniel Vetter, Kamlesh Gurudasani, Sam Ravnborg, David Lechner
In-Reply-To: <20200219102122.1607365-50-daniel.vetter@ffwll.ch>
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback from all
> drivers, and remove the mipi_dbi_release() function.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: David Lechner <david@lechnology.com>
> Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
> Cc: "Noralf Trønnes" <noralf@tronnes.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> ---
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.