Re: questions around Book III-E and branch trace
On Wed, 2013-04-17 at 12:44 -0600, Chris Friesen wrote: Hi, I'm trying to wrap my head around how linux handles branch tracing on Book III-E. I think I understand how we set MSR[DE] and DBCR0[IDM|BT], and how we handle fixing things up if an instruction being traced causes an exception. That code is a mess and it wouldn't surprise me if it was broken... At this point, the people who care the most about it are FSL, so that's where you have the most chance to find a satisfactory answer. Cheers, Ben. I have a few questions though: 1) Does user_enable_block_step() have a bug in it? The current code has task-thread.dbcr0 = DBCR0_IDM | DBCR0_BT; Should that be as follows (to match the singel-step case)? task-thread.dbcr0 |= DBCR0_IDM | DBCR0_BT; 2) Why doesn't DBCR0_ACTIVE_EVENTS include DBCR0_BT? 3) In sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return -EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set? Would it not be possible to use DBCR0_BT? Thanks, Chris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Use tlbiel for 4KB pages
On Thu, 2013-04-18 at 13:33 +0800, Gavin Shan wrote:
The firmware should have supplied correct information for the kernel
to figure out the page size array, which is traced by mmu_psize_defs[].
Otherwise, the kernel will fail back to use solely 4KB page size
and copy mmu_psize_defaults_old[] over to mmu_psize_defs[]. However,
the tlbiel isn't enabled in mmu_psize_defaults_old[].
Did you actually find a problem here ? There is a reason we don't enable
tlbiel in there ... those old CPUs do not support it.
Ben.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/mm/hash_utils_64.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 2d4a20c..8675ae5 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -130,7 +130,7 @@ static struct mmu_psize_def mmu_psize_defaults_old[] = {
.sllp = 0,
.penc = 0,
.avpnm = 0,
- .tlbiel = 0,
+ .tlbiel = 1,
},
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the ppc-temp tree with the metag tree
Hi Michael, Today's linux-next merge of the ppc-temp tree got a conflict in arch/metag/mm/Kconfig between commit 2b8660ed3bfe (memblock: Kill ARCH_POPULATES_NODE_MAP once more) from the metag tree and commit 45b02f8d94e3 (memblock: kill config MAX_ACTIVE_REGIONS) from the ppc-temp tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/metag/mm/Kconfig index 794f26a,ccf2576..000 --- a/arch/metag/mm/Kconfig +++ b/arch/metag/mm/Kconfig @@@ -93,11 -93,9 +93,6 @@@ config ARCH_SPARSEMEM_ENABL config ARCH_SPARSEMEM_DEFAULT def_bool y - config MAX_ACTIVE_REGIONS - int - default 2 if SPARSEMEM - default 1 - -config ARCH_POPULATES_NODE_MAP - def_bool y - config ARCH_SELECT_MEMORY_MODEL def_bool y pgpBUkaHYvKye.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3 4/5] powerpc, perf: Define BHRB generic functions, data and flags for POWER8
This patch populates BHRB specific data for power_pmu structure. It
also implements POWER8 specific BHRB filter and configuration functions.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/power8-pmu.c | 57 +-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 106ae0b..153408c 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -109,6 +109,16 @@
#define EVENT_IS_MARKED(EVENT_MARKED_MASK
EVENT_MARKED_SHIFT)
#define EVENT_PSEL_MASK0xff/* PMCxSEL value */
+/* MMCRA IFM bits - POWER8 */
+#definePOWER8_MMCRA_IFM1 0x4000UL
+#definePOWER8_MMCRA_IFM2 0x8000UL
+#definePOWER8_MMCRA_IFM3 0xC000UL
+
+#define ONLY_PLM \
+ (PERF_SAMPLE_BRANCH_USER|\
+PERF_SAMPLE_BRANCH_KERNEL |\
+PERF_SAMPLE_BRANCH_HV)
+
/*
* Layout of constraint bits:
*
@@ -428,6 +438,48 @@ static int power8_generic_events[] = {
[PERF_COUNT_HW_BRANCH_MISSES] = PM_BR_MPRED_CMPL,
};
+static u64 power8_bhrb_filter_map(u64 branch_sample_type)
+{
+ u64 pmu_bhrb_filter = 0;
+ u64 br_privilege = branch_sample_type ONLY_PLM;
+
+ /* BHRB and regular PMU events share the same prvillege state
+* filter configuration. BHRB is always recorded along with a
+* regular PMU event. So privilege state filter criteria for BHRB
+* and the companion PMU events has to be the same. As a default
+* perf record tool sets all privillege bits ON when no filter
+* criteria is provided in the command line. So as along as all
+* privillege bits are ON or they are OFF, we are good to go.
+*/
+ if ((br_privilege != 7) (br_privilege != 0))
+ return -1;
+
+ /* No branch filter requested */
+ if (branch_sample_type PERF_SAMPLE_BRANCH_ANY)
+ return pmu_bhrb_filter;
+
+ /* Invalid branch filter options - HW does not support */
+ if (branch_sample_type PERF_SAMPLE_BRANCH_ANY_RETURN)
+ return -1;
+
+ if (branch_sample_type PERF_SAMPLE_BRANCH_IND_CALL)
+ return -1;
+
+ if (branch_sample_type PERF_SAMPLE_BRANCH_ANY_CALL) {
+ pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
+ return pmu_bhrb_filter;
+ }
+
+ /* Every thing else is unsupported */
+ return -1;
+}
+
+static void power8_config_bhrb(u64 pmu_bhrb_filter)
+{
+ /* Enable BHRB filter in PMU */
+ mtspr(SPRN_MMCRA, (mfspr(SPRN_MMCRA) | pmu_bhrb_filter));
+}
+
static struct power_pmu power8_pmu = {
.name = POWER8,
.n_counter = 6,
@@ -435,12 +487,15 @@ static struct power_pmu power8_pmu = {
.add_fields = POWER8_ADD_FIELDS,
.test_adder = POWER8_TEST_ADDER,
.compute_mmcr = power8_compute_mmcr,
+ .config_bhrb= power8_config_bhrb,
+ .bhrb_filter_map= power8_bhrb_filter_map,
.get_constraint = power8_get_constraint,
.disable_pmc= power8_disable_pmc,
- .flags = PPMU_HAS_SSLOT | PPMU_HAS_SIER,
+ .flags = PPMU_HAS_SSLOT | PPMU_HAS_SIER | PPMU_BHRB,
.n_generic = ARRAY_SIZE(power8_generic_events),
.generic_events = power8_generic_events,
.attr_groups= power8_pmu_attr_groups,
+ .bhrb_nr= 32,
};
static int __init init_power8_pmu(void)
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3 3/5] powerpc, perf: Add new BHRB related generic functions, data and flags
This patch adds couple of generic functions to power_pmu structure
which would configure the BHRB and it's filters. It also adds
representation of the number of BHRB entries present on the PMU.
A new PMU flag PPMU_BHRB would indicate presence of BHRB feature.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/perf_event_server.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index 57b42da..3f0c15c 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -33,6 +33,8 @@ struct power_pmu {
unsigned long *valp);
int (*get_alternatives)(u64 event_id, unsigned int flags,
u64 alt[]);
+ u64 (*bhrb_filter_map)(u64 branch_sample_type);
+ void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
int (*limited_pmc_event)(u64 event_id);
u32 flags;
@@ -42,6 +44,9 @@ struct power_pmu {
int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
[PERF_COUNT_HW_CACHE_OP_MAX]
[PERF_COUNT_HW_CACHE_RESULT_MAX];
+
+ /* BHRB entries in the PMU */
+ int bhrb_nr;
};
/*
@@ -54,6 +59,7 @@ struct power_pmu {
#define PPMU_SIAR_VALID0x0010 /* Processor has SIAR Valid
bit */
#define PPMU_HAS_SSLOT 0x0020 /* Has sampled slot in MMCRA */
#define PPMU_HAS_SIER 0x0040 /* Has SIER */
+#define PPMU_BHRB 0x0080 /* has BHRB feature enabled */
/*
* Values for flags to get_alternatives()
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3 1/5] powerpc, perf: Add new BHRB related instructions for POWER8
This patch adds new POWER8 instruction encoding for reading the BHRB buffer entries and also clearing it. Encoding for clrbhrb instruction is straight forward. But mfbhrbe encoding involves reading a certain index of BHRB buffer into a particular GPR register. Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com --- arch/powerpc/include/asm/ppc-opcode.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index 8752bc8..93ae5a1 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -82,6 +82,7 @@ #define__REGA0_R31 31 /* sorted alphabetically */ +#define PPC_INST_BHRBE 0x7c00025c #define PPC_INST_DCBA 0x7c0005ec #define PPC_INST_DCBA_MASK 0xfc0007fe #define PPC_INST_DCBAL 0x7c2005ec @@ -297,6 +298,12 @@ #define PPC_NAPstringify_in_c(.long PPC_INST_NAP) #define PPC_SLEEP stringify_in_c(.long PPC_INST_SLEEP) +/* BHRB instructions */ +#define PPC_CLRBHRBstringify_in_c(.long 0x7c00035c) +#define PPC_MFBHRBE(r, n) stringify_in_c(.long PPC_INST_BHRBE | \ + __PPC_RS(r) | \ + (((n) 0x1f) 11)) + /* Transactional memory instructions */ #define TRECHKPT stringify_in_c(.long PPC_INST_TRECHKPT) #define TRECLAIM(r)stringify_in_c(.long PPC_INST_TRECLAIM \ -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3 5/5] powerpc, perf: Enable branch stack sampling framework
Provides basic enablement for perf branch stack sampling framework on
POWER8 processor based platforms. Adds new BHRB related elements into
cpu_hw_event structure to represent current BHRB config, BHRB filter
configuration, manage context and to hold output BHRB buffer during
PMU interrupt before passing to the user space. This also enables
processing of BHRB data and converts them into generic perf branch
stack data format.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/perf_event_server.h | 1 +
arch/powerpc/perf/core-book3s.c | 167 ++-
2 files changed, 165 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index 3f0c15c..f265049 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -73,6 +73,7 @@ extern int register_power_pmu(struct power_pmu *);
struct pt_regs;
extern unsigned long perf_misc_flags(struct pt_regs *regs);
extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
+extern unsigned long int read_bhrb(int n);
/*
* Only override the default definitions in include/linux/perf_event.h
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 4ac6e64..c627843 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -19,6 +19,11 @@
#include asm/firmware.h
#include asm/ptrace.h
+#define BHRB_MAX_ENTRIES 32
+#define BHRB_TARGET0x0002
+#define BHRB_PREDICTION0x0001
+#define BHRB_EA0xFFFC
+
struct cpu_hw_events {
int n_events;
int n_percpu;
@@ -38,7 +43,15 @@ struct cpu_hw_events {
unsigned int group_flag;
int n_txn_start;
+
+ /* BHRB bits */
+ u64 bhrb_filter;/* BHRB HW branch
filter */
+ int bhrb_users;
+ void*bhrb_context;
+ struct perf_branch_stack bhrb_stack;
+ struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
};
+
DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
struct power_pmu *ppmu;
@@ -858,6 +871,9 @@ static void power_pmu_enable(struct pmu *pmu)
}
out:
+ if (cpuhw-bhrb_users)
+ ppmu-config_bhrb(cpuhw-bhrb_filter);
+
local_irq_restore(flags);
}
@@ -888,6 +904,47 @@ static int collect_events(struct perf_event *group, int
max_count,
return n;
}
+/* Reset all possible BHRB entries */
+static void power_pmu_bhrb_reset(void)
+{
+ asm volatile(PPC_CLRBHRB);
+}
+
+void power_pmu_bhrb_enable(struct perf_event *event)
+{
+ struct cpu_hw_events *cpuhw = __get_cpu_var(cpu_hw_events);
+
+ if (!ppmu-bhrb_nr)
+ return;
+
+ /* Clear BHRB if we changed task context to avoid data leaks */
+ if (event-ctx-task cpuhw-bhrb_context != event-ctx) {
+ power_pmu_bhrb_reset();
+ cpuhw-bhrb_context = event-ctx;
+ }
+ cpuhw-bhrb_users++;
+}
+
+void power_pmu_bhrb_disable(struct perf_event *event)
+{
+ struct cpu_hw_events *cpuhw = __get_cpu_var(cpu_hw_events);
+
+ if (!ppmu-bhrb_nr)
+ return;
+
+ cpuhw-bhrb_users--;
+ WARN_ON_ONCE(cpuhw-bhrb_users 0);
+
+ if (!cpuhw-disabled !cpuhw-bhrb_users) {
+ /* BHRB cannot be turned off when other
+* events are active on the PMU.
+*/
+
+ /* avoid stale pointer */
+ cpuhw-bhrb_context = NULL;
+ }
+}
+
/*
* Add a event to the PMU.
* If all events are not already frozen, then we disable and
@@ -947,6 +1004,9 @@ nocheck:
ret = 0;
out:
+ if (has_branch_stack(event))
+ power_pmu_bhrb_enable(event);
+
perf_pmu_enable(event-pmu);
local_irq_restore(flags);
return ret;
@@ -999,6 +1059,9 @@ static void power_pmu_del(struct perf_event *event, int
ef_flags)
cpuhw-mmcr[0] = ~(MMCR0_PMXE | MMCR0_FCECE);
}
+ if (has_branch_stack(event))
+ power_pmu_bhrb_disable(event);
+
perf_pmu_enable(event-pmu);
local_irq_restore(flags);
}
@@ -1117,6 +1180,15 @@ int power_pmu_commit_txn(struct pmu *pmu)
return 0;
}
+/* Called from ctxsw to prevent one process's branch entries to
+ * mingle with the other process's entries during context switch.
+ */
+void power_pmu_flush_branch_stack(void)
+{
+ if (ppmu-bhrb_nr)
+ power_pmu_bhrb_reset();
+}
+
/*
* Return 1 if we might be able to put event on a limited PMC,
* or 0 if not.
@@ -1231,9 +1303,11 @@ static int power_pmu_event_init(struct perf_event *event)
if (!ppmu)
return -ENOENT;
- /* does not support taken branch sampling */
-
[PATCH V3 2/5] powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
This patch adds the basic assembly code to read BHRB buffer. BHRB entries are valid only after a PMU interrupt has happened (when MMCR0[PMAO]=1) and BHRB has been freezed. BHRB read should not be attempted when it is still enabled (MMCR0[PMAE]=1) and getting updated, as this can produce non-deterministic results. Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com --- arch/powerpc/perf/Makefile | 2 +- arch/powerpc/perf/bhrb.S | 44 2 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/perf/bhrb.S diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile index 472db18..510fae1 100644 --- a/arch/powerpc/perf/Makefile +++ b/arch/powerpc/perf/Makefile @@ -2,7 +2,7 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror obj-$(CONFIG_PERF_EVENTS) += callchain.o -obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o +obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \ power5+-pmu.o power6-pmu.o power7-pmu.o \ power8-pmu.o diff --git a/arch/powerpc/perf/bhrb.S b/arch/powerpc/perf/bhrb.S new file mode 100644 index 000..d85f9a5 --- /dev/null +++ b/arch/powerpc/perf/bhrb.S @@ -0,0 +1,44 @@ +/* + * Basic assembly code to read BHRB entries + * + * Copyright 2013 Anshuman Khandual, IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ +#include asm/ppc_asm.h +#include asm/ppc-opcode.h + + .text + +.balign 8 + +/* r3 = n (where n = [0-31]) + * The maximum number of BHRB entries supported with PPC_MFBHRBE instruction + * is 1024. We have limited number of table entries here as POWER8 implements + * 32 BHRB entries. + */ + +/* .global read_bhrb */ +_GLOBAL(read_bhrb) + cmpldi r3,31 + bgt 1f + ld r4,bhrb_table@got(r2) + sldir3,r3,3 + add r3,r4,r3 + mtctr r3 + bctr +1: li r3,0 + blr + +#define MFBHRB_TABLE1(n) PPC_MFBHRBE(R3,n); blr +#define MFBHRB_TABLE2(n) MFBHRB_TABLE1(n); MFBHRB_TABLE1(n+1) +#define MFBHRB_TABLE4(n) MFBHRB_TABLE2(n); MFBHRB_TABLE2(n+2) +#define MFBHRB_TABLE8(n) MFBHRB_TABLE4(n); MFBHRB_TABLE4(n+4) +#define MFBHRB_TABLE16(n) MFBHRB_TABLE8(n); MFBHRB_TABLE8(n+8) +#define MFBHRB_TABLE32(n) MFBHRB_TABLE16(n); MFBHRB_TABLE16(n+16) + +bhrb_table: + MFBHRB_TABLE32(0) -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3 0/5] powerpc, perf: BHRB based branch stack enablement on POWER8
Branch History Rolling Buffer (BHRB) is a new PMU feaure in IBM POWER8 processor which records the branch instructions inside the execution pipeline. This patchset enables the basic functionality of the feature through generic perf branch stack sampling framework. Sample output - $./perf record -b top $./perf report Overhead Command Source Shared Object Source Symbol Target Shared ObjectTarget Symbol # ... .. ... # 7.82% top libc-2.11.2.so[k] _IO_vfscanf libc-2.11.2.so[k] _IO_vfscanf 6.17% top libc-2.11.2.so[k] _IO_vfscanf [unknown] [k] 2.37% top [unknown] [k] 0xf7aafb30 [unknown] [k] 1.80% top [unknown] [k] 0x0fe07978 libc-2.11.2.so[k] _IO_vfscanf 1.60% top libc-2.11.2.so[k] _IO_vfscanf [kernel.kallsyms] [k] .do_task_stat 1.20% top [kernel.kallsyms] [k] .do_task_stat [kernel.kallsyms] [k] .do_task_stat 1.02% top libc-2.11.2.so[k] vfprintf libc-2.11.2.so[k] vfprintf 0.92% top top [k] _init [unknown] [k] 0x0fe037f4 Changes in V2 -- - Added copyright messages to the newly created files - Modified couple of commit messages Changes in V3 - - Incorporated review comments from Segher https://lkml.org/lkml/2013/4/16/350 - Worked on a solution for review comment from Michael Ellerman https://lkml.org/lkml/2013/4/17/548 - Could not move updated cpu_hw_events structure from core-book3s.c file into perf_event_server.h Because perf_event_server.h is pulled in first inside linux/perf_event.h before the definition of perf_branch_entry structure. Thats the reason why perf_branch_entry definition is not available inside perf_event_server.h where we define the array inside cpu_hw_events structure. - Finally have pulled in the code from perf_event_bhrb.c into core-book3s.c - Improved documentation for the patchset Anshuman Khandual (5): powerpc, perf: Add new BHRB related instructions for POWER8 powerpc, perf: Add basic assembly code to read BHRB entries on POWER8 powerpc, perf: Add new BHRB related generic functions, data and flags powerpc, perf: Define BHRB generic functions, data and flags for POWER8 powerpc, perf: Enable branch stack sampling framework arch/powerpc/include/asm/perf_event_server.h | 7 ++ arch/powerpc/include/asm/ppc-opcode.h| 7 ++ arch/powerpc/perf/Makefile | 2 +- arch/powerpc/perf/bhrb.S | 44 +++ arch/powerpc/perf/core-book3s.c | 167 ++- arch/powerpc/perf/power8-pmu.c | 57 - 6 files changed, 279 insertions(+), 5 deletions(-) create mode 100644 arch/powerpc/perf/bhrb.S -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper ja...@lakedaemon.net wrote: On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote: On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper ja...@lakedaemon.net wrote: On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote: On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com wrote: On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Linus Walleij linus.wall...@linaro.org Acked-by: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 arch/powerpc/include/asm/pci-bridge.h|5 +- arch/powerpc/kernel/pci-common.c | 192 Is there anyone on linuxppc-dev/linux-mips that can help test this patchset? I've tested that it builds on powerpc with a variety of configs (some which include fsl_pci.c implementation). Though I don't have hardware to verify that it works. I haven't tested this builds or runs on MIPS. You shouldn't see any difference in behaviour or new warnings and PCI devices should continue to operate as before. I've got through a line-by-line comparison between powerpc, microblaze, and then new code. The differences are purely cosmetic, so I have absolutely no concerns about this patch. I've applied it to my tree. oops. Due to the number of dependencies the mvebu-pcie series has (this being one of them, we (arm-soc/mvebu) asked if we could take this through our tree. Rob Herring agreed to this several days ago. Is this a problem for you? It would truly (dogs and cats living together) upset the apple cart for us at this stage to pipe these through a different tree... Not a problem at all. I'll drop it. Great! Thanks. You can add my Acked-by: Grant Likely grant.lik...@linaro.org to the first patch. I've not reviewed out the second or third patches yet. None of this appears to be in linux-next yet. I've boot tested on PowerPC, but that isn't the same as an ack by the PowerPC maintainers. It is probably too late for the whole now since we're after -rc7. However, if you ask me to, I have absolutely no problem putting the first patch into my tree for v3.10 merging. I went over the patch line-by-line and am convinced that it is functionally identical. Let me know if you need me to do this. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote: On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray andrew.mur...@arm.com wrote: This patch converts the pci_load_of_ranges function to use the new common of_pci_range_parser. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Linus Walleij linus.wall...@linaro.org Jason - you may not have seen this, but here (Linus Walleij) is another Tested-by to add to this patch in your tree (if you can). Andrew Murray ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Thu, Apr 18, 2013 at 01:48:32PM +0100, Grant Likely wrote: On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper ja...@lakedaemon.net wrote: On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote: On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper ja...@lakedaemon.net wrote: On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote: On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com wrote: On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Linus Walleij linus.wall...@linaro.org Acked-by: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 arch/powerpc/include/asm/pci-bridge.h|5 +- arch/powerpc/kernel/pci-common.c | 192 Is there anyone on linuxppc-dev/linux-mips that can help test this patchset? I've tested that it builds on powerpc with a variety of configs (some which include fsl_pci.c implementation). Though I don't have hardware to verify that it works. I haven't tested this builds or runs on MIPS. You shouldn't see any difference in behaviour or new warnings and PCI devices should continue to operate as before. I've got through a line-by-line comparison between powerpc, microblaze, and then new code. The differences are purely cosmetic, so I have absolutely no concerns about this patch. I've applied it to my tree. oops. Due to the number of dependencies the mvebu-pcie series has (this being one of them, we (arm-soc/mvebu) asked if we could take this through our tree. Rob Herring agreed to this several days ago. Is this a problem for you? It would truly (dogs and cats living together) upset the apple cart for us at this stage to pipe these through a different tree... Not a problem at all. I'll drop it. Great! Thanks. You can add my Acked-by: Grant Likely grant.lik...@linaro.org to the first patch. I've not reviewed out the second or third patches yet. None of this appears to be in linux-next yet. I've boot tested on PowerPC, but that isn't the same as an ack by the PowerPC maintainers. It is probably too late for the whole now since we're after -rc7. However, if you ask me to, I have absolutely no problem putting the first patch into my tree for v3.10 merging. I went over the patch line-by-line and am convinced that it is functionally identical. Let me know if you need me to do this. Thanks for the offer, Olof just pulled the branch last night (my PRs were a little late trying to sort all this out), so it should be in shortly. FYI: 65ee348 of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC is in arm-soc/mvebu/drivers as well as arm-soc/next/drivers (and arm-soc/for-next if you want to test merging everything...) thx, Jason. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote: On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote: On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray andrew.mur...@arm.com wrote: This patch converts the pci_load_of_ranges function to use the new common of_pci_range_parser. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Linus Walleij linus.wall...@linaro.org Jason - you may not have seen this, but here (Linus Walleij) is another Tested-by to add to this patch in your tree (if you can). Thanks, I saw it. Unfortunately, the PR was already sent, and the branch is now pulled into arm-soc. thx, Jason. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray andrew.mur...@arm.com wrote:
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture
specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Linus Walleij linus.wall...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
But comments below...
---
drivers/of/address.c | 67 ++
drivers/of/of_pci.c| 113
include/linux/of_address.h | 46 ++
3 files changed, 154 insertions(+), 72 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..6eec70c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser);
of_pci_range_parser_init would be a clearer name
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
Similarly, of_pci_range_parser_one would be more consistent.
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = parser-range[0];
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
#endif /* CONFIG_PCI */
/*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 1626172..e5ab604 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
#include linux/export.h
#include linux/of.h
#include linux/of_pci.h
+#include linux/of_address.h
#include asm/prom.h
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Tue, 16 Apr 2013 11:18:28 +0100, Andrew Murray andrew.mur...@arm.com wrote: This patch converts the pci_load_of_ranges function to use the new common of_pci_range_parser. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Looks okay to me, and thank you very much for doing the legwork to merge the common code. Reviewed-by: Grant Likely grant.lik...@secretlab.ca ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray andrew.mur...@arm.com
wrote:
This patch factors out common implementation patterns to reduce overall
kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture
specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges
them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Linus Walleij linus.wall...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
But comments below...
---
drivers/of/address.c | 67 ++
drivers/of/of_pci.c| 113
include/linux/of_address.h | 46 ++
3 files changed, 154 insertions(+), 72 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..6eec70c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node
*dev, int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser);
of_pci_range_parser_init would be a clearer name
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
Similarly, of_pci_range_parser_one would be more consistent.
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = parser-range[0];
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
#endif /* CONFIG_PCI */
/*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 1626172..e5ab604 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
#include linux/export.h
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Thu, Apr 18, 2013 at 02:45:35PM +0100, Grant Likely wrote: On Tue, 16 Apr 2013 11:18:28 +0100, Andrew Murray andrew.mur...@arm.com wrote: This patch converts the pci_load_of_ranges function to use the new common of_pci_range_parser. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Looks okay to me, and thank you very much for doing the legwork to merge the common code. No problem, though I think there is more than can be done in this area - there is a lot of similar PCI code floating about. Reviewed-by: Grant Likely grant.lik...@secretlab.ca Thanks for the review. Andrew Murray ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Thu, Apr 18, 2013 at 3:24 PM, Andrew Murray andrew.mur...@arm.com wrote:
On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray andrew.mur...@arm.com
wrote:
/* Act based on address space type */
res = NULL;
- switch ((pci_space 24) 0x3) {
- case 1: /* PCI IO space */
+ res_type = range.flags IORESOURCE_TYPE_BITS;
+ if (res_type == IORESOURCE_IO) {
Why the change from switch() to an if/else if sequence?
Russell King suggested this change - see
https://patchwork.kernel.org/patch/2323941/
Umm, that isn't what that link shows. That link shows the patch
already changing to an if/else if construct, and rmk is commenting on
that.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Thu, Apr 18, 2013 at 04:29:54PM +0100, Grant Likely wrote:
On Thu, Apr 18, 2013 at 3:24 PM, Andrew Murray andrew.mur...@arm.com wrote:
On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray andrew.mur...@arm.com
wrote:
/* Act based on address space type */
res = NULL;
- switch ((pci_space 24) 0x3) {
- case 1: /* PCI IO space */
+ res_type = range.flags IORESOURCE_TYPE_BITS;
+ if (res_type == IORESOURCE_IO) {
Why the change from switch() to an if/else if sequence?
Russell King suggested this change - see
https://patchwork.kernel.org/patch/2323941/
Umm, that isn't what that link shows. That link shows the patch
already changing to an if/else if construct, and rmk is commenting on
that.
Arh yes sorry about that. I can't find or remember any good reason why I
changed it from a switch to an if/else :\
Andrew Murray
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/28] proc: Supply PDE attribute setting accessor functions [RFC]
On Tue, Apr 16, 2013 at 12:26 PM, David Howells dhowe...@redhat.com wrote:
Supply accessor functions to set attributes in proc_dir_entry structs.
The following are supplied: proc_set_size() and proc_set_user().
Signed-off-by: David Howells dhowe...@redhat.com
cc: linuxppc-dev@lists.ozlabs.org
cc: linux-me...@vger.kernel.org
cc: net...@vger.kernel.org
cc: linux-wirel...@vger.kernel.org
cc: linux-...@vger.kernel.org
cc: netfilter-de...@vger.kernel.org
cc: alsa-de...@alsa-project.org
---
arch/powerpc/kernel/proc_powerpc.c|2 +-
arch/powerpc/platforms/pseries/reconfig.c |2 +-
drivers/media/pci/ttpci/av7110_ir.c |2 +-
drivers/net/irda/vlsi_ir.c|2 +-
drivers/net/wireless/airo.c | 34
+
drivers/pci/proc.c|2 +-
For the drivers/pci part:
Acked-by: Bjorn Helgaas bhelg...@google.com
fs/proc/generic.c | 13 +++
include/linux/proc_fs.h |5
kernel/configs.c |2 +-
kernel/profile.c |2 +-
net/netfilter/xt_recent.c |3 +--
sound/core/info.c |2 +-
12 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/proc_powerpc.c
b/arch/powerpc/kernel/proc_powerpc.c
index 41d8ee9..feb8580 100644
--- a/arch/powerpc/kernel/proc_powerpc.c
+++ b/arch/powerpc/kernel/proc_powerpc.c
@@ -83,7 +83,7 @@ static int __init proc_ppc64_init(void)
page_map_fops, vdso_data);
if (!pde)
return 1;
- pde-size = PAGE_SIZE;
+ proc_set_size(pde, PAGE_SIZE);
return 0;
}
diff --git a/arch/powerpc/platforms/pseries/reconfig.c
b/arch/powerpc/platforms/pseries/reconfig.c
index d6491bd..f93cdf5 100644
--- a/arch/powerpc/platforms/pseries/reconfig.c
+++ b/arch/powerpc/platforms/pseries/reconfig.c
@@ -452,7 +452,7 @@ static int proc_ppc64_create_ofdt(void)
ent = proc_create(powerpc/ofdt, S_IWUSR, NULL, ofdt_fops);
if (ent)
- ent-size = 0;
+ proc_set_size(ent, 0);
return 0;
}
diff --git a/drivers/media/pci/ttpci/av7110_ir.c
b/drivers/media/pci/ttpci/av7110_ir.c
index eb82286..0e763a7 100644
--- a/drivers/media/pci/ttpci/av7110_ir.c
+++ b/drivers/media/pci/ttpci/av7110_ir.c
@@ -375,7 +375,7 @@ int av7110_ir_init(struct av7110 *av7110)
if (av_cnt == 1) {
e = proc_create(av7110_ir, S_IWUSR, NULL,
av7110_ir_proc_fops);
if (e)
- e-size = 4 + 256 * sizeof(u16);
+ proc_set_size(e, 4 + 256 * sizeof(u16));
}
tasklet_init(av7110-ir.ir_tasklet, av7110_emit_key, (unsigned long)
av7110-ir);
diff --git a/drivers/net/irda/vlsi_ir.c b/drivers/net/irda/vlsi_ir.c
index e22cd4e..5f47584 100644
--- a/drivers/net/irda/vlsi_ir.c
+++ b/drivers/net/irda/vlsi_ir.c
@@ -1678,7 +1678,7 @@ vlsi_irda_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
IRDA_WARNING(%s: failed to create proc entry\n,
__func__);
} else {
- ent-size = 0;
+ proc_set_size(ent, 0);
}
idev-proc_entry = ent;
}
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 66e398d..21d0233 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -4507,73 +4507,63 @@ static int setup_proc_entry( struct net_device *dev,
airo_entry);
if (!apriv-proc_entry)
goto fail;
- apriv-proc_entry-uid = proc_kuid;
- apriv-proc_entry-gid = proc_kgid;
+ proc_set_user(apriv-proc_entry, proc_kuid, proc_kgid);
/* Setup the StatsDelta */
entry = proc_create_data(StatsDelta, S_IRUGO proc_perm,
apriv-proc_entry, proc_statsdelta_ops,
dev);
if (!entry)
goto fail_stats_delta;
- entry-uid = proc_kuid;
- entry-gid = proc_kgid;
+ proc_set_user(entry, proc_kuid, proc_kgid);
/* Setup the Stats */
entry = proc_create_data(Stats, S_IRUGO proc_perm,
apriv-proc_entry, proc_stats_ops, dev);
if (!entry)
goto fail_stats;
- entry-uid = proc_kuid;
- entry-gid = proc_kgid;
+ proc_set_user(entry, proc_kuid, proc_kgid);
/* Setup the Status */
entry = proc_create_data(Status, S_IRUGO proc_perm,
apriv-proc_entry, proc_status_ops, dev);
if (!entry)
goto fail_status;
- entry-uid = proc_kuid;
- entry-gid = proc_kgid;
+ proc_set_user(entry,
Re: [PATCH] [RFC] powerpc: Add VDSO version of time
Hi Adhemerval, This patch implement the time syscall as vDSO. I have a glibc patch to use it as IFUNC (as latest gettimeofday patch). Below the perf numbers: Baseline PPC32: 380 nsec Baseline PPC64: 352 nsec vdso PPC32: 20 nsec vdso PPC64: 20 nsec Very nice speedup. One small performance improvement: +1: ld r8,CFG_TB_UPDATE_COUNT(r3) + ld r4,STAMP_XTIME+TSPC64_TV_SEC(r3) + andi. r0,r8,1 /* pending update ? loop */ + bne-1b Since you are only reading one long you shouldn't need to check the update count and loop, you will always see a consistent value. The system call version of time() just does an unprotected load for example. I focused on 64 bit kernel, do I need to provide a scheme for 32 bits as well? Any tips, advices, comments? With the above change and with Michael's comments covered (decent changelog entry and Signed-off-by): Acked-by: Anton Blanchard an...@samba.org Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V5 00/25] THP support for PPC64
Hi Aneesh, On 04/04/2013 01:57 PM, Aneesh Kumar K.V wrote: Hi, This patchset adds transparent hugepage support for PPC64. TODO: * hash preload support in update_mmu_cache_pmd (we don't do that for hugetlb) Some numbers: The latency measurements code from Anton found at http://ozlabs.org/~anton/junkcode/latency2001.c THP disabled 64K page size [root@llmp24l02 ~]# ./latency2001 8G 8589934592731.73 cycles205.77 ns [root@llmp24l02 ~]# ./latency2001 8G 8589934592743.39 cycles209.05 ns [root@llmp24l02 ~]# THP disabled large page via hugetlbfs - [root@llmp24l02 ~]# ./latency2001 -l 8G 8589934592416.09 cycles117.01 ns [root@llmp24l02 ~]# ./latency2001 -l 8G 8589934592415.74 cycles116.91 ns THP enabled 64K page size. [root@llmp24l02 ~]# ./latency2001 8G 8589934592405.07 cycles113.91 ns [root@llmp24l02 ~]# ./latency2001 8G 8589934592411.82 cycles115.81 ns [root@llmp24l02 ~]# We are close to hugetlbfs in latency and we can achieve this with zero config/page reservation. Most of the allocations above are fault allocated. Another test that does 5000 random access over 1GB area goes from 2.65 seconds to 1.07 seconds with this patchset. split_huge_page impact: - To look at the performance impact of large page invalidate, I tried the below experiment. The test involved, accessing a large contiguous region of memory location as below for (i = 0; i size; i += PAGE_SIZE) data[i] = i; We wanted to access the data in sequential order so that we look at the worst case THP performance. Accesing the data in sequential order implies we have the Page table cached and overhead of TLB miss is as minimal as possible. We also don't touch the entire page, because that can result in cache evict. After we touched the full range as above, we now call mprotect on each of that page. A mprotect will result in a hugepage split. This should allow us to measure the impact of hugepage split. for (i = 0; i size; i += PAGE_SIZE) mprotect(data[i], PAGE_SIZE, PROT_READ); Split hugepage impact: - THP enabled: 2.851561705 seconds for test completion THP disable: 3.599146098 seconds for test completion We are 20.7% better than non THP case even when we have all the large pages split. Detailed output: THP enabled: --- [root@llmp24l02 ~]# cat /proc/vmstat | grep thp thp_fault_alloc 0 thp_fault_fallback 0 thp_collapse_alloc 0 thp_collapse_alloc_failed 0 thp_split 0 thp_zero_page_alloc 0 thp_zero_page_alloc_failed 0 [root@llmp24l02 ~]# /root/thp/tools/perf/perf stat -e page-faults,dTLB-load-misses ./split-huge-page-mpro 20G time taken to touch all the data in ns: 2763096913 Performance counter stats for './split-huge-page-mpro 20G': 1,581 page-faults 3,159 dTLB-load-misses 2.851561705 seconds time elapsed [root@llmp24l02 ~]# [root@llmp24l02 ~]# cat /proc/vmstat | grep thp thp_fault_alloc 1279 thp_fault_fallback 0 thp_collapse_alloc 0 thp_collapse_alloc_failed 0 thp_split 1279 thp_zero_page_alloc 0 thp_zero_page_alloc_failed 0 [root@llmp24l02 ~]# 77.05% split-huge-page [kernel.kallsyms] [k] .clear_user_page 7.10% split-huge-page [kernel.kallsyms] [k] .perf_event_mmap_ctx 1.51% split-huge-page split-huge-page-mpro [.] 0x0a70 0.96% split-huge-page [unknown] [H] 0x0157e3bc 0.81% split-huge-page [kernel.kallsyms] [k] .up_write 0.76% split-huge-page [kernel.kallsyms] [k] .perf_event_mmap 0.76% split-huge-page [kernel.kallsyms] [k] .down_write 0.74% split-huge-page [kernel.kallsyms] [k] .lru_add_page_tail 0.61% split-huge-page [kernel.kallsyms] [k] .split_huge_page 0.59% split-huge-page [kernel.kallsyms] [k] .change_protection 0.51% split-huge-page [kernel.kallsyms] [k] .release_pages 0.96% split-huge-page [unknown] [H] 0x0157e3bc | |--79.44%-- reloc_start | | | |--86.54%-- .__pSeries_lpar_hugepage_invalidate | | .pSeries_lpar_hugepage_invalidate | | .hpte_need_hugepage_flush | | .split_huge_page | | .__split_huge_page_pmd | | .vma_adjust | | .vma_merge | | .mprotect_fixup | | .SyS_mprotect THP disabled: --- [root@llmp24l02 ~]# echo never /sys/kernel/mm/transparent_hugepage/enabled [root@llmp24l02 ~]# /root/thp/tools/perf/perf stat -e page-faults,dTLB-load-misses ./split-huge-page-mpro 20G time taken to touch all the data in ns: 3513767220
Re: [RFC PATCH powerpc] make CONFIG_NUMA depends on CONFIG_SMP
On Thu, 2013-04-18 at 11:46 +1000, Michael Ellerman wrote: On Wed, May 30, 2012 at 05:31:58PM +0800, Li Zhong wrote: I'm not sure whether it makes sense to add this dependency to avoid CONFI_NUMA !CONFIG_SMP. I want to do this because I saw some build errors on next-tree when compiling with CONFIG_SMP disabled, and it seems they are caused by some codes under the CONFIG_NUMA #ifdefs. This seems to make sense to me. Can you please repost with a better changelog and a description of the actual build error you were seeing. I tried it today, but didn't find any build errors any more, guess those errors should have already been fixed. But it seems to me by disabling CONFIG_NUMA when CONFIG_SMP is disabled, could at least prevent some unnecessary code being compiled into the kernel. (After building a kernel with/without CONFIG_NUMA just now, it seems that the vmlinux is ~100K smaller without CONFIG_NUMA). I'm not sure whether this is still needed. Thanks, Zhong cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
