* Re: linux-next: manual merge of the isci tree with the scsi tree
From: Williams, Dan J @ 2012-03-13 2:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, James Bottomley
In-Reply-To: <20120313134512.848baf17f46729fa0fac195d@canb.auug.org.au>
On Mon, Mar 12, 2012 at 7:45 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Dan,
>
> Today's linux-next merge of the isci tree produced a large number of
> conflicts against the scsi.
>
> Merging isci/all
> +CONFLICT (content): Merge conflict in include/scsi/sas_ata.h
> CONFLICT (content): Merge conflict in include/scsi/libsas.h
> +CONFLICT (content): Merge conflict in include/linux/libata.h
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_scsi_host.c
> +CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_internal.h
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_init.c
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_expander.c
> +CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_event.c
> CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_discover.c
> +CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_ata.c
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/request.h
> CONFLICT (content): Merge conflict in drivers/scsi/isci/registers.h
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/port.h
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/port.c
> +CONFLICT (content): Merge conflict in drivers/scsi/isci/phy.c
> CONFLICT (content): Merge conflict in drivers/scsi/isci/init.c
>
> Since you are feeding patches into the scsi tree (instaed of having you
> tree merged into the scsi tree), you should rebase your tree in the scsi
> tree after your patches have been accepted. The above conflicts are
> (almost completely) caused by having the same patches in both trees with
> additional changes to those files in your tree.
I was wondering why it had not happened prior to this point... in any
event I'll get my tree rebased on top scsi-misc so that isci.git#all
will just be the pending delta.
^ permalink raw reply
* linux-next: manual merge of the l2-mtd tree with the vfs tree
From: Stephen Rothwell @ 2012-03-13 3:18 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-next, linux-kernel, Al Viro, Joe Perches
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
fs/jffs2/fs.c between commit de071e1a7466 ("switch open-coded instances
of d_make_root() to new helper") from the vfs tree and commit
ab9b393d6ee8 ("jffs2: Convert most D1/D2 macros to jffs2_dbg") from the
l2-mtd tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
[Al, I suspect that your patch should have changed the debug print as
well ...]
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc fs/jffs2/fs.c
index c0d5c9d,43052fa..0000000
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@@ -560,10 -572,10 +572,10 @@@ int jffs2_do_fill_super(struct super_bl
ret = -ENOMEM;
- D1(printk(KERN_DEBUG "jffs2_do_fill_super(): d_alloc_root()\n"));
+ jffs2_dbg(1, "%s(): d_alloc_root()\n", __func__);
- sb->s_root = d_alloc_root(root_i);
+ sb->s_root = d_make_root(root_i);
if (!sb->s_root)
- goto out_root_i;
+ goto out_root;
sb->s_maxbytes = 0xFFFFFFFF;
sb->s_blocksize = PAGE_CACHE_SIZE;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the isci tree with the scsi tree
From: Stephen Rothwell @ 2012-03-13 3:41 UTC (permalink / raw)
To: Williams, Dan J; +Cc: linux-next, linux-kernel, James Bottomley
In-Reply-To: <CABE8wwtNcA4QcJyLC6zipjygjAYa6o=bwPyz6xS9A=PLiU+2kg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
Hi Dan,
On Mon, 12 Mar 2012 19:50:33 -0700 "Williams, Dan J" <dan.j.williams@intel.com> wrote:
>
> I was wondering why it had not happened prior to this point... in any
It had, I just put up with it the first time :-)
> event I'll get my tree rebased on top scsi-misc so that isci.git#all
> will just be the pending delta.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the mmc tree with the s5p tree
From: Stephen Rothwell @ 2012-03-13 3:59 UTC (permalink / raw)
To: Chris Ball
Cc: linux-next, linux-kernel, Jaehoon Chung, Kyungmin Park,
Kukjin Kim, Mark Brown
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
Hi Chris,
Today's linux-next merge of the mmc tree got a conflict in
drivers/mmc/host/sdhci-s3c.c between commit c1c4b66dc010 ("mmc:
sdhci-s3c: add platform data for the second capability") from the s5p
tree and commit 1c352c37ee23 ("mmc: sdhci-s3c: Enable runtime power
management") from the mmc tree.
Just context changes (I think). I fixed it up (see below) and can carry
the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/mmc/host/sdhci-s3c.c
index a2bfbe0,312aaf4..0000000
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@@ -714,9 -706,11 +703,14 @@@ static int __devinit sdhci_s3c_probe(st
if (pdata->host_caps)
host->mmc->caps |= pdata->host_caps;
+ if (pdata->host_caps2)
+ host->mmc->caps2 |= pdata->host_caps2;
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_suspend_ignore_children(&pdev->dev, 1);
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, "sdhci_add_host() failed\n");
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the devicetree tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-13 5:01 UTC (permalink / raw)
To: Grant Likely
Cc: linux-next, linux-kernel, Gavin Shan, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
Hi Grant,
Today's linux-next merge of the devicetree tree got a conflict in
include/linux/of.h between commit eb740b5f3e65 ("powerpc/eeh: Introduce
EEH device") from the powerpc tree and commit 0f22dd395fc4 ("of: Only
compile OF_DYNAMIC on PowerPC pseries and iseries") from the devicetree
tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/of.h
index bdb1c07,533603e..0000000
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@@ -75,14 -72,10 +75,17 @@@ struct of_phandle_args
uint32_t args[MAX_PHANDLE_ARGS];
};
+#if defined(CONFIG_EEH)
+static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn)
+{
+ return dn->edev;
+}
+#endif
+
- #if defined(CONFIG_SPARC) || !defined(CONFIG_OF)
+ #ifdef CONFIG_OF_DYNAMIC
+ extern struct device_node *of_node_get(struct device_node *node);
+ extern void of_node_put(struct device_node *node);
+ #else /* CONFIG_OF_DYNAMIC */
/* Dummy ref counting routines - to be implemented later */
static inline struct device_node *of_node_get(struct device_node *node)
{
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the tip tree with the drm tree
From: Stephen Rothwell @ 2012-03-13 5:11 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Kirill A. Shutemov, Alan Cox,
Dave Airlie, Mika Westerberg
[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/platform/mrst/mrst.c between commit 026abc333205 ("gma500:
initial medfield merge") from the drm tree and commit ecfdb0ac15ba
("x86/mrst: Add msic_thermal platform support") from the tip tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/platform/mrst/mrst.c
index b930cc4,721e652..0000000
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@@ -688,19 -670,11 +672,24 @@@ static void *msic_ocd_platform_data(voi
return msic_generic_platform_data(info, INTEL_MSIC_BLOCK_OCD);
}
+/* tc35876x DSI-LVDS bridge chip and panel platform data */
+static void *tc35876x_platform_data(void *data)
+{
+ static struct tc35876x_platform_data pdata;
+
+ /* gpio pins set to -1 will not be used by the driver */
+ pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
+ pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
+ pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
+
+ return &pdata;
+}
+
+ static void *msic_thermal_platform_data(void *info)
+ {
+ return msic_generic_platform_data(info, INTEL_MSIC_BLOCK_THERMAL);
+ }
+
static const struct devs_id __initconst device_ids[] = {
{"bma023", SFI_DEV_TYPE_I2C, 1, &no_platform_data},
{"pmic_gpio", SFI_DEV_TYPE_SPI, 1, &pmic_gpio_platform_data},
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the uprobes tree with the tip tree
From: Stephen Rothwell @ 2012-03-13 5:41 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linux-next, linux-kernel, Stephane Eranian, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Hi Srikar,
Today's linux-next merge of the uprobes tree got a conflict in
arch/x86/kernel/cpu/perf_event_intel_ds.c between commit 3e702ff6d1ea
("perf/x86: Add LBR software filter support for Intel CPUs") from the tip
tree and commit 1e1e2cddc33d ("x86/trivial: use is_ia32_compat_task")
from the uprobes tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/kernel/cpu/perf_event_intel_ds.c
index 7f64df1,92e7dee4..0000000
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@@ -3,7 -3,7 +3,8 @@@
#include <linux/slab.h>
#include <asm/perf_event.h>
+#include <asm/insn.h>
+ #include <asm/compat.h>
#include "perf_event.h"
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the uprobes tree with the tip tree
From: Stephen Rothwell @ 2012-03-13 5:52 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linux-next, linux-kernel, Kees Cook, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]
Hi Srikar,
Today's linux-next merge of the uprobes tree got a conflict in
arch/x86/kernel/traps.c between commit c94082656dac ("x86: Use enum
instead of literals for trap values") from the tip tree and commit
b6d8245ec899 ("x86/trivial: rename trap_no to trap_nr in thread struct")
from the uprobes tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/kernel/traps.c
index 4310189,993f52f..0000000
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@@ -238,10 -233,10 +238,10 @@@ dotraplinkage void do_double_fault(stru
struct task_struct *tsk = current;
/* Return not checked because double check cannot be ignored */
- notify_die(DIE_TRAP, str, regs, error_code, 8, SIGSEGV);
+ notify_die(DIE_TRAP, str, regs, error_code, X86_TRAP_DF, SIGSEGV);
tsk->thread.error_code = error_code;
- tsk->thread.trap_no = X86_TRAP_DF;
- tsk->thread.trap_nr = 8;
++ tsk->thread.trap_nr = X86_TRAP_DF;
/*
* This is always a kernel trap and never fixable (and thus must
@@@ -269,7 -264,7 +269,7 @@@ do_general_protection(struct pt_regs *r
goto gp_in_kernel;
tsk->thread.error_code = error_code;
- tsk->thread.trap_no = X86_TRAP_GP;
- tsk->thread.trap_nr = 13;
++ tsk->thread.trap_nr = X86_TRAP_GP;
if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&
printk_ratelimit()) {
@@@ -296,9 -291,9 +296,9 @@@ gp_in_kernel
return;
tsk->thread.error_code = error_code;
- tsk->thread.trap_no = X86_TRAP_GP;
- tsk->thread.trap_nr = 13;
- if (notify_die(DIE_GPF, "general protection fault", regs,
- error_code, 13, SIGSEGV) == NOTIFY_STOP)
++ tsk->thread.trap_nr = X86_TRAP_GP;
+ if (notify_die(DIE_GPF, "general protection fault", regs, error_code,
+ X86_TRAP_GP, SIGSEGV) == NOTIFY_STOP)
return;
die("general protection fault", regs, error_code);
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the uprobes tree with the tip tree
From: Stephen Rothwell @ 2012-03-13 5:52 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
Hi Srikar,
Today's linux-next merge of the uprobes tree got a conflict in
arch/x86/include/asm/compat.h between commits fca460f95e92 ("x32: Handle
the x32 system call flag") and a628b684d27d ("x32: Provide separate
is_ia32_task() and is_x32_task() predicates") from the tip tree and
commit 1e1e2cddc33d ("x86/trivial: use is_ia32_compat_task") from the
uprobes tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/include/asm/compat.h
index 355edc0,a6ba59d..0000000
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@@ -223,39 -214,15 +229,41 @@@ static inline compat_uptr_t ptr_to_comp
static inline void __user *arch_compat_alloc_user_space(long len)
{
- struct pt_regs *regs = task_pt_regs(current);
- return (void __user *)regs->sp - len;
+ compat_uptr_t sp;
+
+ if (test_thread_flag(TIF_IA32)) {
+ sp = task_pt_regs(current)->sp;
+ } else {
+ /* -128 for the x32 ABI redzone */
+ sp = percpu_read(old_rsp) - 128;
+ }
+
+ return (void __user *)round_down(sp - len, 16);
+}
+
+static inline bool is_ia32_task(void)
+{
+#ifdef CONFIG_IA32_EMULATION
+ if (current_thread_info()->status & TS_COMPAT)
+ return true;
+#endif
+ return false;
+}
+
+static inline bool is_x32_task(void)
+{
+#ifdef CONFIG_X86_X32_ABI
+ if (task_pt_regs(current)->orig_ax & __X32_SYSCALL_BIT)
+ return true;
+#endif
+ return false;
}
+ #undef is_compat_task
+
-static inline int is_compat_task(void)
+static inline bool is_compat_task(void)
{
- return current_thread_info()->status & TS_COMPAT;
+ return is_ia32_task() || is_x32_task();
}
#endif /* _ASM_X86_COMPAT_H */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the uprobes tree with the tip tree
From: Stephen Rothwell @ 2012-03-13 5:52 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]
Hi Srikar,
Today's linux-next merge of the uprobes tree got a conflict in
arch/x86/kernel/signal.c between commit c5a373942bbc ("x32:
Signal-related system calls") from the tip tree and commit 1e1e2cddc33d
("x86/trivial: use is_ia32_compat_task") from the uprobes tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/kernel/signal.c
index 5134e17,907d483..0000000
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@@ -37,7 -37,15 +38,8 @@@
#include <asm/syscalls.h>
#include <asm/sigframe.h>
+ #include <asm/compat.h>
-#define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
-
-#define __FIX_EFLAGS (X86_EFLAGS_AC | X86_EFLAGS_OF | \
- X86_EFLAGS_DF | X86_EFLAGS_TF | X86_EFLAGS_SF | \
- X86_EFLAGS_ZF | X86_EFLAGS_AF | X86_EFLAGS_PF | \
- X86_EFLAGS_CF)
-
#ifdef CONFIG_X86_32
# define FIX_EFLAGS (__FIX_EFLAGS | X86_EFLAGS_RF)
#else
@@@ -628,22 -637,6 +629,16 @@@ static int signr_convert(int sig
#else /* !CONFIG_X86_32 */
- #ifdef CONFIG_IA32_EMULATION
- #define is_ia32 test_thread_flag(TIF_IA32)
- #else /* !CONFIG_IA32_EMULATION */
- #define is_ia32 0
- #endif /* CONFIG_IA32_EMULATION */
-
+#ifdef CONFIG_X86_X32_ABI
+#define is_x32 test_thread_flag(TIF_X32)
+
+static int x32_setup_rt_frame(int sig, struct k_sigaction *ka,
+ siginfo_t *info, compat_sigset_t *set,
+ struct pt_regs *regs);
+#else /* !CONFIG_X86_X32_ABI */
+#define is_x32 0
+#endif /* CONFIG_X86_X32_ABI */
+
int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
sigset_t *set, struct pt_regs *regs);
int ia32_setup_frame(int sig, struct k_sigaction *ka,
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the uprobes tree
From: Stephen Rothwell @ 2012-03-13 6:09 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
Hi Srikar,
After merging the uprobes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/trace/events/syscalls.h:11:0,
from kernel/trace/trace_syscalls.c:2:
arch/x86/include/asm/syscall.h: In function 'syscall_get_arguments':
arch/x86/include/asm/syscall.h:98:2: error: implicit declaration of function 'is_ia32_compat_task' [-Werror=implicit-function-declaration]
Caused by commit 1e1e2cddc33d ("x86/trivial: use is_ia32_compat_task").
I have used the uprobes tree from next-20120309 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Ingo Molnar @ 2012-03-13 6:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Russell King, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313110840.7b444deb6b1bb902c15f3cdf@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Russell,
>
> Today's linux-next merge of the arm tree got a conflict in
> kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> from the arm tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
This commit seems simple enough and has PeterZ's ack, but if
there are more scheduler patches coming in this area then please
send it to the scheduler tree first: we can create a pullable,
stable topic branch for it which the ARM tree can then use.
That approach would also avoid conflicts as a side effect.
Thanks,
Ingo
^ permalink raw reply
* linux-next: manual merge of the oprofile tree with the tip tree
From: Stephen Rothwell @ 2012-03-13 6:37 UTC (permalink / raw)
To: Robert Richter
Cc: linux-next, linux-kernel, Stephane Eranian, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]
Hi Robert,
Today's linux-next merge of the oprofile tree got a conflict in
tools/perf/util/header.c tools/perf/util/header.h between commit
330aa675b4f9 ("perf record: Add HEADER_BRANCH_STACK tag") from the tip
tree and commit c415f577eb32 ("perf tools: Add pmu mappings to header
information") from the oprofile tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc tools/perf/util/header.c
index 0d9b6da,626eb90..0000000
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@@ -1321,12 -1372,37 +1388,43 @@@ static void print_cpuid(struct perf_hea
free(str);
}
+static void print_branch_stack(struct perf_header *ph __used, int fd __used,
+ FILE *fp)
+{
+ fprintf(fp, "# contains samples with branch stack\n");
+}
+
+ static void print_pmu_mappings(struct perf_header *ph, int fd, FILE *fp)
+ {
+ const char *delimiter = "# pmu mappings: ";
+ char *name;
+ int ret;
+ u32 pmu_num;
+ u32 type;
+
+ ret = read(fd, &pmu_num, sizeof(pmu_num));
+ if (ret != sizeof(pmu_num))
+ goto error;
+
+ if (!pmu_num)
+ goto error;
+
+ while (pmu_num--) {
+ if (read(fd, &type, sizeof(type)) != sizeof(type))
+ goto error;
+ name = do_read_string(fd, ph);
+ fprintf(fp, "%s%s = %" PRIu32, delimiter, name, type);
+ free(name);
+ delimiter = ", ";
+ }
+
+ fprintf(fp, "\n");
+
+ return;
+ error:
+ fprintf(fp, "# pmu mappings: not available\n");
+ }
+
static int __event_process_build_id(struct build_id_event *bev,
char *filename,
struct perf_session *session)
@@@ -1531,7 -1607,7 +1629,8 @@@ static const struct feature_ops feat_op
FEAT_OPA(HEADER_CMDLINE, cmdline),
FEAT_OPF(HEADER_CPU_TOPOLOGY, cpu_topology),
FEAT_OPF(HEADER_NUMA_TOPOLOGY, numa_topology),
+ FEAT_OPA(HEADER_BRANCH_STACK, branch_stack),
+ FEAT_OPA(HEADER_PMU_MAPPINGS, pmu_mappings),
};
struct header_print_data {
diff --cc tools/perf/util/header.h
index 21a6be0,9b4d407..0000000
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@@ -27,7 -27,8 +27,8 @@@ enum
HEADER_EVENT_DESC,
HEADER_CPU_TOPOLOGY,
HEADER_NUMA_TOPOLOGY,
+ HEADER_BRANCH_STACK,
+ HEADER_PMU_MAPPINGS,
-
HEADER_LAST_FEATURE,
HEADER_FEAT_BITS = 256,
};
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the drivers-x86 tree with the tip tree
From: Stephen Rothwell @ 2012-03-13 6:51 UTC (permalink / raw)
To: Matthew Garrett
Cc: linux-next, linux-kernel, Philip A. Prindeville, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]
Hi Matthew,
Today's linux-next merge of the drivers-x86 tree got a conflicts in
arch/x86/Kconfig and arch/x86/platform/geode/Makefile between commit
da4e3302949f ("x86/geode/net5501: Add platform driver for Soekris
Engineering net5501") from the tip tree and commit b2a2f19ad3db ("geos:
Platform driver for Geos and Geos2 single-board computers") from the
drivers-x86 tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/Kconfig
index 36d459e,3a38c4c..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2146,12 -2133,13 +2146,19 @@@ config ALI
Note: You have to set alix.force=1 for boards with Award BIOS.
+config NET5501
+ bool "Soekris Engineering net5501 System Support (LEDS, GPIO, etc)"
+ select GPIOLIB
+ ---help---
+ This option enables system support for the Soekris Engineering net5501.
+
+ config GEOS
+ bool "Traverse Technologies GEOS System Support (LEDS, GPIO, etc)"
+ select GPIOLIB
+ depends on DMI
+ ---help---
+ This option enables system support for the Traverse Technologies GEOS.
+
endif # X86_32
config AMD_NB
diff --cc arch/x86/platform/geode/Makefile
index 246b788,d8ba564..0000000
--- a/arch/x86/platform/geode/Makefile
+++ b/arch/x86/platform/geode/Makefile
@@@ -1,2 -1,2 +1,3 @@@
obj-$(CONFIG_ALIX) += alix.o
+obj-$(CONFIG_NET5501) += net5501.o
+ obj-$(CONFIG_GEOS) += geos.o
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the omap_dss2 tree
From: Stephen Rothwell @ 2012-03-13 8:21 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Tomi Valkeinen, Janusz Krzysztofik
[-- Attachment #1: Type: text/plain, Size: 5862 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap1/board-ams-delta.c between commit ddba6c7f7ec6
("OMAP1: pass LCD config with omapfb_set_lcd_config()") from the
omap_dss2 tree and commits 2e3ee9f45b3c ("ARM: OMAP1: Move most of
plat/io.h into local iomap.h") and several others from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-omap1/board-ams-delta.c
index e0e8245,7dd3099..0000000
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -18,9 -19,12 +19,13 @@@
#include <linux/interrupt.h>
#include <linux/leds.h>
#include <linux/platform_device.h>
+ #include <linux/regulator/consumer.h>
+ #include <linux/regulator/fixed.h>
+ #include <linux/regulator/machine.h>
#include <linux/serial_8250.h>
#include <linux/export.h>
+#include <linux/omapfb.h>
+ #include <linux/io.h>
#include <media/soc_camera.h>
@@@ -170,6 -165,151 +166,147 @@@ static struct omap_usb_config ams_delta
.pins[0] = 2,
};
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
- { OMAP_TAG_LCD, &ams_delta_lcd_config },
-};
-
+ #define LATCH1_GPIO_BASE 232
+ #define LATCH1_NGPIO 8
+
+ static struct resource latch1_resources[] = {
+ [0] = {
+ .name = "dat",
+ .start = LATCH1_PHYS,
+ .end = LATCH1_PHYS + (LATCH1_NGPIO - 1) / 8,
+ .flags = IORESOURCE_MEM,
+ },
+ };
+
+ static struct bgpio_pdata latch1_pdata = {
+ .base = LATCH1_GPIO_BASE,
+ .ngpio = LATCH1_NGPIO,
+ };
+
+ static struct platform_device latch1_gpio_device = {
+ .name = "basic-mmio-gpio",
+ .id = 0,
+ .resource = latch1_resources,
+ .num_resources = ARRAY_SIZE(latch1_resources),
+ .dev = {
+ .platform_data = &latch1_pdata,
+ },
+ };
+
+ static struct resource latch2_resources[] = {
+ [0] = {
+ .name = "dat",
+ .start = LATCH2_PHYS,
+ .end = LATCH2_PHYS + (AMS_DELTA_LATCH2_NGPIO - 1) / 8,
+ .flags = IORESOURCE_MEM,
+ },
+ };
+
+ static struct bgpio_pdata latch2_pdata = {
+ .base = AMS_DELTA_LATCH2_GPIO_BASE,
+ .ngpio = AMS_DELTA_LATCH2_NGPIO,
+ };
+
+ static struct platform_device latch2_gpio_device = {
+ .name = "basic-mmio-gpio",
+ .id = 1,
+ .resource = latch2_resources,
+ .num_resources = ARRAY_SIZE(latch2_resources),
+ .dev = {
+ .platform_data = &latch2_pdata,
+ },
+ };
+
+ static const struct gpio latch_gpios[] __initconst = {
+ {
+ .gpio = LATCH1_GPIO_BASE + 6,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = "dockit1",
+ },
+ {
+ .gpio = LATCH1_GPIO_BASE + 7,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = "dockit2",
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = "scard_rstin",
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_SCARD_CMDVCC,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = "scard_cmdvcc",
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = "modem_codec",
+ },
+ {
+ .gpio = AMS_DELTA_LATCH2_GPIO_BASE + 14,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = "hookflash1",
+ },
+ {
+ .gpio = AMS_DELTA_LATCH2_GPIO_BASE + 15,
+ .flags = GPIOF_OUT_INIT_LOW,
+ .label = "hookflash2",
+ },
+ };
+
+ static struct regulator_consumer_supply modem_nreset_consumers[] = {
+ REGULATOR_SUPPLY("RESET#", "serial8250.1"),
+ REGULATOR_SUPPLY("POR", "cx20442-codec"),
+ };
+
+ static struct regulator_init_data modem_nreset_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(modem_nreset_consumers),
+ .consumer_supplies = modem_nreset_consumers,
+ };
+
+ static struct fixed_voltage_config modem_nreset_config = {
+ .supply_name = "modem_nreset",
+ .microvolts = 3300000,
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .startup_delay = 25000,
+ .enable_high = 1,
+ .enabled_at_boot = 1,
+ .init_data = &modem_nreset_data,
+ };
+
+ static struct platform_device modem_nreset_device = {
+ .name = "reg-fixed-voltage",
+ .id = -1,
+ .dev = {
+ .platform_data = &modem_nreset_config,
+ },
+ };
+
+ struct modem_private_data {
+ struct regulator *regulator;
+ };
+
+ static struct modem_private_data modem_priv;
+
+ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
+ {
+ int bit = 0;
+ u16 bitpos = 1 << bit;
+
+ for (; bit < ngpio; bit++, bitpos = bitpos << 1) {
+ if (!(mask & bitpos))
+ continue;
+ else
+ gpio_set_value(base + bit, (value & bitpos) != 0);
+ }
+ }
+ EXPORT_SYMBOL(ams_delta_latch_write);
+
static struct resource ams_delta_nand_resources[] = {
[0] = {
.start = OMAP1_MPUIO_BASE,
@@@ -316,14 -496,28 +491,30 @@@ static void __init ams_delta_init(void
ams_delta_init_fiq();
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
+
+ omapfb_set_lcd_config(&ams_delta_lcd_config);
}
+ static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+ {
+ struct modem_private_data *priv = port->private_data;
+
+ if (IS_ERR(priv->regulator))
+ return;
+
+ if (state == old)
+ return;
+
+ if (state == 0)
+ regulator_enable(priv->regulator);
+ else if (old == 0)
+ regulator_disable(priv->regulator);
+ }
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
- .membase = IOMEM(AMS_DELTA_MODEM_VIRT),
- .mapbase = AMS_DELTA_MODEM_PHYS,
+ .membase = IOMEM(MODEM_VIRT),
+ .mapbase = MODEM_PHYS,
.irq = -EINVAL, /* changed later */
.flags = UPF_BOOT_AUTOCONF,
.irqflags = IRQF_TRIGGER_RISING,
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the sound tree
From: Stephen Rothwell @ 2012-03-13 8:28 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Peter Ujfalusi, Tony Lindgren,
Santosh Shilimkar, Takashi Iwai, Mark Brown, Liam Girdwood,
Mircea Gherzan
[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/board-omap4panda.c between commit 3c90c98a1ebb
("OMAP4: omap4panda: Enable audio support") from the sound tree and
commit 65f19159ddc4 ("ARM: OMAP: enable Bluetooth on the PandaBoard")
from the arm-soc tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-omap4panda.c
index e441591,3f3055d..0000000
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@@ -92,34 -91,15 +92,40 @@@ static struct platform_device leds_gpi
},
};
+static struct omap_abe_twl6040_data panda_abe_audio_data = {
+ /* Audio out */
+ .has_hs = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
+ /* HandsFree through expasion connector */
+ .has_hf = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
+ /* PandaBoard: FM TX, PandaBoardES: can be connected to audio out */
+ .has_aux = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
+ /* PandaBoard: FM RX, PandaBoardES: audio in */
+ .has_afm = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
+ /* No jack detection. */
+ .jack_detection = 0,
+ /* MCLK input is 38.4MHz */
+ .mclk_freq = 38400000,
+
+};
+
+static struct platform_device panda_abe_audio = {
+ .name = "omap-abe-twl6040",
+ .id = -1,
+ .dev = {
+ .platform_data = &panda_abe_audio_data,
+ },
+};
+
+ static struct platform_device btwilink_device = {
+ .name = "btwilink",
+ .id = -1,
+ };
+
static struct platform_device *panda_devices[] __initdata = {
&leds_gpio,
&wl1271_device,
+ &panda_abe_audio,
+ &btwilink_device,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the oprofile tree with the tip tree
From: Ingo Molnar @ 2012-03-13 8:31 UTC (permalink / raw)
To: Robert Richter
Cc: linux-next, linux-kernel, Stephane Eranian, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Stephen Rothwell
In-Reply-To: <20120313173712.52ecb636a1e3d4330fe8baff@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Robert,
>
> Today's linux-next merge of the oprofile tree got a conflict
> in tools/perf/util/header.c tools/perf/util/header.h between
> commit 330aa675b4f9 ("perf record: Add HEADER_BRANCH_STACK
> tag") from the tip tree and commit c415f577eb32 ("perf tools:
> Add pmu mappings to header information") from the oprofile
> tree.
Robert,
Hm, that commit should obviously be processed via the regular
perf channels, not via the oprofile tree ... Please resolve
this.
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Russell King @ 2012-03-13 8:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313061622.GA24357@elte.hu>
On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Russell,
> >
> > Today's linux-next merge of the arm tree got a conflict in
> > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > from the arm tree.
> >
> > Just context changes. I fixed it up (see below) and can carry the fix as
> > necessary.
>
> This commit seems simple enough and has PeterZ's ack, but if
> there are more scheduler patches coming in this area then please
> send it to the scheduler tree first: we can create a pullable,
> stable topic branch for it which the ARM tree can then use.
>
> That approach would also avoid conflicts as a side effect.
Please check your mailbox:
Date: Tue, 29 Nov 2011 12:22:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>,
Russell King <linux@arm.linux.org.uk>
Subject: [RFC PATCH 1/6] sched: Introduce the finish_arch_post_lock_switch()
scheduler hook
Date: Mon, 19 Dec 2011 14:57:48 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Frank Rowand <frank.rowand@am.sony.com>
Subject: [RFC PATCH v2 1/6] sched: Introduce the finish_arch_post_lock_switch()
scheduler hook
Date: Fri, 20 Jan 2012 17:42:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
Frank Rowand <frank.rowand@am.sony.com>
Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
scheduler hook
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Ingo Molnar @ 2012-03-13 8:36 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313083310.GA27560@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi Russell,
> > >
> > > Today's linux-next merge of the arm tree got a conflict in
> > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > from the arm tree.
> > >
> > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > necessary.
> >
> > This commit seems simple enough and has PeterZ's ack, but if
> > there are more scheduler patches coming in this area then
> > please send it to the scheduler tree first: we can create a
> > pullable, stable topic branch for it which the ARM tree can
> > then use.
> >
> > That approach would also avoid conflicts as a side effect.
>
> Please check your mailbox:
I'm aware of that old thread, I'd just prefer to hear about your
plans patching the scheduler *before* you commit it to
linux-next ;-)
Please make sure none of these scheduler patches go to the ARM
tree without a proper Git space solution that involves the
scheduler folks.
Thanks,
Ingo
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2012-03-13 8:36 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: Marc Zyngier, Linus Walleij, linux-next, linux-kernel,
Russell King
[-- Attachment #1.1: Type: text/plain, Size: 2307 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-ux500/timer.c between commit 8eed6eac103b ("ARM: ux500:
convert to twd_local_timer_register() interface") from the arm tree and
commit b9576623c421 ("ARM: plat-nomadik: get rid of global mtu base
pointer") from the arm-soc tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-ux500/timer.c
index cadf982,fd00024..0000000
--- a/arch/arm/mach-ux500/timer.c
+++ b/arch/arm/mach-ux500/timer.c
@@@ -15,38 -15,22 +15,39 @@@
#include <mach/setup.h>
#include <mach/hardware.h>
+#ifdef CONFIG_HAVE_ARM_TWD
+static DEFINE_TWD_LOCAL_TIMER(u5500_twd_local_timer,
+ U5500_TWD_BASE, IRQ_LOCALTIMER);
+static DEFINE_TWD_LOCAL_TIMER(u8500_twd_local_timer,
+ U8500_TWD_BASE, IRQ_LOCALTIMER);
+
+static void __init ux500_twd_init(void)
+{
+ struct twd_local_timer *twd_local_timer;
+ int err;
+
+ twd_local_timer = cpu_is_u5500() ? &u5500_twd_local_timer :
+ &u8500_twd_local_timer;
+
+ err = twd_local_timer_register(twd_local_timer);
+ if (err)
+ pr_err("twd_local_timer_register failed %d\n", err);
+}
+#else
+#define ux500_twd_init() do { } while(0)
+#endif
+
static void __init ux500_timer_init(void)
{
+ void __iomem *mtu_timer_base;
void __iomem *prcmu_timer_base;
+ int err;
if (cpu_is_u5500()) {
- mtu_base = __io_address(U5500_MTU0_BASE);
-#ifdef CONFIG_LOCAL_TIMERS
- twd_base = __io_address(U5500_TWD_BASE);
-#endif
+ mtu_timer_base = __io_address(U5500_MTU0_BASE);
prcmu_timer_base = __io_address(U5500_PRCMU_TIMER_3_BASE);
} else if (cpu_is_u8500()) {
- mtu_base = __io_address(U8500_MTU0_BASE);
-#ifdef CONFIG_LOCAL_TIMERS
- twd_base = __io_address(U8500_TWD_BASE);
-#endif
+ mtu_timer_base = __io_address(U8500_MTU0_BASE);
prcmu_timer_base = __io_address(U8500_PRCMU_TIMER_4_BASE);
} else {
ux500_unknown_soc();
@@@ -69,9 -53,8 +70,9 @@@
*
*/
- nmdk_timer_init();
+ nmdk_timer_init(mtu_timer_base);
clksrc_dbx500_prcmu_init(prcmu_timer_base);
+ ux500_twd_init();
}
static void ux500_timer_reset(void)
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2012-03-13 8:42 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Pawel Moll, Marc Zyngier, Russell King
[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-vexpress/ct-ca9x4.c between commit e9f07fbc5f5b ("ARM:
plat-versatile: convert to twd_local_timer_register() interface") from
the arm tree and commit 98ed4ceb93ba ("ARM: vexpress: Get rid of
MMIO_P2V") from the arm-soc tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-vexpress/ct-ca9x4.c
index b391538,73791f0..0000000
--- a/arch/arm/mach-vexpress/ct-ca9x4.c
+++ b/arch/arm/mach-vexpress/ct-ca9x4.c
@@@ -54,44 -42,17 +42,28 @@@ static struct map_desc ct_ca9x4_io_desc
static void __init ct_ca9x4_map_io(void)
{
iotable_init(ct_ca9x4_io_desc, ARRAY_SIZE(ct_ca9x4_io_desc));
-#ifdef CONFIG_LOCAL_TIMERS
- twd_base = ioremap(A9_MPCORE_TWD, SZ_32);
-#endif
}
+#ifdef CONFIG_HAVE_ARM_TWD
+static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, A9_MPCORE_TWD, IRQ_LOCALTIMER);
+
+static void __init ca9x4_twd_init(void)
+{
+ int err = twd_local_timer_register(&twd_local_timer);
+ if (err)
+ pr_err("twd_local_timer_register failed %d\n", err);
+}
+#else
+#define ca9x4_twd_init() do {} while(0)
+#endif
+
static void __init ct_ca9x4_init_irq(void)
{
- gic_init(0, 29, MMIO_P2V(A9_MPCORE_GIC_DIST),
- MMIO_P2V(A9_MPCORE_GIC_CPU));
+ gic_init(0, 29, ioremap(A9_MPCORE_GIC_DIST, SZ_4K),
+ ioremap(A9_MPCORE_GIC_CPU, SZ_256));
+ ca9x4_twd_init();
}
- #if 0
- static void __init ct_ca9x4_timer_init(void)
- {
- writel(0, MMIO_P2V(CT_CA9X4_TIMER0) + TIMER_CTRL);
- writel(0, MMIO_P2V(CT_CA9X4_TIMER1) + TIMER_CTRL);
-
- sp804_clocksource_init(MMIO_P2V(CT_CA9X4_TIMER1), "ct-timer1");
- sp804_clockevents_init(MMIO_P2V(CT_CA9X4_TIMER0), IRQ_CT_CA9X4_TIMER0,
- "ct-timer0");
- }
-
- static struct sys_timer ct_ca9x4_timer = {
- .init = ct_ca9x4_timer_init,
- };
- #endif
-
static void ct_ca9x4_clcd_enable(struct clcd_fb *fb)
{
v2m_cfg_write(SYS_CFG_MUXFPGA | SYS_CFG_SITE_DB1, 0);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2012-03-13 8:47 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, linux-arm-kernel
Cc: linux-next, linux-kernel, Russell King, Marc Zyngier
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/plat-versatile/localtimer.c between commit e9f07fbc5f5b ("ARM:
plat-versatile: convert to twd_local_timer_register() interface") from
the arm tree and commit e129440af638 ("ARM: versatile: Map local timers
using Device Tree when possible") from the arm-soc tree.
I did the obvious thing and removed the file (as the former does), but
there is probably more to be fixed up.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Russell King @ 2012-03-13 8:47 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313083630.GA10131@elte.hu>
On Tue, Mar 13, 2012 at 09:36:30AM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> > >
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > > Hi Russell,
> > > >
> > > > Today's linux-next merge of the arm tree got a conflict in
> > > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > > from the arm tree.
> > > >
> > > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > > necessary.
> > >
> > > This commit seems simple enough and has PeterZ's ack, but if
> > > there are more scheduler patches coming in this area then
> > > please send it to the scheduler tree first: we can create a
> > > pullable, stable topic branch for it which the ARM tree can
> > > then use.
> > >
> > > That approach would also avoid conflicts as a side effect.
> >
> > Please check your mailbox:
>
> I'm aware of that old thread, I'd just prefer to hear about your
> plans patching the scheduler *before* you commit it to
> linux-next ;-)
>
> Please make sure none of these scheduler patches go to the ARM
> tree without a proper Git space solution that involves the
> scheduler folks.
Sorry, you're blaming the wrong person. I got the commit via a pull,
not via a patch.
If that's how you want to run your bit of the kernel, then please be more
responsive when you're sent patches and say how you want to handle things.
Don't ignore patches and then blame people when conflicts happen.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Ingo Molnar @ 2012-03-13 8:48 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313083310.GA27560@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> Please check your mailbox:
>
> Date: Fri, 20 Jan 2012 17:42:27 +0000
> From: Catalin Marinas <catalin.marinas@arm.com>
> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> Peter Zijlstra <peterz@infradead.org>,
> Will Deacon <will.deacon@arm.com>,
> Frank Rowand <frank.rowand@am.sony.com>
> Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> scheduler hook
Btw., are you losing emails? Because the reply from peterz to
those patches, a month ago, was pretty clear:
> > Russell, what's the status of these patches? I'd like to see
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some
> > other patches on top.
You never replied to PeterZ's request, you just ignored this
scheduler maintainer request and you just did it in some random
way that was most convenient to you many weeks after the thread
died down, ignoring everyone else's concerns - a pretty usual
pattern from you I have to say.
Had you followed PeterZ's request this conflict in linux-next
could have been avoided, amongst other things.
Given that the merge window is close I doubt there will be
other, more difficult to resolve conflicts, but this incident
again demonstrates your inability to communicate efficiently and
amicably, forcing me to highlight it in this trivial case
because it's a sadly reoccuring pattern.
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Ingo Molnar @ 2012-03-13 8:56 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313084713.GB27560@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> Sorry, you're blaming the wrong person. I got the commit via
> a pull, not via a patch.
This is the most idiotic excuse I've ever read.
Dammit, don't pull code you don't maintain and which you have
not checked the background of, *especially* not if the
originating discussion very clearly asked *you* to do it in
another way.
We were modifying that very code in this development cycle, in
the scheduler tree - a fact highlighted by the conflict - which
you could have seen yourself, had you even attempted to
test-merge your tree to linux-next ...
Let me quote PeterZ again:
> > Russell, what's the status of these patches? I'd like to see
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some
> > other patches on top.
Russell, read and reply to your mail in a timely and reliable
fashion, that will avoid such mixups in the future.
> If that's how you want to run your bit of the kernel, then
> please be more responsive when you're sent patches and say how
> you want to handle things. Don't ignore patches and then blame
> people when conflicts happen.
Stop blaming others for your own mistakes, one of the the
scheduler maintainers replied to the patches a month ago, in an
absolutely constructive fashion:
http://lkml.org/lkml/2012/2/16/232
You never replied to PeterZ that I can see.
Again, fortunately it's not a big deal right now - both the
commit and the conflict is trivial - but your current attitute
towards applying patches and following discussions is rather sad
and could cause bigger problems in the future.
Thanks,
Ingo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox