LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 1/3] powerpc/booke64: add sync after writing PTE
From: Scott Wood @ 2013-09-14  3:50 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev

The ISA says that a sync is needed to order a PTE write with a
subsequent hardware tablewalk lookup.  On e6500, without this sync
we've been observed to die with a DSI due to a PTE write not being seen
by a subsequent access, even when everything happens on the same
CPU.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: new patch

Note that we saw this problem when running in emulation (died early in
boot), but when I tried just now with the mb() removed on actual
hardware, I didn't see any problem.  But since I'm not aware of any
change having been made in the hardware relative to this, and since it
is architecturally required, I'd be more comfortable leaving it in
unlesss something has changed in the kernel recently such that a sync
is happening somewhere else along the code path.
---
 arch/powerpc/include/asm/pgtable.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index 7d6eacf..0459077 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -143,6 +143,13 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
 	 * cases, and 32-bit non-hash with 32-bit PTEs.
 	 */
 	*ptep = pte;
+#ifdef CONFIG_PPC_BOOK3E_64
+	/*
+	 * With hardware tablewalk, a sync is needed to ensure that
+	 * subsequent accesses see the PTE we just wrote.
+	 */
+	mb();
+#endif
 #endif
 }
 
-- 
1.8.1.2

^ permalink raw reply related

* [PATCH 8/8][v4] powerpc/perf: Export Power7 memory hierarchy info to user space.
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

On Power7, the DCACHE_SRC field in MMCRA register identifies the memory
hierarchy level (eg: L2, L3 etc) from which a data-cache miss for a
marked instruction was satisfied.

Use the 'perf_mem_data_src' object to export this hierarchy level to user
space. Some memory hierarchy levels in Power7 don't map into the arch-neutral
levels. However, since newer generation of the processor (i.e. Power8) uses
fewer levels than in Power7, we don't really need to define new hierarchy
levels just for Power7.

We instead, map as many levels as possible and approximate the rest. See
comments near dcache-src_map[] in the patch.

Usage:

	perf record -d -e 'cpu/PM_MRK_GRP_CMPL/' <application>
	perf report -n --mem-mode --sort=mem,sym,dso,symbol_daddr,dso_daddr"

		For samples involving load/store instructions, the memory
		hierarchy level is shown as "L1 hit", "Remote RAM hit" etc.
	# or

	perf record --data <application>
	perf report -D

		Sample records contain a 'data_src' field which encodes the
		memory hierarchy level: Eg: data_src 0x442 indicates
		MEM_OP_LOAD, MEM_LVL_HIT, MEM_LVL_L2 (i.e load hit L2).

Note that the PMU event PM_MRK_GRP_CMPL tracks all marked group completions
events. While some of these are loads and stores, others like 'add'
instructions may also be sampled.

As such, the precise semantics of 'perf mem -t load' or 'perf mem -t store'
(which require sampling only loads or only stores cannot be implemented on
Power. (Sampling on PM_MRK_GRP_CMPL and throwing away non-loads and non-store
samples could yield an inconsistent profile of the application).

Thanks to input from Stephane Eranian, Michael Ellerman and Michael Neuling.

Cc: Stephane Eranian <eranian@google.com>
Cc: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog[v4]:
	Drop support for 'perf mem' for Power (use perf-record and perf-report
	directly)

Changelog[v3]:
	[Michael Ellerman] If newer levels that we defined in [v2] are not
	needed for Power8, ignore the new levels for Power7 also, and
	approximate them.
	Separate the TLB level mapping to a separate patchset.

Changelog[v2]:
        [Stephane Eranian] Define new levels rather than ORing the L2 and L3
        with REM_CCE1 and REM_CCE2.
        [Stephane Eranian] allocate a bit PERF_MEM_XLVL_NA for architectures
        that don't use the ->mem_xlvl field.
        Insert the TLB patch ahead so the new TLB bits are contigous with
        existing TLB bits.

 arch/powerpc/perf/power7-pmu.c |   94 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 56c67bc..ddfa548 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -11,8 +11,10 @@
 #include <linux/kernel.h>
 #include <linux/perf_event.h>
 #include <linux/string.h>
+#include <linux/uaccess.h>
 #include <asm/reg.h>
 #include <asm/cputable.h>
+#include <asm/code-patching.h>
 
 /*
  * Bits in event code for POWER7
@@ -317,6 +319,97 @@ static void power7_disable_pmc(unsigned int pmc, unsigned long mmcr[])
 		mmcr[1] &= ~(0xffUL << MMCR1_PMCSEL_SH(pmc));
 }
 
+#define POWER7_MMCRA_DCACHE_MISS	(0x1LL << 55)
+#define POWER7_MMCRA_DCACHE_SRC_SHIFT	51
+#define POWER7_MMCRA_DCACHE_SRC_MASK	(0xFLL << POWER7_MMCRA_DCACHE_SRC_SHIFT)
+
+#define P(a, b)		PERF_MEM_S(a, b)
+#define PLH(a, b)	(P(OP, LOAD) | P(LVL, HIT) | P(a, b))
+/*
+ * Map the Power7 DCACHE_SRC field (bits 9..12) in MMCRA register to the
+ * architecture-neutral memory hierarchy levels. For the levels in Power7
+ * that don't map to the arch-neutral levels, approximate to nearest
+ * level.
+ *
+ *	1-hop:	indicates another core on the same chip (2.1 and 3.1 levels).
+ *	2-hops:	indicates a different chip on same or different node (remote
+ *		and distant levels).
+ *
+ * For consistency with this interpretation of the hops, we dont use
+ * the REM_RAM1 level below.
+ *
+ * The *SHR and *MOD states of the cache are ignored/not exported to user.
+ *
+ * ### Levels marked with ### in comments below are approximated
+ */
+static u64 dcache_src_map[] = {
+	PLH(LVL, L2),			/* 00: FROM_L2 */
+	PLH(LVL, L3),			/* 01: FROM_L3 */
+
+	P(LVL, NA),			/* 02: Reserved */
+	P(LVL, NA),			/* 03: Reserved */
+
+	PLH(LVL, REM_CCE1),		/* 04: FROM_L2.1_SHR ### */
+	PLH(LVL, REM_CCE1),		/* 05: FROM_L2.1_MOD ### */
+
+	PLH(LVL, REM_CCE1),		/* 06: FROM_L3.1_SHR ### */
+	PLH(LVL, REM_CCE1),		/* 07: FROM_L3.1_MOD ### */
+
+	PLH(LVL, REM_CCE2),		/* 08: FROM_RL2L3_SHR ### */
+	PLH(LVL, REM_CCE2),		/* 09: FROM_RL2L3_MOD ### */
+
+	PLH(LVL, REM_CCE2),		/* 10: FROM_DL2L3_SHR ### */
+	PLH(LVL, REM_CCE2),		/* 11: FROM_DL2L3_MOD ### */
+
+	PLH(LVL, LOC_RAM),		/* 12: FROM_LMEM */
+	PLH(LVL, REM_RAM2),		/* 13: FROM_RMEM ### */
+	PLH(LVL, REM_RAM2),		/* 14: FROM_DMEM */
+
+	P(LVL, NA),			/* 15: Reserved */
+};
+
+/*
+ * Determine the memory-hierarchy information (if applicable) for the
+ * instruction/address we are sampling. If we encountered a DCACHE_MISS,
+ * mmcra[DCACHE_SRC_MASK] specifies the memory level from which the operand
+ * was loaded.
+ *
+ * Otherwise, it is an L1-hit, provided the instruction was a load/store.
+ */
+static void power7_get_mem_data_src(union perf_mem_data_src *dsrc,
+			struct pt_regs *regs)
+{
+	u64 idx;
+	u64 mmcra = regs->dsisr;
+	u64 addr;
+	int ret;
+	unsigned int instr;
+
+	if (mmcra & POWER7_MMCRA_DCACHE_MISS) {
+		idx = mmcra & POWER7_MMCRA_DCACHE_SRC_MASK;
+		idx >>= POWER7_MMCRA_DCACHE_SRC_SHIFT;
+
+		dsrc->val |= dcache_src_map[idx];
+		return;
+	}
+
+	instr = 0;
+	addr = perf_instruction_pointer(regs);
+
+	if (is_kernel_addr(addr))
+		instr = *(unsigned int *)addr;
+	else {
+		pagefault_disable();
+		ret = __get_user_inatomic(instr, (unsigned int __user *)addr);
+		pagefault_enable();
+		if (ret)
+			instr = 0;
+	}
+	if (instr && instr_is_load_store(&instr))
+		dsrc->val |= PLH(LVL, L1);
+}
+
+
 static int power7_generic_events[] = {
 	[PERF_COUNT_HW_CPU_CYCLES] =			PME_PM_CYC,
 	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] =	PME_PM_GCT_NOSLOT_CYC,
@@ -437,6 +530,7 @@ static struct power_pmu power7_pmu = {
 	.get_constraint		= power7_get_constraint,
 	.get_alternatives	= power7_get_alternatives,
 	.disable_pmc		= power7_disable_pmc,
+	.get_mem_data_src	= power7_get_mem_data_src,
 	.flags			= PPMU_ALT_SIPR,
 	.attr_groups		= power7_pmu_attr_groups,
 	.n_generic		= ARRAY_SIZE(power7_generic_events),
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 7/8][v4] power: implement is_instr_load_store().
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

Implement is_instr_load_store() to detect whether a given instruction
is one of the fixed-point or floating-point load/store instructions.
This function will be used in a follow-on patch to save memory hierarchy
information of the load/store.

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/code-patching.h |    1 +
 arch/powerpc/lib/code-patching.c         |   90 ++++++++++++++++++++++++++++++
 2 files changed, 91 insertions(+)

diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h
index a6f8c7a..3e47fe0 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -34,6 +34,7 @@ int instr_is_branch_to_addr(const unsigned int *instr, unsigned long addr);
 unsigned long branch_target(const unsigned int *instr);
 unsigned int translate_branch(const unsigned int *dest,
 			      const unsigned int *src);
+int instr_is_load_store(const unsigned int *instr);
 
 static inline unsigned long ppc_function_entry(void *func)
 {
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 2bc9db3..7e5dc6f 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -159,6 +159,96 @@ unsigned int translate_branch(const unsigned int *dest, const unsigned int *src)
 	return 0;
 }
 
+static unsigned int load_store_xval(const unsigned int instr)
+{
+	return (instr >> 1) & 0x3FF;	/* bits 21..30 */
+}
+
+/*
+ * Values of bits 21:30 of Fixed-point and Floating-point Load and Store
+ * instructions.
+ *
+ * Reference:	PowerISA_V2.06B_Public.pdf, Sections 3.3.2 through 3.3.6 and
+ *		4.6.2 through 4.6.4.
+ */
+#define	x_lbzx		87
+#define	x_lbzux		119
+#define	x_lhzx		279
+#define	x_lhzux		311
+#define	x_lhax		343
+#define	x_lhaux		375
+#define	x_lwzx		23
+#define	x_lwzux		55
+#define	x_lwax		341
+#define	x_lwaux		373
+#define	x_ldx		21
+#define	x_ldux		53
+#define	x_stbx		215
+#define	x_stbux		247
+#define	x_sthx		407
+#define	x_sthux		439
+#define	x_stwx		151
+#define	x_stwux		183
+#define	x_stdx		149
+#define	x_stdux		181
+#define	x_lhbrx		790
+#define	x_lwbrx		534
+#define	x_sthbrx	918
+#define	x_stwbrx	662
+#define	x_ldbrx		532
+#define	x_stdbrx	660
+#define	x_lswi		597
+#define	x_lswx		533
+#define	x_stswi		725
+#define	x_stswx		661
+#define	x_lfsx		535
+#define	x_lfsux		567
+#define	x_lfdx		599
+#define	x_lfdux		631
+#define	x_lfiwax	855
+#define	x_lfiwzx	887
+#define	x_stfsx		663
+#define	x_stfsux	695
+#define	x_stfdx		727
+#define	x_stfdux	759
+#define	x_stfiwax	983
+#define	x_lfdpx		791
+#define	x_stfdpx	919
+
+static unsigned int x_form_load_store[] = {
+	x_lbzx,     x_lbzux,    x_lhzx,     x_lhzux,    x_lhax,
+	x_lhaux,    x_lwzx,     x_lwzux,    x_lwax,     x_lwaux,
+	x_ldx,      x_ldux,     x_stbx,     x_stbux,    x_sthx,
+	x_sthux,    x_stwx,     x_stwux,    x_stdx,     x_stdux,
+	x_lhbrx,    x_lwbrx,    x_sthbrx,   x_stwbrx,   x_ldbrx,
+	x_stdbrx,   x_lswi,     x_lswx,     x_stswi,    x_stswx,
+	x_lfsx,     x_lfsux,    x_lfdx,     x_lfdux,    x_lfiwax,
+	x_lfiwzx,   x_stfsx,    x_stfsux,   x_stfdx,    x_stfdux,
+	x_stfiwax,  x_lfdpx,    x_stfdpx
+};
+
+int instr_is_load_store(const unsigned int *instr)
+{
+	unsigned int op;
+	int i, n;
+
+	op = instr_opcode(*instr);
+
+	if ((op >= 32 && op <= 58) || (op == 61 || op == 62))
+		return 1;
+
+	if (op == 31) {
+		n = sizeof(x_form_load_store) / sizeof(int);
+
+		for (i = 0; i < n; i++) {
+			if (x_form_load_store[i] == load_store_xval(*instr))
+				return 1;
+		}
+	}
+
+	return 0;
+}
+
 
 #ifdef CONFIG_CODE_PATCHING_SELFTEST
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 6/8][v4] powerpc: Rename branch_opcode() to instr_opcode()
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

The logic used in branch_opcode() to extract the opcode for an instruction
applies to non branch instructions also. So rename to instr_opcode().

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 arch/powerpc/lib/code-patching.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 17e5b23..2bc9db3 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -72,19 +72,19 @@ unsigned int create_cond_branch(const unsigned int *addr,
 	return instruction;
 }
 
-static unsigned int branch_opcode(unsigned int instr)
+static unsigned int instr_opcode(unsigned int instr)
 {
 	return (instr >> 26) & 0x3F;
 }
 
 static int instr_is_branch_iform(unsigned int instr)
 {
-	return branch_opcode(instr) == 18;
+	return instr_opcode(instr) == 18;
 }
 
 static int instr_is_branch_bform(unsigned int instr)
 {
-	return branch_opcode(instr) == 16;
+	return instr_opcode(instr) == 16;
 }
 
 int instr_is_relative_branch(unsigned int instr)
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 5/8][v4] powerpc/perf: Export Power8 memory hierarchy info to user space.
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

On Power8, the LDST field in SIER identifies the memory hierarchy level
(eg: L1, L2 etc), from which a data-cache miss for a marked instruction
was satisfied.

Use the 'perf_mem_data_src' object to export this hierarchy level to user
space. Fortunately, the memory hierarchy levels in Power8 map fairly easily
into the arch-neutral levels as described by the ldst_src_map[] table.

Usage:

	perf record -d -e 'cpu/PM_MRK_GRP_CMPL/' <application>
	perf report -n --mem-mode --sort=mem,sym,dso,symbol_daddr,dso_daddr"

		For samples involving load/store instructions, the memory
		hierarchy level is shown as "L1 hit", "Remote RAM hit" etc.
	# or

	perf record --data <application>
	perf report -D

		Sample records contain a 'data_src' field which encodes the
		memory hierarchy level: Eg: data_src 0x442 indicates
		MEM_OP_LOAD, MEM_LVL_HIT, MEM_LVL_L2 (i.e load hit L2).

Note that the PMU event PM_MRK_GRP_CMPL tracks all marked group completions
events. While some of these are loads and stores, others like 'add'
instructions may also be sampled. One alternative of sampling on
PM_MRK_GRP_CMPL and throwing away non-loads and non-store samples could
yield an inconsistent profile of the application.

As the precise semantics of 'perf mem -t load' or 'perf mem -t store' (which
require sampling only loads or only stores) cannot be implemented on Power,
we don't implement 'perf mem' on Power for now.

Thanks to input from Stephane Eranian, Michael Ellerman and Michael Neuling.

Cc: Stephane Eranian <eranian@google.com>
Cc: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog[v4]:
	Drop support for 'perf mem' for Power (use perf-record and perf-report
	directly)

 arch/powerpc/include/asm/perf_event_server.h |    2 +
 arch/powerpc/perf/core-book3s.c              |   11 ++++++
 arch/powerpc/perf/power8-pmu.c               |   53 ++++++++++++++++++++++++++
 3 files changed, 66 insertions(+)

diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index cc5f45b..2252798 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -37,6 +37,8 @@ struct power_pmu {
 	void            (*config_bhrb)(u64 pmu_bhrb_filter);
 	void		(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
 	int		(*limited_pmc_event)(u64 event_id);
+	void		(*get_mem_data_src)(union perf_mem_data_src *dsrc,
+				struct pt_regs *regs);
 	u32		flags;
 	const struct attribute_group	**attr_groups;
 	int		n_generic;
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index a3985ae..e61fd05 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1693,6 +1693,13 @@ ssize_t power_events_sysfs_show(struct device *dev,
 	return sprintf(page, "event=0x%02llx\n", pmu_attr->id);
 }
 
+static inline void power_get_mem_data_src(union perf_mem_data_src *dsrc,
+				struct pt_regs *regs)
+{
+	if  (ppmu->get_mem_data_src)
+		ppmu->get_mem_data_src(dsrc, regs);
+}
+
 struct pmu power_pmu = {
 	.pmu_enable	= power_pmu_enable,
 	.pmu_disable	= power_pmu_disable,
@@ -1774,6 +1781,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
 			data.br_stack = &cpuhw->bhrb_stack;
 		}
 
+		if (event->attr.sample_type & PERF_SAMPLE_DATA_SRC &&
+						ppmu->get_mem_data_src)
+			ppmu->get_mem_data_src(&data.data_src, regs);
+
 		if (perf_event_overflow(event, &data, regs))
 			power_pmu_stop(event, 0);
 	}
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 5c61e59..4ecf903 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -537,6 +537,58 @@ static struct attribute_group power8_pmu_events_group = {
 	.attrs = power8_events_attr,
 };
 
+#define POWER8_SIER_TYPE_SHIFT	15
+#define POWER8_SIER_TYPE_MASK	(0x7LL << POWER8_SIER_TYPE_SHIFT)
+
+#define POWER8_SIER_LDST_SHIFT	1
+#define POWER8_SIER_LDST_MASK	(0x7LL << POWER8_SIER_LDST_SHIFT)
+
+#define P(a, b)			PERF_MEM_S(a, b)
+#define PLH(a, b)		(P(OP, LOAD) | P(LVL, HIT) | P(a, b))
+#define PSM(a, b)		(P(OP, STORE) | P(LVL, MISS) | P(a, b))
+
+/*
+ * Power8 interpretations:
+ * REM_CCE1: 1-hop indicates L2/L3 cache of a different core on same chip
+ * REM_CCE2: 2-hop indicates different chip or different node.
+ */
+static u64 ldst_src_map[] = {
+	/* 000 */	P(LVL, NA),
+
+	/* 001 */	PLH(LVL, L1),
+	/* 010 */	PLH(LVL, L2),
+	/* 011 */	PLH(LVL, L3),
+	/* 100 */	PLH(LVL, LOC_RAM),
+	/* 101 */	PLH(LVL, REM_CCE1),
+	/* 110 */	PLH(LVL, REM_CCE2),
+
+	/* 111 */	PSM(LVL, L1),
+};
+
+static inline bool is_load_store_inst(u64 sier)
+{
+	u64 val;
+	val = (sier & POWER8_SIER_TYPE_MASK) >> POWER8_SIER_TYPE_SHIFT;
+
+	/* 1 = load, 2 = store */
+	return val == 1 || val == 2;
+}
+
+static void power8_get_mem_data_src(union perf_mem_data_src *dsrc,
+			struct pt_regs *regs)
+{
+	u64 idx;
+	u64 sier;
+
+	sier = mfspr(SPRN_SIER);
+
+	if (is_load_store_inst(sier)) {
+		idx = (sier & POWER8_SIER_LDST_MASK) >> POWER8_SIER_LDST_SHIFT;
+
+		dsrc->val |= ldst_src_map[idx];
+	}
+}
+
 PMU_FORMAT_ATTR(event,		"config:0-49");
 PMU_FORMAT_ATTR(pmcxsel,	"config:0-7");
 PMU_FORMAT_ATTR(mark,		"config:8");
@@ -640,6 +692,7 @@ static struct power_pmu power8_pmu = {
 	.get_constraint		= power8_get_constraint,
 	.get_alternatives	= power8_get_alternatives,
 	.disable_pmc		= power8_disable_pmc,
+	.get_mem_data_src	= power8_get_mem_data_src,
 	.flags			= PPMU_HAS_SSLOT | PPMU_HAS_SIER | PPMU_BHRB | PPMU_EBB,
 	.n_generic		= ARRAY_SIZE(power8_generic_events),
 	.generic_events		= power8_generic_events,
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 4/8][v4] powerpc/perf: Define big-endian version of perf_mem_data_src
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

perf_mem_data_src is an union that is initialized via the ->val field
and accessed via the bitmap fields. For this to work on big endian
platforms, we also need a big-endian represenation of perf_mem_data_src.

Cc: Stephane Eranian <eranian@google.com>
Cc: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog [v2]:
	- [Vince Weaver, Michael Ellerman] No __KERNEL__ in uapi headers.

 include/uapi/linux/perf_event.h |   58 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 62c25a2..7a4f9bb 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -19,6 +19,50 @@
 #include <asm/byteorder.h>
 
 /*
+ * Kernel and userspace check for endianness in incompatible ways.
+ * In user space, <endian.h> defines both __BIG_ENDIAN and __LITTLE_ENDIAN
+ * but sets __BYTE_ORDER to one or the other. So user space uses checks are:
+ *
+ *	#if __BYTE_ORDER == __LITTLE_ENDIAN
+ *
+ * In the kernel, __BYTE_ORDER is undefined, so using the above check doesn't
+ * work. Further, kernel code assumes that exactly one of __BIG_ENDIAN and
+ * __LITTLE_ENDIAN is defined.  So the kernel checks are like:
+ *
+ *	#if defined(__LITTLE_ENDIAN)
+ *
+ * But we can't use that check in user space since __LITTLE_ENDIAN (and
+ * __BIG_ENDIAN) are always defined.
+ *
+ * Since some perf data structures depend on endianness _and_ are shared
+ * between kernel and user, perf needs its own notion of endian macros (at
+ * least until user and kernel endian checks converge).
+ */
+#define __PERF_LE	1234
+#define __PERF_BE	4321
+
+#if defined(__BYTE_ORDER)
+
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define __PERF_BYTE_ORDER	__PERF_LE
+#elif __BYTE_ORDER == __BIG_ENDIAN
+#define __PERF_BYTE_ORDER	__PERF_BE
+#endif
+
+#else /* __BYTE_ORDER */
+
+#if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)
+#error "Cannot determine endianness"
+#elif defined(__LITTLE_ENDIAN)
+#define __PERF_BYTE_ORDER	__PERF_LE
+#elif defined(__BIG_ENDIAN)
+#define __PERF_BYTE_ORDER	__PERF_BE
+#endif
+
+
+#endif /* __BYTE_ORDER */
+
+/*
  * User-space ABI bits:
  */
 
@@ -659,6 +703,7 @@ enum perf_callchain_context {
 #define PERF_FLAG_FD_OUTPUT		(1U << 1)
 #define PERF_FLAG_PID_CGROUP		(1U << 2) /* pid=cgroup id, per-cpu mode only */
 
+#if __PERF_BYTE_ORDER == __PERF_LE
 union perf_mem_data_src {
 	__u64 val;
 	struct {
@@ -670,6 +715,19 @@ union perf_mem_data_src {
 			mem_rsvd:31;
 	};
 };
+#elif __PERF_BYTE_ORDER == __PERF_BE
+union perf_mem_data_src {
+	__u64 val;
+	struct {
+		__u64	mem_rsvd:31,
+			mem_dtlb:7,	/* tlb access */
+			mem_lock:2,	/* lock instr */
+			mem_snoop:5,	/* snoop mode */
+			mem_lvl:14,	/* memory hierarchy level */
+			mem_op:5;	/* type of opcode */
+	};
+};
+#endif
 
 /* type of opcode (load/store/prefetch,code) */
 #define PERF_MEM_OP_NA		0x01 /* not available */
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 2/8][v4] powerpc/perf: Export Power8 generic events in sysfs
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

Export generic perf events for Power8 in sysfs.

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 arch/powerpc/perf/power8-pmu.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 30c6b12..ff98fb8 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -510,6 +510,28 @@ static void power8_disable_pmc(unsigned int pmc, unsigned long mmcr[])
 		mmcr[1] &= ~(0xffUL << MMCR1_PMCSEL_SHIFT(pmc + 1));
 }
 
+GENERIC_EVENT_ATTR(cpu-cyles,			PM_CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-frontend,	PM_GCT_NOSLOT_CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-backend,	PM_CMPLU_STALL);
+GENERIC_EVENT_ATTR(instructions,		PM_INST_CMPL);
+GENERIC_EVENT_ATTR(branch-instructions,		PM_BRU_FIN);
+GENERIC_EVENT_ATTR(branch-misses,		PM_BR_MPRED_CMPL);
+
+static struct attribute *power8_events_attr[] = {
+	GENERIC_EVENT_PTR(PM_CYC),
+	GENERIC_EVENT_PTR(PM_GCT_NOSLOT_CYC),
+	GENERIC_EVENT_PTR(PM_CMPLU_STALL),
+	GENERIC_EVENT_PTR(PM_INST_CMPL),
+	GENERIC_EVENT_PTR(PM_BRU_FIN),
+	GENERIC_EVENT_PTR(PM_BR_MPRED_CMPL),
+	NULL
+};
+
+static struct attribute_group power8_pmu_events_group = {
+	.name = "events",
+	.attrs = power8_events_attr,
+};
+
 PMU_FORMAT_ATTR(event,		"config:0-49");
 PMU_FORMAT_ATTR(pmcxsel,	"config:0-7");
 PMU_FORMAT_ATTR(mark,		"config:8");
@@ -546,6 +568,7 @@ struct attribute_group power8_pmu_format_group = {
 
 static const struct attribute_group *power8_pmu_attr_groups[] = {
 	&power8_pmu_format_group,
+	&power8_pmu_events_group,
 	NULL,
 };
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 3/8][v4] powerpc/perf: Add PM_MRK_GRP_CMPL event to sysfs.
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

The perf event PM_MRK_GRP_CMPL is useful in analyzing memory hierarchy
of applications.

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 arch/powerpc/perf/power8-pmu.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index ff98fb8..5c61e59 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -24,6 +24,7 @@
 #define PME_PM_INST_CMPL			0x00002
 #define PME_PM_BRU_FIN				0x10068
 #define PME_PM_BR_MPRED_CMPL			0x400f6
+#define PME_PM_MRK_GRP_CMPL			0x40130
 
 
 /*
@@ -517,6 +518,8 @@ GENERIC_EVENT_ATTR(instructions,		PM_INST_CMPL);
 GENERIC_EVENT_ATTR(branch-instructions,		PM_BRU_FIN);
 GENERIC_EVENT_ATTR(branch-misses,		PM_BR_MPRED_CMPL);
 
+POWER_EVENT_ATTR(PM_MRK_GRP_CMPL,		PM_MRK_GRP_CMPL);
+
 static struct attribute *power8_events_attr[] = {
 	GENERIC_EVENT_PTR(PM_CYC),
 	GENERIC_EVENT_PTR(PM_GCT_NOSLOT_CYC),
@@ -524,6 +527,8 @@ static struct attribute *power8_events_attr[] = {
 	GENERIC_EVENT_PTR(PM_INST_CMPL),
 	GENERIC_EVENT_PTR(PM_BRU_FIN),
 	GENERIC_EVENT_PTR(PM_BR_MPRED_CMPL),
+
+	POWER_EVENT_PTR(PM_MRK_GRP_CMPL),
 	NULL
 };
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 1/8][v4] powerpc/perf: Rename Power8 macros to start with PME
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual
In-Reply-To: <1379119755-21025-1-git-send-email-sukadev@linux.vnet.ibm.com>

We use helpers like GENERIC_EVENT_ATTR() to list the generic events in
sysfs. To avoid name collisions, GENERIC_EVENT_ATTR() requires the perf
event macros to start with PME.

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 arch/powerpc/perf/power8-pmu.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 96a64d6..30c6b12 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -18,12 +18,12 @@
 /*
  * Some power8 event codes.
  */
-#define PM_CYC				0x0001e
-#define PM_GCT_NOSLOT_CYC		0x100f8
-#define PM_CMPLU_STALL			0x4000a
-#define PM_INST_CMPL			0x00002
-#define PM_BRU_FIN			0x10068
-#define PM_BR_MPRED_CMPL		0x400f6
+#define PME_PM_CYC				0x0001e
+#define PME_PM_GCT_NOSLOT_CYC			0x100f8
+#define PME_PM_CMPLU_STALL			0x4000a
+#define PME_PM_INST_CMPL			0x00002
+#define PME_PM_BRU_FIN				0x10068
+#define PME_PM_BR_MPRED_CMPL			0x400f6
 
 
 /*
@@ -550,12 +550,12 @@ static const struct attribute_group *power8_pmu_attr_groups[] = {
 };
 
 static int power8_generic_events[] = {
-	[PERF_COUNT_HW_CPU_CYCLES] =			PM_CYC,
-	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] =	PM_GCT_NOSLOT_CYC,
-	[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =	PM_CMPLU_STALL,
-	[PERF_COUNT_HW_INSTRUCTIONS] =			PM_INST_CMPL,
-	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS] =		PM_BRU_FIN,
-	[PERF_COUNT_HW_BRANCH_MISSES] =			PM_BR_MPRED_CMPL,
+	[PERF_COUNT_HW_CPU_CYCLES] =			PME_PM_CYC,
+	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] =	PME_PM_GCT_NOSLOT_CYC,
+	[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =	PME_PM_CMPLU_STALL,
+	[PERF_COUNT_HW_INSTRUCTIONS] =			PME_PM_INST_CMPL,
+	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS] =		PME_PM_BRU_FIN,
+	[PERF_COUNT_HW_BRANCH_MISSES] =			PME_PM_BR_MPRED_CMPL,
 };
 
 static u64 power8_bhrb_filter_map(u64 branch_sample_type)
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 0/8][v4] powerpc/perf: Export memory hierarchy level in Power7/8.
From: Sukadev Bhattiprolu @ 2013-09-14  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: linuxppc-dev, Paul Mackerras, Michael Ellerman, Stephane Eranian,
	Anshuman Khandual

Power7 and Power8 processors save the memory hierarchy level (eg: L2, L3)
from which a load or store instruction was satisfied. Export this hierarchy
information to the user via the perf_mem_data_src object.

Thanks to input from Stephane Eranian, Michael Ellerman, Michael Neuling.

Sukadev Bhattiprolu (8):
  powerpc/perf: Rename Power8 macros to start with PME
  powerpc/perf: Export Power8 generic events in sysfs
  powerpc/perf: Add PM_MRK_GRP_CMPL event to sysfs.
  powerpc/perf: Define big-endian version of perf_mem_data_src
  powerpc/perf: Export Power8 memory hierarchy info to user space.
  powerpc: Rename branch_opcode() to instr_opcode()
  power: implement is_instr_load_store().
  powerpc/perf: Export Power7 memory hierarchy info to user space.

 arch/powerpc/include/asm/code-patching.h     |    1 +
 arch/powerpc/include/asm/perf_event_server.h |    2 +
 arch/powerpc/lib/code-patching.c             |   96 ++++++++++++++++++++++-
 arch/powerpc/perf/core-book3s.c              |   11 +++
 arch/powerpc/perf/power7-pmu.c               |   94 +++++++++++++++++++++++
 arch/powerpc/perf/power8-pmu.c               |  105 +++++++++++++++++++++++---
 include/uapi/linux/perf_event.h              |   58 ++++++++++++++
 7 files changed, 352 insertions(+), 15 deletions(-)

-- 
1.7.9.5

^ permalink raw reply

* Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
From: Kumar Gala @ 2013-09-13 14:53 UTC (permalink / raw)
  To: Valentin Longchamp
  Cc: Poonam Aggrwal, Priyanka Jain, scottwood, Varun Sethi,
	linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <5232D778.20007@keymile.com>


On Sep 13, 2013, at 4:14 AM, Valentin Longchamp wrote:

> On 09/11/2013 08:58 AM, Prabhakar Kushwaha wrote:
>> The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 =
PA
>> processor cores with high-performance data path acceleration =
architecture
>> and network peripheral interfaces required for networking & =
telecommunications.
>>=20
>> T1042 personality is a reduced personality of T1040 without =
Integrated 8-port
>> Gigabit Ethernet switch.
>>=20
>> The T1040/T1042 SoC includes the following function and features:
>>=20
>> - Four e5500 cores, each with a private 256 KB L2 cache
>> - 256 KB shared L3 CoreNet platform cache (CPC)
>> - Interconnect CoreNet platform
>> - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and =
interleaving
>>   support
>> - Data Path Acceleration Architecture (DPAA) incorporating =
acceleration
>> for the following functions:
>>    -  Packet parsing, classification, and distribution
>>    -  Queue management for scheduling, packet sequencing, and =
congestion
>>    	management
>>    -  Cryptography Acceleration (SEC 5.0)
>>    - RegEx Pattern Matching Acceleration (PME 2.2)
>>    - IEEE Std 1588 support
>>    - Hardware buffer management for buffer allocation and =
deallocation
>> - Ethernet interfaces
>>    - Integrated 8-port Gigabit Ethernet switch (T1040 only)
>>    - Four 1 Gbps Ethernet controllers
>> - Two RGMII interfaces or one RGMII and one MII interfaces
>> - High speed peripheral interfaces
>>   - Four PCI Express 2.0 controllers running at up to 5 GHz
>>   - Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
>>   - Upto two QSGMII interface
>>   - Upto six SGMII interface supporting 1000 Mbps
>>   - One SGMII interface supporting upto 2500 Mbps
>> - Additional peripheral interfaces
>>   - Two USB 2.0 controllers with integrated PHY
>>   - SD/eSDHC/eMMC
>>   -  eSPI controller
>>   - Four I2C controllers
>>   - Four UARTs
>>   - Four GPIO controllers
>>   - Integrated flash controller (IFC)
>>   - Change this to  LCD/ HDMI interface (DIU) with 12 bit dual data =
rate
>>   - TDM interface
>> - Multicore programmable interrupt controller (PIC)
>> - Two 8-channel DMA engines
>> - Single source clocking implementation
>> - Deep Sleep power implementaion (wakeup from =
GPIO/Timer/Ethernet/USB)
>>=20
>> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
>> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
>> ---
>> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>>=20
>> TODO: Add noded for ethernet
>>=20
>> arch/powerpc/boot/dts/fsl/t1040si-post.dtsi |  116 ++++++++
>> arch/powerpc/boot/dts/fsl/t1042si-post.dtsi |  430 =
+++++++++++++++++++++++++++
>> arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi  |  111 +++++++
>> 3 files changed, 657 insertions(+)
>> create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
>> create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
>> create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
>>=20
>=20
> I am currently working on a design bases on the p2041 but my issue =
seems to be
> generic to all the QorIQ dtsi files since the structure is exactly the =
same, so
> I pick the opportunity that such a file is submitted to the =
mailing-list to
> raise it.
>=20
> DISCLAIMER: I am no DTS expert, so there may be a way to achieve what =
I want to
> I have not seen.
>=20
> My understanding is that the SOC-NAMEsi-post.dtsi and =
SOC-NAMEsi-pre.dtsi are
> files that describe the SoC internals. They will be maintained when =
new drivers
> are merged or changed and therefore they should be used by all boards =
using the
> SoCs. Can someone confirm this or am I already wrong (since there are =
on
> Freescale boards that use them in mainline) ?

That is the intent. of the SOC*.dtsi files. =20

>=20
> [snip]
>=20
>> +
>> +&pci0 {
>> +	compatible =3D "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", =
"fsl,qoriq-pcie";
>> +	device_type =3D "pci";
>> +	#size-cells =3D <2>;
>> +	#address-cells =3D <3>;
>> +	bus-range =3D <0x0 0xff>;
>> +	interrupts =3D <20 2 0 0>;
>> +	fsl,iommu-parent =3D <&pamu0>;
>> +	pcie@0 {
>> +		reg =3D <0 0 0 0 0>;
>> +		#interrupt-cells =3D <1>;
>> +		#size-cells =3D <2>;
>> +		#address-cells =3D <3>;
>> +		device_type =3D "pci";
>> +		interrupts =3D <20 2 0 0>;
>> +		interrupt-map-mask =3D <0xf800 0 0 7>;
>> +		interrupt-map =3D <
>> +			/* IDSEL 0x0 */
>> +			0000 0 0 1 &mpic 40 1 0 0
>> +			0000 0 0 2 &mpic 1 1 0 0
>> +			0000 0 0 3 &mpic 2 1 0 0
>> +			0000 0 0 4 &mpic 3 1 0 0
>> +			>;
>> +	};
>> +};
>> +
>> +&pci1 {
>> +	compatible =3D "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", =
"fsl,qoriq-pcie";
>> +	device_type =3D "pci";
>> +	#size-cells =3D <2>;
>> +	#address-cells =3D <3>;
>> +	bus-range =3D <0 0xff>;
>> +	interrupts =3D <21 2 0 0>;
>> +	fsl,iommu-parent =3D <&pamu0>;
>> +	pcie@0 {
>> +		reg =3D <0 0 0 0 0>;
>> +		#interrupt-cells =3D <1>;
>> +		#size-cells =3D <2>;
>> +		#address-cells =3D <3>;
>> +		device_type =3D "pci";
>> +		interrupts =3D <21 2 0 0>;
>> +		interrupt-map-mask =3D <0xf800 0 0 7>;
>> +		interrupt-map =3D <
>> +			/* IDSEL 0x0 */
>> +			0000 0 0 1 &mpic 41 1 0 0
>> +			0000 0 0 2 &mpic 5 1 0 0
>> +			0000 0 0 3 &mpic 6 1 0 0
>> +			0000 0 0 4 &mpic 7 1 0 0
>> +			>;
>> +	};
>> +};
>> +
>> +&pci2 {
>> +	compatible =3D "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", =
"fsl,qoriq-pcie";
>> +	device_type =3D "pci";
>> +	#size-cells =3D <2>;
>> +	#address-cells =3D <3>;
>> +	bus-range =3D <0x0 0xff>;
>> +	interrupts =3D <22 2 0 0>;
>> +	fsl,iommu-parent =3D <&pamu0>;
>> +	pcie@0 {
>> +		reg =3D <0 0 0 0 0>;
>> +		#interrupt-cells =3D <1>;
>> +		#size-cells =3D <2>;
>> +		#address-cells =3D <3>;
>> +		device_type =3D "pci";
>> +		interrupts =3D <22 2 0 0>;
>> +		interrupt-map-mask =3D <0xf800 0 0 7>;
>> +		interrupt-map =3D <
>> +			/* IDSEL 0x0 */
>> +			0000 0 0 1 &mpic 42 1 0 0
>> +			0000 0 0 2 &mpic 9 1 0 0
>> +			0000 0 0 3 &mpic 10 1 0 0
>> +			0000 0 0 4 &mpic 11 1 0 0
>> +			>;
>> +	};
>> +};
>> +
>> +&pci3 {
>> +	compatible =3D "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", =
"fsl,qoriq-pcie";
>> +	device_type =3D "pci";
>> +	#size-cells =3D <2>;
>> +	#address-cells =3D <3>;
>> +	bus-range =3D <0x0 0xff>;
>> +	interrupts =3D <23 2 0 0>;
>> +	fsl,iommu-parent =3D <&pamu0>;
>> +	pcie@0 {
>> +		reg =3D <0 0 0 0 0>;
>> +		#interrupt-cells =3D <1>;
>> +		#size-cells =3D <2>;
>> +		#address-cells =3D <3>;
>> +		device_type =3D "pci";
>> +		interrupts =3D <23 2 0 0>;
>> +		interrupt-map-mask =3D <0xf800 0 0 7>;
>> +		interrupt-map =3D <
>> +			/* IDSEL 0x0 */
>> +			0000 0 0 1 &mpic 43 1 0 0
>> +			0000 0 0 2 &mpic 0 1 0 0
>> +			0000 0 0 3 &mpic 4 1 0 0
>> +			0000 0 0 4 &mpic 8 1 0 0
>> +			>;
>> +	};
>> +};
>> +
>=20
> The above 4 nodes have the consequence that it will then be mandatory =
that a
> board support .dts file that would like to inlcude the =
SOC-NAMEsi-post.dtsi
> defines the pci0, pci1, pci2, pci3 aliases.
>=20
> Now it is possible that a board does not implement pci1 for instance. =
So its
> .dts file would ideally not define a node for it, and thus not define =
the
> respective alias. However, this triggers this dtc compile error (which =
is correct):
>=20
>> [chlongv1@chber1-10533x linux-km]$ make kmp204x.dtb
>>  DTC     arch/powerpc/boot/kmp204x.dtb
>> Error: arch/powerpc/boot/dts/fsl/p2041si-post.dtsi:98.2-3 label or =
path, 'pci1', not found
>> FATAL ERROR: Syntax error parsing input tree
>> make[1]: *** [arch/powerpc/boot/kmp204x.dtb] Error 1
>> make: *** [kmp204x.dtb] Error 2
>=20
> The solution I have found is to define a "dummy" disabled node so that =
I can
> define the alias, but I am not really happy about this:
>=20
>> 	pci1: pcie@ffe201000 {
>> 		status =3D "disabled";
>> 	};
>=20
> I am here missing something obvious or shouldn't it be possible that =
such .dtsi
> files allow not to define unused/unnecessary nodes ?

Isn't this correct, that you are disabling the PCIe1 interface on the =
SoC for your board?

- k=

^ permalink raw reply

* Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
From: Valentin Longchamp @ 2013-09-13  9:14 UTC (permalink / raw)
  To: Prabhakar Kushwaha, linuxppc-dev, scottwood
  Cc: Priyanka Jain, Poonam Aggrwal, Varun Sethi
In-Reply-To: <1378882686-19454-1-git-send-email-prabhakar@freescale.com>

On 09/11/2013 08:58 AM, Prabhakar Kushwaha wrote:
> The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
> processor cores with high-performance data path acceleration architecture
> and network peripheral interfaces required for networking & telecommunications.
> 
> T1042 personality is a reduced personality of T1040 without Integrated 8-port
> Gigabit Ethernet switch.
> 
> The T1040/T1042 SoC includes the following function and features:
> 
>  - Four e5500 cores, each with a private 256 KB L2 cache
>  - 256 KB shared L3 CoreNet platform cache (CPC)
>  - Interconnect CoreNet platform
>  - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
>    support
>  - Data Path Acceleration Architecture (DPAA) incorporating acceleration
>  for the following functions:
>     -  Packet parsing, classification, and distribution
>     -  Queue management for scheduling, packet sequencing, and congestion
>     	management
>     -  Cryptography Acceleration (SEC 5.0)
>     - RegEx Pattern Matching Acceleration (PME 2.2)
>     - IEEE Std 1588 support
>     - Hardware buffer management for buffer allocation and deallocation
>  - Ethernet interfaces
>     - Integrated 8-port Gigabit Ethernet switch (T1040 only)
>     - Four 1 Gbps Ethernet controllers
>  - Two RGMII interfaces or one RGMII and one MII interfaces
>  - High speed peripheral interfaces
>    - Four PCI Express 2.0 controllers running at up to 5 GHz
>    - Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
>    - Upto two QSGMII interface
>    - Upto six SGMII interface supporting 1000 Mbps
>    - One SGMII interface supporting upto 2500 Mbps
>  - Additional peripheral interfaces
>    - Two USB 2.0 controllers with integrated PHY
>    - SD/eSDHC/eMMC
>    -  eSPI controller
>    - Four I2C controllers
>    - Four UARTs
>    - Four GPIO controllers
>    - Integrated flash controller (IFC)
>    - Change this to  LCD/ HDMI interface (DIU) with 12 bit dual data rate
>    - TDM interface
>  - Multicore programmable interrupt controller (PIC)
>  - Two 8-channel DMA engines
>  - Single source clocking implementation
>  - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
> 
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
> 
> TODO: Add noded for ethernet
> 
>  arch/powerpc/boot/dts/fsl/t1040si-post.dtsi |  116 ++++++++
>  arch/powerpc/boot/dts/fsl/t1042si-post.dtsi |  430 +++++++++++++++++++++++++++
>  arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi  |  111 +++++++
>  3 files changed, 657 insertions(+)
>  create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
>  create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
>  create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
> 

I am currently working on a design bases on the p2041 but my issue seems to be
generic to all the QorIQ dtsi files since the structure is exactly the same, so
I pick the opportunity that such a file is submitted to the mailing-list to
raise it.

DISCLAIMER: I am no DTS expert, so there may be a way to achieve what I want to
I have not seen.

My understanding is that the SOC-NAMEsi-post.dtsi and SOC-NAMEsi-pre.dtsi are
files that describe the SoC internals. They will be maintained when new drivers
are merged or changed and therefore they should be used by all boards using the
SoCs. Can someone confirm this or am I already wrong (since there are on
Freescale boards that use them in mainline) ?

[snip]

> +
> +&pci0 {
> +	compatible = "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
> +	device_type = "pci";
> +	#size-cells = <2>;
> +	#address-cells = <3>;
> +	bus-range = <0x0 0xff>;
> +	interrupts = <20 2 0 0>;
> +	fsl,iommu-parent = <&pamu0>;
> +	pcie@0 {
> +		reg = <0 0 0 0 0>;
> +		#interrupt-cells = <1>;
> +		#size-cells = <2>;
> +		#address-cells = <3>;
> +		device_type = "pci";
> +		interrupts = <20 2 0 0>;
> +		interrupt-map-mask = <0xf800 0 0 7>;
> +		interrupt-map = <
> +			/* IDSEL 0x0 */
> +			0000 0 0 1 &mpic 40 1 0 0
> +			0000 0 0 2 &mpic 1 1 0 0
> +			0000 0 0 3 &mpic 2 1 0 0
> +			0000 0 0 4 &mpic 3 1 0 0
> +			>;
> +	};
> +};
> +
> +&pci1 {
> +	compatible = "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
> +	device_type = "pci";
> +	#size-cells = <2>;
> +	#address-cells = <3>;
> +	bus-range = <0 0xff>;
> +	interrupts = <21 2 0 0>;
> +	fsl,iommu-parent = <&pamu0>;
> +	pcie@0 {
> +		reg = <0 0 0 0 0>;
> +		#interrupt-cells = <1>;
> +		#size-cells = <2>;
> +		#address-cells = <3>;
> +		device_type = "pci";
> +		interrupts = <21 2 0 0>;
> +		interrupt-map-mask = <0xf800 0 0 7>;
> +		interrupt-map = <
> +			/* IDSEL 0x0 */
> +			0000 0 0 1 &mpic 41 1 0 0
> +			0000 0 0 2 &mpic 5 1 0 0
> +			0000 0 0 3 &mpic 6 1 0 0
> +			0000 0 0 4 &mpic 7 1 0 0
> +			>;
> +	};
> +};
> +
> +&pci2 {
> +	compatible = "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
> +	device_type = "pci";
> +	#size-cells = <2>;
> +	#address-cells = <3>;
> +	bus-range = <0x0 0xff>;
> +	interrupts = <22 2 0 0>;
> +	fsl,iommu-parent = <&pamu0>;
> +	pcie@0 {
> +		reg = <0 0 0 0 0>;
> +		#interrupt-cells = <1>;
> +		#size-cells = <2>;
> +		#address-cells = <3>;
> +		device_type = "pci";
> +		interrupts = <22 2 0 0>;
> +		interrupt-map-mask = <0xf800 0 0 7>;
> +		interrupt-map = <
> +			/* IDSEL 0x0 */
> +			0000 0 0 1 &mpic 42 1 0 0
> +			0000 0 0 2 &mpic 9 1 0 0
> +			0000 0 0 3 &mpic 10 1 0 0
> +			0000 0 0 4 &mpic 11 1 0 0
> +			>;
> +	};
> +};
> +
> +&pci3 {
> +	compatible = "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
> +	device_type = "pci";
> +	#size-cells = <2>;
> +	#address-cells = <3>;
> +	bus-range = <0x0 0xff>;
> +	interrupts = <23 2 0 0>;
> +	fsl,iommu-parent = <&pamu0>;
> +	pcie@0 {
> +		reg = <0 0 0 0 0>;
> +		#interrupt-cells = <1>;
> +		#size-cells = <2>;
> +		#address-cells = <3>;
> +		device_type = "pci";
> +		interrupts = <23 2 0 0>;
> +		interrupt-map-mask = <0xf800 0 0 7>;
> +		interrupt-map = <
> +			/* IDSEL 0x0 */
> +			0000 0 0 1 &mpic 43 1 0 0
> +			0000 0 0 2 &mpic 0 1 0 0
> +			0000 0 0 3 &mpic 4 1 0 0
> +			0000 0 0 4 &mpic 8 1 0 0
> +			>;
> +	};
> +};
> +

The above 4 nodes have the consequence that it will then be mandatory that a
board support .dts file that would like to inlcude the SOC-NAMEsi-post.dtsi
defines the pci0, pci1, pci2, pci3 aliases.

Now it is possible that a board does not implement pci1 for instance. So its
.dts file would ideally not define a node for it, and thus not define the
respective alias. However, this triggers this dtc compile error (which is correct):

> [chlongv1@chber1-10533x linux-km]$ make kmp204x.dtb
>   DTC     arch/powerpc/boot/kmp204x.dtb
> Error: arch/powerpc/boot/dts/fsl/p2041si-post.dtsi:98.2-3 label or path, 'pci1', not found
> FATAL ERROR: Syntax error parsing input tree
> make[1]: *** [arch/powerpc/boot/kmp204x.dtb] Error 1
> make: *** [kmp204x.dtb] Error 2

The solution I have found is to define a "dummy" disabled node so that I can
define the alias, but I am not really happy about this:

> 	pci1: pcie@ffe201000 {
> 		status = "disabled";
> 	};

I am here missing something obvious or shouldn't it be possible that such .dtsi
files allow not to define unused/unnecessary nodes ?

Valentin

^ permalink raw reply

* RE: [PATCH 1/2] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Kushwaha Prabhakar-B32579 @ 2013-09-13  7:35 UTC (permalink / raw)
  To: Wood Scott-B07421
  Cc: Jain Priyanka-B32167, Aggrwal Poonam-B10812,
	linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1378942885.12204.448.camel@snotra.buserror.net>

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMiwgMjAxMyA1OjExIEFNDQo+IFRvOiBL
dXNod2FoYSBQcmFiaGFrYXItQjMyNTc5DQo+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJz
Lm9yZzsgZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsgSmFpbg0KPiBQcml5YW5rYS1CMzIxNjc7
IEFnZ3J3YWwgUG9vbmFtLUIxMDgxMg0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDEvMl0gcG93ZXJw
Yy9mc2wtYm9va2U6IEFkZCBpbml0aWFsIFQxMDR4X1FEUyBib2FyZA0KPiBzdXBwb3J0DQo+IA0K
PiBPbiBXZWQsIDIwMTMtMDktMTEgYXQgMTI6MjggKzA1MzAsIFByYWJoYWthciBLdXNod2FoYSB3
cm90ZToNCj4gPiAgQWRkIHN1cHBvcnQgZm9yIFQxMDR4IGJvYXJkIGluIGJvYXJkIGZpbGUgdDEw
NHhfcWRzLmMsIEl0IGlzIGNvbW1vbg0KPiA+IGZvciAgYm90aCBUMTA0MCBhbmQgVDEwNDIgYXMg
dGhleSBzaGFyZSBzYW1lIFFEUyBib2FyZC4NCj4gPg0KPiA+ICBUMTA0MFFEUyBib2FyZCBPdmVy
dmlldw0KPiA+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICAtIFNFUkRFUyBDb25uZWN0
aW9ucywgOCBsYW5lcyBzdXBwb3J0aW5nOg0KPiA+ICAgICAgIOKAlCBQQ0kgRXhwcmVzczogc3Vw
cG9ydGluZyBHZW4gMSBhbmQgR2VuIDI7DQo+ID4gICAgICAg4oCUIFNHTUlJDQo+ID4gICAgICAg
4oCUIFFTR01JSQ0KPiA+ICAgICAgIOKAlCBTQVRBIDIuMA0KPiA+ICAgICAgIOKAlCBBdXJvcmEg
ZGVidWcgd2l0aCBkZWRpY2F0ZWQgY29ubmVjdG9ycyAoVDEwNDAgb25seSkNCj4gPiAgLSBERFIg
Q29udHJvbGxlcg0KPiA+ICAgICAgLSBTdXBwb3J0cyByYXRlcyBvZiB1cCB0byAxNjAwIE1IeiBk
YXRhLXJhdGUNCj4gPiAgICAgIC0gU3VwcG9ydHMgb25lIEREUjNMUCBVRElNTS9SRElNTXMsIG9m
IHNpbmdsZS0sIGR1YWwtIG9yIHF1YWQtcmFuaw0KPiB0eXBlcy4NCj4gPiAgLUlGQy9Mb2NhbCBC
dXMNCj4gPiAgICAgIC0gTkFORCBmbGFzaDogOC1iaXQsIGFzeW5jLCB1cCB0byAyR0IuDQo+ID4g
ICAgICAtIE5PUjogOC1iaXQgb3IgMTYtYml0LCBub24tbXVsdGlwbGV4ZWQsIHVwIHRvIDUxMk1C
DQo+ID4gICAgICAtIEdBU0lDOiBTaW1wbGUgKG1pbmltYWwpIHRhcmdldCB3aXRoaW4gUWl4aXMg
RlBHQQ0KPiA+ICAgICAgLSBQcm9tSkVUIHJhcGlkIG1lbW9yeSBkb3dubG9hZCBzdXBwb3J0DQo+
ID4gIC0gRXRoZXJuZXQNCj4gPiAgICAgIC0gVHdvIG9uLWJvYXJkIFJHTUlJIDEwLzEwMC8xRyBl
dGhlcm5ldCBwb3J0cy4NCj4gPiAgICAgIC0gUEhZICMwIHJlbWFpbnMgcG93ZXJlZCB1cCBkdXJp
bmcgZGVlcC1zbGVlcCAoVDEwNDAgb25seSkNCj4gPiAgLSBRSVhJUyBTeXN0ZW0gTG9naWMgRlBH
QQ0KPiA+ICAtIENsb2Nrcw0KPiA+ICAgICAgLSBTeXN0ZW0gYW5kIEREUiBjbG9jayAoU1lTQ0xL
LCDigJxERFJDTEvigJ0pDQo+ID4gICAgICAtIFNFUkRFUyBjbG9ja3MNCj4gPiAgLSBQb3dlciBT
dXBwbGllcw0KPiA+ICAtIFZpZGVvDQo+ID4gICAgICAtIERJVSBzdXBwb3J0cyB2aWRlbyBhdCB1
cCB0byAxMjgweDEwMjR4MzJicHANCj4gPiAgLSBVU0INCj4gPiAgICAgIC0gU3VwcG9ydHMgdHdv
IFVTQiAyLjAgcG9ydHMgd2l0aCBpbnRlZ3JhdGVkIFBIWXMNCj4gPiAgICAgIOKAlCBUd28gdHlw
ZSBBIHBvcnRzIHdpdGggNVZAMS41QSBwZXIgcG9ydC4NCj4gPiAgICAgIOKAlCBTZWNvbmQgcG9y
dCBjYW4gYmUgY29udmVydGVkIHRvIE9URyBtaW5pLUFCDQo+ID4gIC0gU0RIQw0KPiA+ICAgICAg
LSBTREhDIHBvcnQgY29ubmVjdHMgZGlyZWN0bHkgdG8gYW4gYWRhcHRlciBjYXJkIHNsb3QsIGZl
YXR1cmluZzoNCj4gPiAgICAgIC0gU3VwcG9ydGluZyBTRCBzbG90cyBmb3I6IFNELCBTREhDICgx
eCwgNHgsIDh4KSBhbmQvb3IgTU1DDQo+ID4gICAgICDigJQgU3VwcG9ydGluZyBlTU1DIG1lbW9y
eSBkZXZpY2VzDQo+ID4gIC0gU1BJDQo+ID4gICAgIC0gIE9uLWJvYXJkIHN1cHBvcnQgb2YgMyBk
aWZmZXJlbnQgZGV2aWNlcyBhbmQgc2l6ZXMNCj4gPiAgLSBPdGhlciBJTw0KPiA+ICAgICAtIFR3
byBTZXJpYWwgcG9ydHMNCj4gPiAgICAgLSBQcm9maUJ1cyBwb3J0DQo+ID4gICAgIC0gRm91ciBJ
MkMgcG9ydHMNCj4gPg0KPiA+ICBBZGQgVDEwNHhRRFMgc3VwcG9ydCBpbiBLY29uZmlnIGFuZCBN
YWtlZmlsZS4gQWxzbyBjcmVhdGUgZGV2aWNlIHRyZWUuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5
OiBQcml5YW5rYSBKYWluIDxQcml5YW5rYS5KYWluQGZyZWVzY2FsZS5jb20+DQo+ID4gU2lnbmVk
LW9mZi1ieTogUG9vbmFtIEFnZ3J3YWwgPHBvb25hbS5hZ2dyd2FsQGZyZWVzY2FsZS5jb20+DQo+
ID4gU2lnbmVkLW9mZi1ieTogUHJhYmhha2FyIEt1c2h3YWhhIDxwcmFiaGFrYXJAZnJlZXNjYWxl
LmNvbT4NCj4gPiAtLS0NCj4gPiBCYXNlZCB1cG9uDQo+ID4gZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcv
cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3Njb3R0d29vZC9saW51eC5naXQNCj4gPg0KPiA+IFRP
RE86IEFkZCBub2RlZCBmb3IgZXRoZXJuZXQgYW5kIGJvYXJkIHN0dWZmDQo+IA0KPiAiYm9hcmQg
c3R1ZmYiPw0KPiANCj4gSXNuJ3QgImJvYXJkIHN0dWZmIiB0aGUgd2hvbGUgcG9pbnQgb2YgdGhp
cyBwYXRjaD8gOi0pDQo+IA0KDQo6KQ0KDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy90MTA0
MHFkcy5kdHMgICAgICB8ICAyMDENCj4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0K
PiA+ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDEwNDJxZHMuZHRzICAgICAgfCAgMjAxDQo+ICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gPiAgYXJjaC9wb3dlcnBjL3BsYXRmb3Jt
cy84NXh4L0tjb25maWcgICAgIHwgICAyMCArKysNCj4gPiAgYXJjaC9wb3dlcnBjL3BsYXRmb3Jt
cy84NXh4L01ha2VmaWxlICAgIHwgICAgMSArDQo+ID4gIGFyY2gvcG93ZXJwYy9wbGF0Zm9ybXMv
ODV4eC90MTA0eF9xZHMuYyB8ICAxMDIgKysrKysrKysrKysrKysrKw0KPiA+ICA1IGZpbGVzIGNo
YW5nZWQsIDUyNSBpbnNlcnRpb25zKCspDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBhcmNoL3Bv
d2VycGMvYm9vdC9kdHMvdDEwNDBxZHMuZHRzDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBhcmNo
L3Bvd2VycGMvYm9vdC9kdHMvdDEwNDJxZHMuZHRzDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBh
cmNoL3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgvdDEwNHhfcWRzLmMNCj4gPg0KPiA+IGRpZmYgLS1n
aXQgYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvdDEwNDBxZHMuZHRzDQo+ID4gYi9hcmNoL3Bvd2Vy
cGMvYm9vdC9kdHMvdDEwNDBxZHMuZHRzDQo+ID4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4gPiBp
bmRleCAwMDAwMDAwLi5jZWE1NjMyDQo+ID4gLS0tIC9kZXYvbnVsbA0KPiA+ICsrKyBiL2FyY2gv
cG93ZXJwYy9ib290L2R0cy90MTA0MHFkcy5kdHMNCj4gPiBAQCAtMCwwICsxLDIwMSBAQA0KPiA+
ICsvKg0KPiA+ICsgKiBUMTA0MFFEUyBEZXZpY2UgVHJlZSBTb3VyY2UNCj4gPiArICoNCj4gPiAr
ICogQ29weXJpZ2h0IDIwMTMgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IgSW5jLg0KPiA+ICsgKg0K
PiA+ICsgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1z
LCB3aXRoIG9yIHdpdGhvdXQNCj4gPiArICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHBy
b3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zDQo+IGFyZSBtZXQ6DQo+ID4gKyAq
ICAgICAqIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJv
dmUNCj4gY29weXJpZ2h0DQo+ID4gKyAqCSBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z
IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuDQo+ID4gKyAqICAgICAqIFJlZGlzdHJpYnV0
aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUNCj4gY29weXJpZ2h0
DQo+ID4gKyAqCSBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93
aW5nIGRpc2NsYWltZXIgaW4NCj4gdGhlDQo+ID4gKyAqCSBkb2N1bWVudGF0aW9uIGFuZC9vciBv
dGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUNCj4gZGlzdHJpYnV0aW9uLg0KPiA+ICsg
KiAgICAgKiBOZWl0aGVyIHRoZSBuYW1lIG9mIEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yIG5vciB0
aGUNCj4gPiArICoJIG5hbWVzIG9mIGl0cyBjb250cmlidXRvcnMgbWF5IGJlIHVzZWQgdG8gZW5k
b3JzZSBvciBwcm9tb3RlDQo+IHByb2R1Y3RzDQo+ID4gKyAqCSBkZXJpdmVkIGZyb20gdGhpcyBz
b2Z0d2FyZSB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4NCj4gcGVybWlzc2lvbi4NCj4g
PiArICoNCj4gPiArICoNCj4gPiArICogQUxURVJOQVRJVkVMWSwgdGhpcyBzb2Z0d2FyZSBtYXkg
YmUgZGlzdHJpYnV0ZWQgdW5kZXIgdGhlIHRlcm1zIG9mDQo+ID4gK3RoZQ0KPiA+ICsgKiBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZSAoIkdQTCIpIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZQ0K
PiA+ICtTb2Z0d2FyZQ0KPiA+ICsgKiBGb3VuZGF0aW9uLCBlaXRoZXIgdmVyc2lvbiAyIG9mIHRo
YXQgTGljZW5zZSBvciAoYXQgeW91ciBvcHRpb24pDQo+ID4gK2FueQ0KPiA+ICsgKiBsYXRlciB2
ZXJzaW9uLg0KPiA+ICsgKg0KPiA+ICsgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIEZy
ZWVzY2FsZSBTZW1pY29uZHVjdG9yICJBUyBJUyIgQU5EDQo+ID4gK0FOWQ0KPiA+ICsgKiBFWFBS
RVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8s
IFRIRQ0KPiA+ICtJTVBMSUVEDQo+ID4gKyAqIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZ
IEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQ0KPiA+ICtBUkUNCj4gPiArICog
RElTQ0xBSU1FRC4gSU4gTk8gRVZFTlQgU0hBTEwgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IgQkUg
TElBQkxFDQo+ID4gK0ZPUiBBTlkNCj4gPiArICogRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRB
TCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMDQo+ID4gK0RBTUFHRVMNCj4g
PiArICogKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJT
VElUVVRFIEdPT0RTIE9SDQo+ID4gK1NFUlZJQ0VTOw0KPiA+ICsgKiBMT1NTIE9GIFVTRSwgREFU
QSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSDQo+ID4gK0NB
VVNFRCBBTkQNCj4gPiArICogT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4g
Q09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksDQo+ID4gK09SIFRPUlQNCj4gPiArICogKElOQ0xV
RElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBU
SEUNCj4gPiArVVNFIE9GIFRISVMNCj4gPiArICogU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP
RiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuDQo+ID4gKyAqLw0KPiA+ICsNCj4gPiAr
L2luY2x1ZGUvICJmc2wvdDEwNHhzaS1wcmUuZHRzaSINCj4gPiArDQo+ID4gKy8gew0KPiA+ICsJ
bW9kZWwgPSAiZnNsLFQxMDQwUURTIjsNCj4gPiArCWNvbXBhdGlibGUgPSAiZnNsLFQxMDQwUURT
IjsNCj4gPiArCSNhZGRyZXNzLWNlbGxzID0gPDI+Ow0KPiA+ICsJI3NpemUtY2VsbHMgPSA8Mj47
DQo+ID4gKwlpbnRlcnJ1cHQtcGFyZW50ID0gPCZtcGljPjsNCj4gPiArDQo+ID4gKwlhbGlhc2Vz
IHsNCj4gPiArCQkgLyogVE9ETyAqLw0KPiA+ICsJCX07DQo+IA0KPiBUT0RPPyAgRGlkIHlvdSBt
ZWFuIHRoaXMgcGF0Y2ggYXMgYW4gUkZDPw0KPiANCg0KDQphY3R1YWxseSwgdGhpcyBwYXRjaCBp
cyBub3QgYWRkaW5nIGluIGRwYWEgcmVsYXRlZCBub2RlKGZtYW4sYm1hbiBldGMpLg0KSSBhbSBr
ZWVwaW5nIHBsYWNlIGhvbGRlciBmb3IgYWxpYXMgb2YgRXRoZXJuZXQgbm9kZXMuIA0KDQo+IEFs
c28sIHdoaXRlc3BhY2UuDQo+IA0KDQpkb2VzIHdoaXRlc3BhY2UgaXMgbm90IGNhcHR1cmVkIGlu
IGNoZWNrcGF0Y2g/DQoNCj4gPiArCQlpMmNAMTE4MDAwIHsNCj4gPiArICAgICAgICAgICAgICAg
ICAgICAgICAgcGNhOTU0N0A3NyB7DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgY29tcGF0aWJsZSA9ICJwaGlsaXBzLHBjYTk1NDciOw0KPiA+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHJlZyA9IDwweDc3PjsNCj4gPiArICAgICAgICAgICAgICAgICAgICAg
ICAgfTsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICBydGNANjggew0KPiA+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiZGFsbGFzLGRzMzIzMiI7DQo+
ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4Njg+Ow0KPiA+ICsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycnVwdHMgPSA8MHgxIDB4MSAwIDA+
Ow0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICB9Ow0KPiA+ICsJCX07DQo+ID4gKw0KPiA+
ICsJfTsNCj4gDQo+IFdoaXRlc3BhY2UNCj4gDQo+ID4gKw0KPiA+ICsJcGNpMDogcGNpZUBmZmUy
NDAwMDAgew0KPiA+ICsJCXJlZyA9IDwweGYgMHhmZTI0MDAwMCAwIDB4MTAwMDA+Ow0KPiA+ICsJ
CXJhbmdlcyA9IDwweDAyMDAwMDAwIDAgMHhlMDAwMDAwMCAweGMgMHgwMDAwMDAwMCAweDANCj4g
MHgxMDAwMDAwMA0KPiA+ICsJCQkgIDB4MDEwMDAwMDAgMCAweDAwMDAwMDAwIDB4ZiAweGY4MDAw
MDAwIDB4MA0KPiAweDAwMDEwMDAwPjsNCj4gPiArCQlwY2llQDAgew0KPiA+ICsJCQlyYW5nZXMg
PSA8MHgwMjAwMDAwMCAwIDB4ZTAwMDAwMDANCj4gPiArCQkJCSAgMHgwMjAwMDAwMCAwIDB4ZTAw
MDAwMDANCj4gPiArCQkJCSAgMCAweDEwMDAwMDAwDQo+ID4gKw0KPiA+ICsJCQkJICAweDAxMDAw
MDAwIDAgMHgwMDAwMDAwMA0KPiA+ICsJCQkJICAweDAxMDAwMDAwIDAgMHgwMDAwMDAwMA0KPiA+
ICsJCQkJICAwIDB4MDAwMTAwMDA+Ow0KPiA+ICsJCX07DQo+ID4gKwl9Ow0KPiA+ICsNCj4gPiAr
CXBjaTE6IHBjaWVAZmZlMjUwMDAwIHsNCj4gPiArCQlyZWcgPSA8MHhmIDB4ZmUyNTAwMDAgMCAw
eDEwMDAwPjsNCj4gPiArCQlyYW5nZXMgPSA8MHgwMjAwMDAwMCAweDAgMHhlMDAwMDAwMCAweGMg
MHgyMDAwMDAwMCAweDANCj4gMHgxMDAwMDAwMA0KPiA+ICsJCQkgIDB4MDEwMDAwMDAgMHgwIDB4
MDAwMDAwMDAgMHhmIDB4ZjgwMTAwMDAgMHgwDQo+IDB4MDAwMTAwMDA+Ow0KPiA+ICsJCXBjaWVA
MCB7DQo+ID4gKwkJCXJhbmdlcyA9IDwweDAyMDAwMDAwIDAgMHhlMDAwMDAwMA0KPiA+ICsJCQkJ
ICAweDAyMDAwMDAwIDAgMHhlMDAwMDAwMA0KPiA+ICsJCQkJICAwIDB4MTAwMDAwMDANCj4gPiAr
DQo+ID4gKwkJCQkgIDB4MDEwMDAwMDAgMCAweDAwMDAwMDAwDQo+ID4gKwkJCQkgIDB4MDEwMDAw
MDAgMCAweDAwMDAwMDAwDQo+ID4gKwkJCQkgIDAgMHgwMDAxMDAwMD47DQo+ID4gKwkJfTsNCj4g
PiArCX07DQo+ID4gKw0KPiA+ICsJcGNpMjogcGNpZUBmZmUyNjAwMDAgew0KPiA+ICsJCXJlZyA9
IDwweGYgMHhmZTI2MDAwMCAwIDB4MTAwMD47DQo+ID4gKwkJcmFuZ2VzID0gPDB4MDIwMDAwMDAg
MCAweGUwMDAwMDAwIDB4YyAweDQwMDAwMDAwIDAgMHgxMDAwMDAwMA0KPiA+ICsJCQkgIDB4MDEw
MDAwMDAgMCAweDAwMDAwMDAwIDB4ZiAweGY4MDIwMDAwIDAgMHgwMDAxMDAwMD47DQo+ID4gKwkJ
cGNpZUAwIHsNCj4gPiArCQkJcmFuZ2VzID0gPDB4MDIwMDAwMDAgMCAweGUwMDAwMDAwDQo+ID4g
KwkJCQkgIDB4MDIwMDAwMDAgMCAweGUwMDAwMDAwDQo+ID4gKwkJCQkgIDAgMHgxMDAwMDAwMA0K
PiA+ICsNCj4gPiArCQkJCSAgMHgwMTAwMDAwMCAwIDB4MDAwMDAwMDANCj4gPiArCQkJCSAgMHgw
MTAwMDAwMCAwIDB4MDAwMDAwMDANCj4gPiArCQkJCSAgMCAweDAwMDEwMDAwPjsNCj4gPiArCQl9
Ow0KPiA+ICsJfTsNCj4gPiArDQo+ID4gKwlwY2kzOiBwY2llQGZmZTI3MDAwMCB7DQo+ID4gKwkJ
cmVnID0gPDB4ZiAweGZlMjcwMDAwIDAgMHgxMDAwMD47DQo+ID4gKwkJcmFuZ2VzID0gPDB4MDIw
MDAwMDAgMCAweGUwMDAwMDAwIDB4YyAweDYwMDAwMDAwIDAgMHgxMDAwMDAwMA0KPiA+ICsJCQkg
IDB4MDEwMDAwMDAgMCAweDAwMDAwMDAwIDB4ZiAweGY4MDMwMDAwIDAgMHgwMDAxMDAwMD47DQo+
ID4gKwkJcGNpZUAwIHsNCj4gPiArCQkJcmFuZ2VzID0gPDB4MDIwMDAwMDAgMCAweGUwMDAwMDAw
DQo+ID4gKwkJCQkgIDB4MDIwMDAwMDAgMCAweGUwMDAwMDAwDQo+ID4gKwkJCQkgIDAgMHgxMDAw
MDAwMA0KPiA+ICsNCj4gPiArCQkJCSAgMHgwMTAwMDAwMCAwIDB4MDAwMDAwMDANCj4gPiArCQkJ
CSAgMHgwMTAwMDAwMCAwIDB4MDAwMDAwMDANCj4gPiArCQkJCSAgMCAweDAwMDEwMDAwPjsNCj4g
PiArCQl9Ow0KPiA+ICsJfTsNCj4gPiArfTsNCj4gDQo+IE1heWJlIHNvbWUgb2YgdGhpcyBzdHVm
ZiBjb3VsZCBiZSBwdXQgaW4gYSBjb21tb24gZHRzaSBiZXR3ZWVuIHQxMDQwIGFuZA0KPiB0MTA0
Mj8NCj4gDQo+IElkZWFsbHkgZm9yIHQxMDQyIHlvdSdkIGp1c3QgdGFrZSB0aGUgZW50aXJlIHQx
MDQwIHRyZWUgYXMgYW4gaW5jbHVkZSwNCj4gYW5kIGFkZCB0aGUgc3dpdGNoDQo+IA0KDQptZWFu
cywgSSBqdXN0IGNyZWF0ZSBUMTA0MnFkcy5kdHMgYW5kIGZvciBUMTA0MC5kdHMgaW5jbHVkZSB0
MTA0MmR0cyArIHN3aXRjaA0KDQoNCj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL3BsYXRm
b3Jtcy84NXh4L3QxMDR4X3Fkcy5jDQo+ID4gYi9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgv
dDEwNHhfcWRzLmMNCj4gPiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPiA+IGluZGV4IDAwMDAwMDAu
LmQyOGRhMTQNCj4gPiAtLS0gL2Rldi9udWxsDQo+ID4gKysrIGIvYXJjaC9wb3dlcnBjL3BsYXRm
b3Jtcy84NXh4L3QxMDR4X3Fkcy5jDQo+ID4gQEAgLTAsMCArMSwxMDIgQEANCj4gPiArLyoNCj4g
PiArICogVDEwNHggUURTIFNldHVwDQo+ID4gKyAqIFNob3VsZCBhcHBseSBmb3IgUURTIHBsYXRm
b3JtIG9mIFQxMDQwIGFuZCBpdCdzIHBlcnNvbmFsaXRpZXMuDQo+ID4gKyAqIHZpeiBUMTA0MC9U
MTA0Mg0KPiA+ICsgKg0KPiA+ICsgKiBDb3B5cmlnaHQgMjAxMyBGcmVlc2NhbGUgU2VtaWNvbmR1
Y3RvciBJbmMuDQo+ID4gKyAqDQo+ID4gKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZQlpdCBhbmQvb3INCj4gbW9kaWZ5IGl0DQo+ID4gKyAqIHVu
ZGVyICB0aGUgdGVybXMgb2YJdGhlIEdOVSBHZW5lcmFsCSBQdWJsaWMgTGljZW5zZSBhcw0KPiBw
dWJsaXNoZWQgYnkgdGhlDQo+ID4gKyAqIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgIGVpdGhl
ciB2ZXJzaW9uIDIgb2YgdGhlICBMaWNlbnNlLCBvcg0KPiA+ICsoYXQgeW91cg0KPiA+ICsgKiBv
cHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KPiA+ICsgKi8NCj4gPiArDQo+ID4gKyNpbmNsdWRl
IDxsaW51eC9rZXJuZWwuaD4NCj4gPiArI2luY2x1ZGUgPGxpbnV4L3BjaS5oPg0KPiA+ICsjaW5j
bHVkZSA8bGludXgva2Rldl90Lmg+DQo+ID4gKyNpbmNsdWRlIDxsaW51eC9kZWxheS5oPg0KPiA+
ICsjaW5jbHVkZSA8bGludXgvaW50ZXJydXB0Lmg+DQo+ID4gKyNpbmNsdWRlIDxsaW51eC9waHku
aD4NCj4gPiArDQo+ID4gKyNpbmNsdWRlIDxhc20vdGltZS5oPg0KPiA+ICsjaW5jbHVkZSA8YXNt
L21hY2hkZXAuaD4NCj4gPiArI2luY2x1ZGUgPGFzbS9wY2ktYnJpZGdlLmg+DQo+ID4gKyNpbmNs
dWRlIDxtbS9tbXVfZGVjbC5oPg0KPiA+ICsjaW5jbHVkZSA8YXNtL3Byb20uaD4NCj4gPiArI2lu
Y2x1ZGUgPGFzbS91ZGJnLmg+DQo+ID4gKyNpbmNsdWRlIDxhc20vbXBpYy5oPg0KPiA+ICsNCj4g
PiArI2luY2x1ZGUgPGxpbnV4L29mX3BsYXRmb3JtLmg+DQo+ID4gKyNpbmNsdWRlIDxzeXNkZXYv
ZnNsX3NvYy5oPg0KPiA+ICsjaW5jbHVkZSA8c3lzZGV2L2ZzbF9wY2kuaD4NCj4gPiArI2luY2x1
ZGUgPGFzbS9laHZfcGljLmg+DQo+ID4gKw0KPiA+ICsjaW5jbHVkZSAiY29yZW5ldF9kcy5oIg0K
PiANCj4gWW91IGRvbid0IG5lZWQgYWxsIG9mIHRoZXNlIGluY2x1ZGVzLg0KPiANCj4gPiArZGVm
aW5lX21hY2hpbmUodDEwNHhfcWRzKSB7DQo+ID4gKwkubmFtZQkJCT0gIlQxMDR4IFFEUyIsDQo+
ID4gKwkucHJvYmUJCQk9IHQxMDR4X3Fkc19wcm9iZSwNCj4gDQo+IFNob3VsZCB3ZSBoYXZlIHR3
byBtYWNoaW5lIGRlc2NyaXB0aW9ucywgc28gdGhhdCB0aGUgcHJvcGVyIGNoaXAgbmFtZQ0KPiBz
aG93cyB1cCAoZS5nLiBpbiAvcHJvYy9jcHVpbmZvKT8NCj4gDQo+ID4gKy8qIGNvcmVpbnQgZG9l
c24ndCBwbGF5IG5pY2Ugd2l0aCBsYXp5IEVFLCB1c2UgbGVnYWN5IG1waWMgZm9yIG5vdyAqLw0K
PiA+ICsjaWZkZWYgQ09ORklHX1BQQzY0DQo+ID4gKwkuZ2V0X2lycQkJPSBtcGljX2dldF9pcnEs
DQo+ID4gKyNlbHNlDQo+ID4gKwkuZ2V0X2lycQkJPSBtcGljX2dldF9jb3JlaW50X2lycSwNCj4g
PiArI2VuZGlmDQo+IA0KPiBUaGlzIGlzbid0IHRydWUgYW55IG1vcmUuICBXaGVuIHN1Ym1pdHRp
bmcgY29kZSB0aGF0IHdhcyBjb3BpZWQgZnJvbQ0KPiBlbHNld2hlcmUsIHBsZWFzZSBjaGVjayB3
aGV0aGVyIHRoZXJlIHdlcmUgYW55IHVwZGF0ZXMgaW4gdGhlIGNvZGUgdGhhdA0KPiB5b3UgY29w
aWVkIGZyb20gKHVubGVzcyB5b3UgY29waWVkIGZyb20gYjRxZHMsIHdoaWNoIHRoZSB1cGRhdGUg
bWlzc2VkDQo+IC0tIEkganVzdCBzZW50IGEgcGF0Y2ggdG8gZml4IHRoYXQpLg0KPiANCg0KSSB3
aWxsIGNoZWNrIG9uIGxhdGVzdCBjb2RlIGJhc2UuDQoNClJlZ2FyZHMsDQpQcmFiaGFrYXINCg0K

^ permalink raw reply

* RE: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
From: Kushwaha Prabhakar-B32579 @ 2013-09-13  7:30 UTC (permalink / raw)
  To: Wood Scott-B07421
  Cc: Sethi Varun-B16395, Jain Priyanka-B32167, Aggrwal Poonam-B10812,
	linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1378941854.12204.439.camel@snotra.buserror.net>

dGhhbmtzIFNjb3R0IGZvciByZXZpZXcuDQoNClBsZWFzZSBmaW5kIG15IHJlcGx5IGluLWxpbmVk
Lg0KDQpSZWdhcmRzLA0KUHJhYmhha2FyDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAx
MiwgMjAxMyA0OjU0IEFNDQo+IFRvOiBLdXNod2FoYSBQcmFiaGFrYXItQjMyNTc5DQo+IENjOiBs
aW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsg
QWdncndhbA0KPiBQb29uYW0tQjEwODEyOyBKYWluIFByaXlhbmthLUIzMjE2NzsgU2V0aGkgVmFy
dW4tQjE2Mzk1DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2VycGMvbXBjODV4eDpBZGQgaW5p
dGlhbCBkZXZpY2UgdHJlZSBzdXBwb3J0IG9mDQo+IFQxMDR4DQo+IA0KPiBPbiBXZWQsIDIwMTMt
MDktMTEgYXQgMTI6MjggKzA1MzAsIFByYWJoYWthciBLdXNod2FoYSB3cm90ZToNCj4gPiBUaGUg
UW9ySVEgVDEwNDAvVDEwNDIgcHJvY2Vzc29yIHN1cHBvcnQgZm91ciBpbnRlZ3JhdGVkIDY0LWJp
dCBlNTUwMA0KPiA+IFBBIHByb2Nlc3NvciBjb3JlcyB3aXRoIGhpZ2gtcGVyZm9ybWFuY2UgZGF0
YSBwYXRoIGFjY2VsZXJhdGlvbg0KPiA+IGFyY2hpdGVjdHVyZSBhbmQgbmV0d29yayBwZXJpcGhl
cmFsIGludGVyZmFjZXMgcmVxdWlyZWQgZm9yIG5ldHdvcmtpbmcNCj4gJiB0ZWxlY29tbXVuaWNh
dGlvbnMuDQo+ID4NCj4gPiBUMTA0MiBwZXJzb25hbGl0eSBpcyBhIHJlZHVjZWQgcGVyc29uYWxp
dHkgb2YgVDEwNDAgd2l0aG91dCBJbnRlZ3JhdGVkDQo+ID4gOC1wb3J0IEdpZ2FiaXQgRXRoZXJu
ZXQgc3dpdGNoLg0KPiA+DQo+ID4gVGhlIFQxMDQwL1QxMDQyIFNvQyBpbmNsdWRlcyB0aGUgZm9s
bG93aW5nIGZ1bmN0aW9uIGFuZCBmZWF0dXJlczoNCj4gPg0KPiA+ICAtIEZvdXIgZTU1MDAgY29y
ZXMsIGVhY2ggd2l0aCBhIHByaXZhdGUgMjU2IEtCIEwyIGNhY2hlDQo+ID4gIC0gMjU2IEtCIHNo
YXJlZCBMMyBDb3JlTmV0IHBsYXRmb3JtIGNhY2hlIChDUEMpDQo+ID4gIC0gSW50ZXJjb25uZWN0
IENvcmVOZXQgcGxhdGZvcm0NCj4gPiAgLSAzMi0vNjQtYml0IEREUjNML0REUjQgU0RSQU0gbWVt
b3J5IGNvbnRyb2xsZXIgd2l0aCBFQ0MgYW5kDQo+IGludGVybGVhdmluZw0KPiA+ICAgIHN1cHBv
cnQNCj4gPiAgLSBEYXRhIFBhdGggQWNjZWxlcmF0aW9uIEFyY2hpdGVjdHVyZSAoRFBBQSkgaW5j
b3Jwb3JhdGluZw0KPiA+IGFjY2VsZXJhdGlvbiAgZm9yIHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25z
Og0KPiA+ICAgICAtICBQYWNrZXQgcGFyc2luZywgY2xhc3NpZmljYXRpb24sIGFuZCBkaXN0cmli
dXRpb24NCj4gPiAgICAgLSAgUXVldWUgbWFuYWdlbWVudCBmb3Igc2NoZWR1bGluZywgcGFja2V0
IHNlcXVlbmNpbmcsIGFuZA0KPiBjb25nZXN0aW9uDQo+ID4gICAgIAltYW5hZ2VtZW50DQo+ID4g
ICAgIC0gIENyeXB0b2dyYXBoeSBBY2NlbGVyYXRpb24gKFNFQyA1LjApDQo+ID4gICAgIC0gUmVn
RXggUGF0dGVybiBNYXRjaGluZyBBY2NlbGVyYXRpb24gKFBNRSAyLjIpDQo+ID4gICAgIC0gSUVF
RSBTdGQgMTU4OCBzdXBwb3J0DQo+ID4gICAgIC0gSGFyZHdhcmUgYnVmZmVyIG1hbmFnZW1lbnQg
Zm9yIGJ1ZmZlciBhbGxvY2F0aW9uIGFuZA0KPiA+IGRlYWxsb2NhdGlvbg0KPiA+ICAtIEV0aGVy
bmV0IGludGVyZmFjZXMNCj4gPiAgICAgLSBJbnRlZ3JhdGVkIDgtcG9ydCBHaWdhYml0IEV0aGVy
bmV0IHN3aXRjaCAoVDEwNDAgb25seSkNCj4gPiAgICAgLSBGb3VyIDEgR2JwcyBFdGhlcm5ldCBj
b250cm9sbGVycw0KPiA+ICAtIFR3byBSR01JSSBpbnRlcmZhY2VzIG9yIG9uZSBSR01JSSBhbmQg
b25lIE1JSSBpbnRlcmZhY2VzDQo+ID4gIC0gSGlnaCBzcGVlZCBwZXJpcGhlcmFsIGludGVyZmFj
ZXMNCj4gPiAgICAtIEZvdXIgUENJIEV4cHJlc3MgMi4wIGNvbnRyb2xsZXJzIHJ1bm5pbmcgYXQg
dXAgdG8gNSBHSHoNCj4gPiAgICAtIFR3byBTQVRBIGNvbnRyb2xsZXJzIHN1cHBvcnRpbmcgMS41
IGFuZCAzLjAgR2IvcyBvcGVyYXRpb24NCj4gPiAgICAtIFVwdG8gdHdvIFFTR01JSSBpbnRlcmZh
Y2UNCj4gPiAgICAtIFVwdG8gc2l4IFNHTUlJIGludGVyZmFjZSBzdXBwb3J0aW5nIDEwMDAgTWJw
cw0KPiA+ICAgIC0gT25lIFNHTUlJIGludGVyZmFjZSBzdXBwb3J0aW5nIHVwdG8gMjUwMCBNYnBz
DQo+ID4gIC0gQWRkaXRpb25hbCBwZXJpcGhlcmFsIGludGVyZmFjZXMNCj4gPiAgICAtIFR3byBV
U0IgMi4wIGNvbnRyb2xsZXJzIHdpdGggaW50ZWdyYXRlZCBQSFkNCj4gPiAgICAtIFNEL2VTREhD
L2VNTUMNCj4gPiAgICAtICBlU1BJIGNvbnRyb2xsZXINCj4gPiAgICAtIEZvdXIgSTJDIGNvbnRy
b2xsZXJzDQo+ID4gICAgLSBGb3VyIFVBUlRzDQo+ID4gICAgLSBGb3VyIEdQSU8gY29udHJvbGxl
cnMNCj4gPiAgICAtIEludGVncmF0ZWQgZmxhc2ggY29udHJvbGxlciAoSUZDKQ0KPiA+ICAgIC0g
Q2hhbmdlIHRoaXMgdG8gIExDRC8gSERNSSBpbnRlcmZhY2UgKERJVSkgd2l0aCAxMiBiaXQgZHVh
bCBkYXRhDQo+IHJhdGUNCj4gPiAgICAtIFRETSBpbnRlcmZhY2UNCj4gPiAgLSBNdWx0aWNvcmUg
cHJvZ3JhbW1hYmxlIGludGVycnVwdCBjb250cm9sbGVyIChQSUMpDQo+ID4gIC0gVHdvIDgtY2hh
bm5lbCBETUEgZW5naW5lcw0KPiA+ICAtIFNpbmdsZSBzb3VyY2UgY2xvY2tpbmcgaW1wbGVtZW50
YXRpb24NCj4gPiAgLSBEZWVwIFNsZWVwIHBvd2VyIGltcGxlbWVudGFpb24gKHdha2V1cCBmcm9t
DQo+ID4gR1BJTy9UaW1lci9FdGhlcm5ldC9VU0IpDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBQ
b29uYW0gQWdncndhbCA8cG9vbmFtLmFnZ3J3YWxAZnJlZXNjYWxlLmNvbT4NCj4gPiBTaWduZWQt
b2ZmLWJ5OiBQcml5YW5rYSBKYWluIDxQcml5YW5rYS5KYWluQGZyZWVzY2FsZS5jb20+DQo+ID4g
U2lnbmVkLW9mZi1ieTogVmFydW4gU2V0aGkgPFZhcnVuLlNldGhpQGZyZWVzY2FsZS5jb20+DQo+
ID4gU2lnbmVkLW9mZi1ieTogUHJhYmhha2FyIEt1c2h3YWhhIDxwcmFiaGFrYXJAZnJlZXNjYWxl
LmNvbT4NCj4gPiAtLS0NCj4gPiBCYXNlZCB1cG9uDQo+ID4gZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcv
cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3Njb3R0d29vZC9saW51eC5naXQNCj4gDQo+IEV2ZXJ5
dGhpbmcgaW4gdGhlcmUgaGFzIGFscmVhZHkgYmVlbiBwdWxsZWQgYnkgTGludXMsIHNvIHRoZXJl
J3Mgbm8NCj4gcmVhc29uIHRvIHVzZSB0aGF0IHRyZWUgYXMgYSBiYXNlIHJpZ2h0IG5vdy4NCj4g
DQoNCkkgd2lsbCByZWJhc2UgdGhpcyBwYXRjaC4NCg0KPiA+ICsvaW5jbHVkZS8gInQxMDQyc2kt
cG9zdC5kdHNpIg0KPiBbc25pcF0NCj4gPiArCXNlcmRlczogc2VyZGVzQGVhMDAwIHsNCj4gPiAr
CQljb21wYXRpYmxlID0gImZzbCx0MTA0MC1zZXJkZXMiOw0KPiA+ICsJCXJlZwkgICA9IDwweGVh
MDAwIDB4NDAwMD47DQo+ID4gKwl9Ow0KPiA+ICsNCj4gPiArCXNkaGNAMTE0MDAwIHsNCj4gPiAr
CQljb21wYXRpYmxlID0gImZzbCx0MTA0MC1lc2RoYyIsICJmc2wsZXNkaGMiOw0KPiA+ICsJCXNk
aGNpLGF1dG8tY21kMTI7DQo+ID4gKwl9Ow0KPiANCj4gV2h5IGRvZXMgc2RoY2ksYXV0by1jbWQx
MiBuZWVkIHRvIGJlIHNwZWNpZmllZCBoZXJlPyAgSXQncyBhbHJlYWR5IGluDQo+IHQxMDQyc2kt
cG9zdC5kdHNpIHdoaWNoIHlvdSd2ZSBpbmNsdWRlZC4gIExpa2V3aXNlIHdpdGggcmVnIG9uIHRo
ZSBzZXJkZXMNCj4gbm9kZS4NCj4gDQoNCkkgd2lsbCB0YWtlIGNhcmUgb2YgdGhpcy4NCg0KPiBJ
IGFsc28gcXVlc3Rpb24gdGhlIG5lZWQgdG8gZGVmaW5lIHNlcGFyYXRlIHQxMDQwIGNvbXBhdGli
bGUgdmFsdWVzIGZvcg0KPiBhbGwgb2YgdGhlc2UsIGlmIHRoZSBvbmx5IGRpZmZlcmVuY2UgaXMg
d2hldGhlciB0aGUgb25ib2FyZCBzd2l0Y2ggaXMNCj4gZW5hYmxlZCBvciBub3QuDQo+IA0KDQpz
byBzaG91bGQgSSB1c2UgVDEwNHggYXMgY29tcGF0aWJsZSBmaWVsZC4gYW5kIGluIFQxMDQwIGRl
dmljZSB0cmVlIGFkZCBleHRyYSBub2RlIGZvciBsMiBzd2l0Y2guIA0KDQo+ID4gKwljbG9ja2dl
bjogZ2xvYmFsLXV0aWxpdGllc0BlMTAwMCB7DQo+ID4gKwkJY29tcGF0aWJsZSA9ICJmc2wsdDEw
NDItY2xvY2tnZW4iLCAiZnNsLHFvcmlxLWNsb2NrZ2VuLTIuMCIsDQo+ID4gKwkJCQkgICAiZml4
ZWQtY2xvY2siOw0KPiA+ICsJCXJlZyA9IDwweGUxMDAwIDB4MTAwMD47DQo+ID4gKwkJY2xvY2st
b3V0cHV0LW5hbWVzID0gInN5c2NsayI7DQo+ID4gKwkJI2Nsb2NrLWNlbGxzID0gPDA+Ow0KPiA+
ICsNCj4gPiArCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiArCQkjc2l6ZS1jZWxscyA9IDww
PjsNCj4gPiArCQlwbGwwOiBwbGwwQDgwMCB7DQo+ID4gKwkJCSNjbG9jay1jZWxscyA9IDwxPjsN
Cj4gPiArCQkJcmVnID0gPDB4ODAwPjsNCj4gPiArCQkJY29tcGF0aWJsZSA9ICJmc2wsY29yZS1w
bGwtY2xvY2siOw0KPiA+ICsJCQljbG9ja3MgPSA8JmNsb2NrZ2VuPjsNCj4gPiArCQkJY2xvY2st
b3V0cHV0LW5hbWVzID0gInBsbDAiLCAicGxsMC1kaXYyIiwgInBsbDAtZGl2NCI7DQo+ID4gKwkJ
fTsNCj4gPiArCQlwbGwxOiBwbGwxQDgyMCB7DQo+ID4gKwkJCSNjbG9jay1jZWxscyA9IDwxPjsN
Cj4gPiArCQkJcmVnID0gPDB4ODIwPjsNCj4gPiArCQkJY29tcGF0aWJsZSA9ICJmc2wsY29yZS1w
bGwtY2xvY2siOw0KPiA+ICsJCQljbG9ja3MgPSA8JmNsb2NrZ2VuPjsNCj4gPiArCQkJY2xvY2st
b3V0cHV0LW5hbWVzID0gInBsbDEiLCAicGxsMS1kaXYyIiwgInBsbDEtZGl2NCI7DQo+ID4gKwkJ
fTsNCj4gPiArCQltdXgwOiBtdXgwQDAgew0KPiA+ICsJCQkjY2xvY2stY2VsbHMgPSA8MD47DQo+
ID4gKwkJCXJlZyA9IDwweDA+Ow0KPiA+ICsJCQljb21wYXRpYmxlID0gImZzbCxjb3JlLW11eC1j
bG9jayI7DQo+IA0KPiBQbGVhc2UgdXBkYXRlIHRoZSBjbG9jayBzdHVmZiBiYXNlZCBvbg0KPiBo
dHRwOi8vcGF0Y2h3b3JrLm96bGFicy5vcmcvcGF0Y2gvMjc0MTM0Lw0KPiANCg0KdGhpcyBwYXRj
aCBpcyBzdGlsbCB1bmRlciBkaXNjdXNzaW9uLiBNYXkgSSBoYXZlIHRvIHdhaXQgZm9yIHRoZSBm
aW5hbCBwYXRjaC4NCm9yIG1heSBJIHJlYmFzZSBvbiB2NC4gDQoNCj4gPiArL2luY2x1ZGUvICJx
b3JpcS1kbWEtMC5kdHNpIg0KPiA+ICsJZG1hQDEwMDMwMCB7DQo+ID4gKwkJZnNsLGlvbW11LXBh
cmVudCA9IDwmcGFtdTA+Ow0KPiA+ICsJCWZzbCxsaW9kbi1yZWcgPSA8Jmd1dHMgMHg1ODA+OyAv
KiBETUExTElPRE5SICovDQo+ID4gKwl9Ow0KPiA+ICsNCj4gPiArL2luY2x1ZGUvICJxb3JpcS1k
bWEtMS5kdHNpIg0KPiA+ICsJZG1hQDEwMTMwMCB7DQo+ID4gKwkJZnNsLGlvbW11LXBhcmVudCA9
IDwmcGFtdTA+Ow0KPiA+ICsJCWZzbCxsaW9kbi1yZWcgPSA8Jmd1dHMgMHg1ODQ+OyAvKiBETUEy
TElPRE5SICovDQo+ID4gKwl9Ow0KPiANCj4gVGhlc2UgYXJlIGVsbzM6DQo+IGh0dHA6Ly9wYXRj
aHdvcmsub3psYWJzLm9yZy9wYXRjaC8yNzEyMzgvDQoNClRoaXMgcGF0Y2ggaXMgc3RpbGwgdW5k
ZXIgZGlzY3Vzc2lvbi4gDQpJIGFtIG5vdCBzdXJlLCBJIHNob3VsZCB3YWl0IGZvciBmaW5hbCBw
YXRjaCBvciBjaGFuZ2UgY29kZSBhcyBwZXIgdjkgdmVyc2lvbi4gDQo+IA0KPiA+ICsJZGlzcGxh
eUAxODAwMDAgew0KPiA+ICsgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJmc2wsZGl1Iiwg
ImZzbCx0MTA0Mi1kaXUiOw0KPiA+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MTgwMDAwIDEw
MDA+Ow0KPiA+ICsgICAgICAgICAgICAgICAgaW50ZXJydXB0cyA9IDw3NCAyIDAgMD47DQo+ID4g
KyAgICAgICAgfTsNCj4gDQo+IE1vcmUgc3BlY2lmaWMgY29tcGF0aWJsZXMgY29tZSBmaXJzdC4N
Cj4gDQoNClN1cmUuDQoNClJlZ2FyZHMsDQpQcmFiaGFrYXINCg==

^ permalink raw reply

* Re: [PATCH] powerpc/pmac: Early debug output on screen on 64-bit macs
From: Benjamin Herrenschmidt @ 2013-09-13  5:39 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20130913051029.GA5411@concordia>

On Fri, 2013-09-13 at 15:10 +1000, Michael Ellerman wrote:
> Looks like you merged the version with #define DEBUG.
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/setup_64.c#n13

Yes, it looks like I've been distracted, I'll remove it again (or you
can send a patch :-)

Cheers,
Ben.

^ permalink raw reply

* Re: [PATCH] pci: fix interrupt-map for bridges
From: Nikunj A Dadhania @ 2013-09-13  5:19 UTC (permalink / raw)
  To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy
In-Reply-To: <1378988717-15112-1-git-send-email-aik@ozlabs.ru>

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

> The previous scheme always put 0 as a parent slot#. However it is
> not always the case and QEMU's PCI bridge does not support putting
> device at slot#0 as it claims SHPC support for hotplug.
>
> This modifies the interrups map to let the linux guest resolve XICS
> global interrupt number correctly.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> This is the example of working system:
>
> [root@erif_root pci@1]# lspci
> 0001:00:01.0 PCI bridge: Red Hat, Inc. Device 0001
> 0001:01:02.0 PCI bridge: Red Hat, Inc. Device 0001
> 0001:01:03.0 PCI bridge: Red Hat, Inc. Device 0001
> 0001:02:01.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
> 0001:02:02.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
> 0001:03:01.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
> 0001:03:02.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
> [root@erif_root pci@1]# pwd
> /proc/device-tree/pci@80000002000000f/pci@1
> [root@erif_root pci@1]# hexdump -e '9/4 "%08x "' -e '"\n"' i*map
> 00001000 00000000 00000000 00000001 3e57f7e0 00000800 00000000 00000000 00000003
> 00001000 00000000 00000000 00000002 3e57f7e0 00000800 00000000 00000000 00000000
> 00001000 00000000 00000000 00000003 3e57f7e0 00000800 00000000 00000000 00000001
> 00001000 00000000 00000000 00000004 3e57f7e0 00000800 00000000 00000000 00000002
> 00001800 00000000 00000000 00000001 3e57f7e0 00000800 00000000 00000000 00000000
> 00001800 00000000 00000000 00000002 3e57f7e0 00000800 00000000 00000000 00000001
> 00001800 00000000 00000000 00000003 3e57f7e0 00000800 00000000 00000000 00000002
> 00001800 00000000 00000000 00000004 3e57f7e0 00000800 00000000 00000000 00000003
> [root@erif_root pci@1]# cd pci@2/
> [root@erif_root pci@2]# hexdump -e '9/4 "%08x "' -e '"\n"' i*map
> 00000800 00000000 00000000 00000001 3e5a86f0 00001000 00000000 00000000 00000002
> 00000800 00000000 00000000 00000002 3e5a86f0 00001000 00000000 00000000 00000003
> 00000800 00000000 00000000 00000003 3e5a86f0 00001000 00000000 00000000 00000000
> 00000800 00000000 00000000 00000004 3e5a86f0 00001000 00000000 00000000 00000001
> 00001000 00000000 00000000 00000001 3e5a86f0 00001000 00000000 00000000 00000003
> 00001000 00000000 00000000 00000002 3e5a86f0 00001000 00000000 00000000 00000000
> 00001000 00000000 00000000 00000003 3e5a86f0 00001000 00000000 00000000 00000001
> 00001000 00000000 00000000 00000004 3e5a86f0 00001000 00000000 00000000 00000002
> [root@erif_root pci@2]# cd ethernet@
> ethernet@1/ ethernet@2/
> [root@erif_root pci@2]# cd ethernet@1/
> [root@erif_root ethernet@1]# lsprop reg
> reg              00020800 00000000 00000000 00000000 00000000
> 		 02020810 00000000 00000000 00000000 00020000
>  		 02020814 00000000 00000000 00000000 00020000
>  		 01020818 00000000 00000000 00000000 00000020
>  		 02020830 00000000 00000000 00000000 00020000
> [root@erif_root ethernet@1]# lsprop interrupts
> interrupts       00000002
> ---
>  board-qemu/slof/pci-interrupts.fs | 31 ++++++++++++++++++++-----------
>  1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/board-qemu/slof/pci-interrupts.fs b/board-qemu/slof/pci-interrupts.fs
> index a12d7bb..62785a7 100644
> --- a/board-qemu/slof/pci-interrupts.fs
> +++ b/board-qemu/slof/pci-interrupts.fs
> @@ -1,17 +1,26 @@
>
>  : pci-gen-irq-map-one ( prop-addr prop-len slot pin -- prop-addr prop-len )
> -        2dup + 4 mod                                        ( prop-addr prop-len slot pin parentpin )
> +        2dup + 4 mod                ( prop-addr prop-len slot pin parentpin )
> +        >r >r >r                    ( prop-addr prop-len R: swizzledpin pin slot )
> +
> +        \ Child slot#
> +        r> B lshift encode-int+     ( prop-addr prop-len R: swizzledpin pin )

Redundant push to the R-Stack, can just be

        >r >r                    ( prop-addr prop-len slot R: swizzledpin pin )

        \ Child slot#
        B lshift encode-int+     ( prop-addr prop-len R: swizzledpin pin )


> +        \ Child 64bit BAR (not really used)
> +        0 encode-64+
> +        \ Chile pin#
> +        r> encode-int+              ( prop-addr prop-len R: swizzledpin )
> +
> +        \ Parent phandle
> +        get-parent encode-int+
> +
> +        \ Parent slot#
>          get-node >space
> -        pci-addr2dev + 1- 4 mod 1+  \ do swizzling          ( prop-addr prop-len slot pin swizzledpin )
> -        >r >r >r                                            ( prop-addr prop-len R: swizzledpin pin slot )
> -
> -        r> B lshift encode-int+
> -        0 encode-64+                \ device slot           ( prop-addr prop-len R: swizzledpin pin )
> -        r> encode-int+              \ device pin            ( prop-addr prop-len R: swizzledpin )
> -
> -        get-parent encode-int+      \ parent phandle
> -        0 encode-int+ 0 encode-64+  \ parent slot
> -        r> encode-int+              \ parent swizzled pin   ( prop-addr prop-len R: )
> +        pci-addr2dev B lshift       ( prop-addr prop-len parent-slot R: swizzledpin )
> +        encode-int+
> +        \ Parent 64bit BAR (not really used)
> +        0 encode-64+
> +        \ Parent pin
> +        r> encode-int+              ( prop-addr prop-len R: )
>  ;
>
>  : pci-gen-irq-entry ( prop-addr prop-len config-addr -- prop-addr prop-len )

Regards,
Nikunj

^ permalink raw reply

* Re: [PATCH] powerpc/pmac: Early debug output on screen on 64-bit macs
From: Michael Ellerman @ 2013-09-13  5:10 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1374720597.6142.49.camel@pasglop>

On Thu, Jul 25, 2013 at 12:49:57PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 12:12 +1000, Benjamin Herrenschmidt wrote:
> > --- a/arch/powerpc/kernel/setup_64.c
> > +++ b/arch/powerpc/kernel/setup_64.c
> > @@ -10,7 +10,7 @@
> >   *      2 of the License, or (at your option) any later version.
> >   */
> >  
> > -#undef DEBUG
> > +#define DEBUG
> 
> Ooops... sent the wrong version. Will send an updated one later,
> if there are no other comments.

Looks like you merged the version with #define DEBUG.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/setup_64.c#n13


cheers

^ permalink raw reply

* Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
From: leroy christophe @ 2013-09-13  5:04 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1379011469.2536.45.camel@snotra.buserror.net>

Le 12/09/2013 20:44, Scott Wood a écrit :
> On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
>> This is a reorganisation of the setup of the TLB at kernel startup, in order
>> to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.3 of MPC866
>> and MPC885 reference manuals.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S
>> --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S	2013-09-02 22:46:10.000000000 +0200
>> +++ linux-3.11/arch/powerpc/kernel/head_8xx.S	2013-09-09 11:28:54.000000000 +0200
>> @@ -785,27 +785,24 @@
>>    * these mappings is mapped by page tables.
>>    */
>>   initial_mmu:
>> -	tlbia			/* Invalidate all TLB entries */
>> -/* Always pin the first 8 MB ITLB to prevent ITLB
>> -   misses while mucking around with SRR0/SRR1 in asm
>> -*/
>> -	lis	r8, MI_RSV4I@h
>> -	ori	r8, r8, 0x1c00
>> -
>> +	lis	r8, MI_RESETVAL@h
>>   	mtspr	SPRN_MI_CTR, r8	/* Set instruction MMU control */
>>   
>> -#ifdef CONFIG_PIN_TLB
>> -	lis	r10, (MD_RSV4I | MD_RESETVAL)@h
>> -	ori	r10, r10, 0x1c00
>> -	mr	r8, r10
>> -#else
>>   	lis	r10, MD_RESETVAL@h
>> -#endif
>>   #ifndef CONFIG_8xx_COPYBACK
>>   	oris	r10, r10, MD_WTDEF@h
>>   #endif
>>   	mtspr	SPRN_MD_CTR, r10	/* Set data TLB control */
>>   
>> +	tlbia			/* Invalidate all TLB entries */
> Is this change to make sure we invalidate everything even if the
> bootloader set RSV4I?
Most probably. It is step 2 of the process defined in MPC866 and MPC885 
Reference Manuals:

§8.10.3 Loading Locked TLB Entries:
The process of loading a single reserved entry in the TLB is as follows:
1. Disable the TLB by clearing MSR[IR] or MSR[DR] as needed.
2. Clear MI_CTR[RSV4I] (MD_CTR[RSV4D]).
3. Invalidate the EA of the reserved page by using tlbia or tlbie.
4. Set MI_CTR[ITLB_INDX] (MD_CTR[DTLB_INDX]) to the appropriate value 
(between 27 and 31).
5. Load Mx_EPN with the effective page number, the ASID of the reserved 
page, and set EV.
6. Run software tablewalk code to load the appropriate entry into the 
translation lookaside buffer. See Section 8.10.1.1, “Translation Reload 
Examples.”
7. Repeat steps 4–6 to load other TLB entries.
8. Set MI_CTR[RSV4I] (MD_CTR[RSV4D])
>
>> +	ori	r8, r8, 0x1c00
>> +	mtspr	SPRN_MI_CTR, r8	/* Set instruction MMU control */
>> +#ifdef CONFIG_PIN_TLB
>> +	ori	r10, r10, 0x1c00
>> +	mtspr	SPRN_MD_CTR, r10	/* Set data TLB control */
>> +#endif
> Still 0x1c00?
Yes, I kept the same entries in order to limit modifications:
* 28 = First 8Mbytes page
* 29 = IMMR
* 30 = Second 8Mbytes page
* 31 = Third 8Mbytes page
>
>>   	/* Now map the lower 8 Meg into the TLBs.  For this quick hack,
>>   	 * we can load the instruction and data TLB registers with the
>>   	 * same values.
>> @@ -825,6 +822,12 @@
>>   	mtspr	SPRN_MI_AP, r8
>>   	mtspr	SPRN_MD_AP, r8
>>   
>> +	/* Always pin the first 8 MB ITLB to prevent ITLB
>> +	 * misses while mucking around with SRR0/SRR1 in asm
>> +	 */
>> +	lis	r8, (MI_RSV4I | MI_RESETVAL)@h
>> +	mtspr	SPRN_MI_CTR, r8	/* Set instruction MMU control */
> Entry 0 is not pinnable.
Here we are not trying to pin entry 0. We are at step 8, we are setting 
MI_RSV4I. At the same time, we set MD_CTR to 0 which is off the pinned 
range, to be sure that we won't overwrite one of the pinned entries.

The main difference compared to the previous implementation is that 
before, we were setting the RSV4I bit before loading the TLB entries. 
Now, as defined in the Reference Manuals, we are doing it at the end.

Christophe

^ permalink raw reply

* RE: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
From: Zhao Qiang-B45475 @ 2013-09-13  3:17 UTC (permalink / raw)
  To: Kumar Gala, Liu Shengzhou-B36685; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D8AFFF30-31B1-4B3B-B9D0-DC209A5A3BCD@kernel.crashing.org>

On Sep 13, 2013, at 12:42 AM, Kumar Gala wrote:

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, September 13, 2013 12:42 AM
> To: Liu Shengzhou-B36685
> Cc: Zhao Qiang-B45475; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy
> in device tree
>=20
>=20
> On Sep 12, 2013, at 1:54 AM, Liu Shengzhou-B36685 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Wednesday, September 11, 2013 11:13 PM
> >> To: Zhao Qiang-B45475
> >> Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685
> >> Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of
> >> ethernet-phy in device tree
> >>
> >>
> >> On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote:
> >>
> >>
> >> NAK.  The device tree should represent the HW not what drivers decide
> >> to do with it.
> >>
> >> If different board revs have different interrupt signals than create
> >> dts's to handle the 2 board revs.
> >>
> >> - k
> >>
> > You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi
> replacing current p1010rdb.dtsi just because of the unused phy interrupt?
> > and phy interrupt is not present in those dts of P3/P4/P5 platforms.
> > Actually currently many hardware are not present in dts, such as a lot
> of i2c devices, temperature monitor, etc.
> >
> > -Shengzhou
> >
>=20
> I'm saying of the board revs are different w/regards to how the PHY
> interrupt is wired, than create two .dts one for each of the board revs.
>=20
> If the p3/p4/p5 platforms are missing the phy interrupt in the .dts than
> its an error.
>=20
> Other devices like i2c, temp mon, etc should be added.  There is a
> difference between something not existing because people haven't gotten
> around to it / there isn't a binding vs a using the lack of information
> as a configuration mechanism.
>=20
> - k
>=20
>=20

Kumar, please advice your solution, thanks.

-zhaoqiang

^ permalink raw reply

* RE: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
From: Zhao Qiang-B45475 @ 2013-09-13  2:58 UTC (permalink / raw)
  To: Kumar Gala, Liu Shengzhou-B36685; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D8AFFF30-31B1-4B3B-B9D0-DC209A5A3BCD@kernel.crashing.org>

Do you have any solutions?

-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Friday, September 13, 2013 12:42 AM
To: Liu Shengzhou-B36685
Cc: Zhao Qiang-B45475; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in =
device tree


On Sep 12, 2013, at 1:54 AM, Liu Shengzhou-B36685 wrote:

>=20
>=20
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Wednesday, September 11, 2013 11:13 PM
>> To: Zhao Qiang-B45475
>> Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685
>> Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of=20
>> ethernet-phy in device tree
>>=20
>>=20
>> On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote:
>>=20
>>> Since P1010RDB-PA and P1010RDB-PB boards use different external PHY=20
>>> interrupt signals.
>>> And actually the PHY interrupt is not used effectively with=20
>>> corresponding interrupt handler.
>>> So we can remove the interrupts node without side-effect to comply=20
>>> with both P1010RDB-PA and P1010RDB-PB.
>>>=20
>>> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
>>> Signed-off-by: Zhao Qiang <B45475@freescale.com>
>>> ---
>>> arch/powerpc/boot/dts/p1010rdb.dtsi | 3 ---
>>> 1 file changed, 3 deletions(-)
>>>=20
>>=20
>> NAK.  The device tree should represent the HW not what drivers decide=20
>> to do with it.
>>=20
>> If different board revs have different interrupt signals than create=20
>> dts's to handle the 2 board revs.
>>=20
>> - k
>>=20
> You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi replacin=
g current p1010rdb.dtsi just because of the unused phy interrupt?
> and phy interrupt is not present in those dts of P3/P4/P5 platforms.
> Actually currently many hardware are not present in dts, such as a lot of=
 i2c devices, temperature monitor, etc.
>=20
> -Shengzhou
>=20

I'm saying of the board revs are different w/regards to how the PHY interru=
pt is wired, than create two .dts one for each of the board revs.

If the p3/p4/p5 platforms are missing the phy interrupt in the .dts than it=
s an error.

Other devices like i2c, temp mon, etc should be added.  There is a differen=
ce between something not existing because people haven't gotten around to i=
t / there isn't a binding vs a using the lack of information as a configura=
tion mechanism.

- k

^ permalink raw reply

* RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-09-13  2:53 UTC (permalink / raw)
  To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1379009192.2536.19.camel@snotra.buserror.net>

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTMgMjowNyBBTQ0KPiBUbzogV2Fu
ZyBEb25nc2hlbmctQjQwNTM0DQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgZ2FsYWtAa2VybmVs
LmNyYXNoaW5nLm9yZzsgbGludXhwcGMtDQo+IGRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggdjMgNC80XSBwb3dlcnBjLzg1eHg6IGFkZCBzeXNmcyBmb3IgcHcyMCBz
dGF0ZSBhbmQNCj4gYWx0aXZlYyBpZGxlDQo+IA0KPiBPbiBXZWQsIDIwMTMtMDktMTEgYXQgMjI6
NDggLTA1MDAsIFdhbmcgRG9uZ3NoZW5nLUI0MDUzNCB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4g
PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEzIDc6MDQgQU0NCj4gPiA+IFRvOiBX
YW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+IENjOiBnYWxha0BrZXJuZWwuY3Jhc2hpbmcub3Jn
OyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRD
SCB2MyA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5c2ZzIGZvciBwdzIwIHN0YXRlDQo+ID4gPiBh
bmQgYWx0aXZlYyBpZGxlDQo+ID4gPg0KPiA+ID4gT24gV2VkLCAyMDEzLTA5LTExIGF0IDEzOjU2
ICswODAwLCBEb25nc2hlbmcgV2FuZyB3cm90ZToNCj4gPiA+ID4gRnJvbTogV2FuZyBEb25nc2hl
bmcgPGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+DQo+ID4gPiA+IEFkZCBh
IHN5cyBpbnRlcmZhY2UgdG8gZW5hYmxlL2RpYWJsZSBwdzIwIHN0YXRlIG9yIGFsdGl2ZWMgaWRs
ZSwNCj4gPiA+ID4gYW5kIGNvbnRyb2wgdGhlIHdhaXQgZW50cnkgdGltZS4NCj4gPiA+ID4NCj4g
PiA+ID4gRW5hYmxlL0Rpc2FibGUgaW50ZXJmYWNlOg0KPiA+ID4gPiAwLCBkaXNhYmxlLiAxLCBl
bmFibGUuDQo+ID4gPiA+IC9zeXMvZGV2aWNlcy9zeXN0ZW0vY3B1L2NwdVgvcHcyMF9zdGF0ZQ0K
PiA+ID4gPiAvc3lzL2RldmljZXMvc3lzdGVtL2NwdS9jcHVYL2FsdGl2ZWNfaWRsZQ0KPiA+ID4g
Pg0KPiA+ID4gPiBTZXQgd2FpdCBlbnRyeSBiaXQgaW50ZXJmYWNlOg0KPiA+ID4gPiBiaXQgdmFs
dWUgcmFuZ2UgMH42MywgMCBiaXQgaXMgTWludGltZSwgNjMgYml0IGlzIE1heHRpbWUuDQo+ID4g
PiA+IC9zeXMvZGV2aWNlcy9zeXN0ZW0vY3B1L2NwdVgvcHcyMF93YWl0X2VudHJ5X2JpdA0KPiA+
ID4gPiAvc3lzL2RldmljZXMvc3lzdGVtL2NwdS9jcHVYL2FsdGl2ZWNfaWRsZV93YWl0X2VudHJ5
X2JpdA0KPiA+ID4NCj4gPiA+IEknbSBubyBmYW4gb2YgdGhlIHdheSBwb3dlcnBjIGRvZXMgYml0
IG51bWJlcmluZywgYnV0IGRvbid0IGZsaXAgaXQNCj4gPiA+IGFyb3VuZCBoZXJlIC0tIHlvdSds
bCBqdXN0IGNhdXNlIGNvbmZ1c2lvbi4NCj4gPiA+DQo+ID4gT0suIDAgYml0IGlzIG1heHRpbWUs
IDYzIGJpdCBpcyBtaW50aW1lLg0KPiA+DQo+ID4gPiBCZXR0ZXIgeWV0LCB0aGlzIGludGVyZmFj
ZSBzaG91bGQgdGFrZSByZWFsIHRpbWUgdW5pdHMgcmF0aGVyIHRoYW4gYQ0KPiA+ID4gdGltZWJh
c2UgYml0Lg0KPiA+ID4NCj4gPiBJIHRoaW5rIHRoZSByZWFsIHRpbWUgaXMgbm90IHN1aXRhYmxl
LCBiZWNhdXNlIHRpbWViYXNlIGJpdCBkb2VzIG5vdA0KPiA+IGNvcnJlc3BvbmQgd2l0aCByZWFs
IHRpbWUuDQo+IA0KPiBJdCdzIGEgYml0IHNsb3BweSBkdWUgdG8gaG93IHRoZSBoYXJkd2FyZSB3
b3JrcywgYnV0IHlvdSBjb3VsZCBjb252ZXJ0IGl0DQo+IGxpa2UgeW91IGRpZCBpbiBlYXJsaWVy
IHBhdGNoZXMuICBTZW1hbnRpY2FsbHkgaXQgc2hvdWxkIHByb2JhYmx5IGJlIHRoZQ0KPiBtaW5p
bXVtIHRpbWUgdG8gd2FpdCBiZWZvcmUgZW50ZXJpbmcgdGhlIGxvdyBwb3dlciBzdGF0ZS4NCj4g
DQpCdXQgdGhlcmUgaGFzIGEgcHJvYmxlbSwgd2UgY2FuJ3QgY29udmVydCBiaXQgdG8gdGhlIHJl
YWwgdGltZSB3aGVuIHVzZXIgcmVhZCB0aGlzIHN5c2ZzLg0KTGlrZToNCmVjaG8gMTAwMCh1cykg
PiAvc3lzLyovcHcyMF93YWl0X2VudHJ5X2JpdCwgYWZ0ZXIgY29udmVydCB3ZSBnZXQgYml0IGlz
IDQ5Lg0KY2F0IC9zeXMvKi9wdzIwX3dhaXRfZW50cnlfYml0LCBhZnRlciBjb252ZXJ0IHRoZSB0
aW1lIGlzIDE1OTgodXMpLg0KDQpUaGUgcmVhZCBvdXQgb2YgdGhlIHRpbWUgaXMgbm90IHJlYWwg
dGltZS4gVW5sZXNzIHdlIGRlZmluZSBhIHZhcmlhYmxlIHRvIHNhdmUgdGhlIHJlYWwgdGltZS4N
Cg0KPiA+ID4gQWxzbywgeW91IGRpc2FibGUgdGhlIHBvd2VyIHNhdmluZyBtb2RlIGlmIHRoZSBt
YXhpbXVtIGludGVydmFsIGlzDQo+ID4gPiBzZWxlY3RlZCwNCj4gPiBJdCdzIG5vdCBkaXNhYmxl
IHRoZSBwdzIwIHN0YXRlIG9yIGFsdGl2ZWMgaWRsZSwganVzdCBtYXgtZGVsYXkgZW50cnkNCj4g
dGltZS4NCj4gDQo+IE5vLCB0aGUgY29kZSBjaGVja3MgZm9yIHplcm8gdG8gc2V0IG9yIGNsZWFy
IHRoZSBlbmFibGluZyBiaXQgKGUuZy4NCj4gUFcyMF9XQUlUKS4NCj4gDQpUaGVyZSBoYXMgcHcy
MF9zdGF0ZS9hbHRpdmVjX2lkbGUgc3lzIGludGVyZmFjZSB0byBjb250cm9sICJlbmFibGUvZGlz
YWJsZSIsDQpUaGVyZSBpcyBvbmx5IHRvIGNvbnRyb2wgd2FpdCBiaXQuIERpZCB5b3UgbWVhbiBy
ZW1vdmUgInB3MjBfc3RhdGUvYWx0aXZlY19pZGxlIg0Kc3lzIGludGVyZmFjZSwgYW5kIHJldXNl
ICJwdzIwX3dhaXRfZW50cnlfYml0L2FsdGl2ZWNfaWRsZSoiIHN5cyBpbnRlcmZhY2U/DQpXaGVu
IGVjaG8gemVybyBpbnRvICJwdzIwX3dhaXRfZW50cnlfYml0IiB3ZSBqdXN0IHRvIGRpc2FibGUg
cHcyMCBzdGF0ZSwgSSB0aGluayB0aGF0IGlzIHJlYXNvbmFibGUuIDopDQo=

^ permalink raw reply

* RE: [PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes
From: Tang Yuantian-B29983 @ 2013-09-13  2:50 UTC (permalink / raw)
  To: Wood Scott-B07421
  Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Li Yang-Leo-R58472
In-Reply-To: <1378997052.2536.5.camel@snotra.buserror.net>

DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IDIwMTPlubQ55pyIMTLml6Ug5pif5pyf5ZubIDIyOjQ0DQo+IFRvOiBUYW5nIFl1
YW50aWFuLUIyOTk4Mw0KPiBDYzogV29vZCBTY290dC1CMDc0MjE7IGdhbGFrQGtlcm5lbC5jcmFz
aGluZy5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZzsgZGV2aWNldHJlZUB2
Z2VyLmtlcm5lbC5vcmc7IExpIFlhbmctTGVvLVI1ODQ3Mg0KPiBTdWJqZWN0OiBSZTogW1BBVENI
IHY0XSBwb3dlcnBjL21wYzg1eHg6IFVwZGF0ZSB0aGUgY2xvY2sgZGV2aWNlIHRyZWUNCj4gbm9k
ZXMNCj4gDQo+IE9uIFdlZCwgMjAxMy0wOS0xMSBhdCAyMDozMSAtMDUwMCwgVGFuZyBZdWFudGlh
bi1CMjk5ODMgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g
RnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6IDIwMTPlubQ55pyIMTLml6Ug5pif
5pyf5ZubIDk6MTANCj4gPiA+IFRvOiBUYW5nIFl1YW50aWFuLUIyOTk4Mw0KPiA+ID4gQ2M6IGdh
bGFrQGtlcm5lbC5jcmFzaGluZy5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOw0K
PiA+ID4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IExpIFlhbmctTGVvLVI1ODQ3Mg0KPiA+
ID4gU3ViamVjdDogUmU6IFtQQVRDSCB2NF0gcG93ZXJwYy9tcGM4NXh4OiBVcGRhdGUgdGhlIGNs
b2NrIGRldmljZQ0KPiA+ID4gdHJlZSBub2Rlcw0KPiA+ID4NCj4gPiA+IFRoaXMgZGVzY3JpcHRp
b24gb2YgInJlZyIgaXMgb3Zlcmx5IHNwZWNpZmljIChhc3N1bWVzIGhvdyB0aGUgcGFyZW50DQo+
ID4gPiBub2RlJ3MgcmFuZ2VzIGFyZSBzZXQgdXApLCBpbmNvbXBsZXRlICh0aGVyZSdzIGEgc2l6
ZSBhcyB3ZWxsIGFzIHRoZQ0KPiA+ID4gb2Zmc2V0KSwgYW5kIGRvZXMgbm90IGFwcGx5IHRvIHRo
ZSBjbG9ja2dlbiBub2RlIGl0c2VsZiAoeW91DQo+ID4gPiBwcm9iYWJseSBzaG91bGRuJ3QgbHVt
cCB0aGVtIHRvZ2V0aGVyIGxpa2UgdGhpcykuDQo+ID4gPg0KPiA+IERvIHlvdSBtZWFuIEkgc2hv
dWxkIGV4cGxhaW4gdGhlIFJFRyBvZiBjbG9ja2dlbiBhbmQgaXRzIGNoaWxkIG5vZGUNCj4gcmVz
cGVjdGl2ZWx5Pw0KPiA+DQo+ID4gPiA+ICstIGNsb2NrcyA6IHNoYWxsIGJlIHRoZSBpbnB1dCBw
YXJlbnQgY2xvY2sgcGhhbmRsZSBmb3IgdGhlIGNsb2NrLg0KPiA+ID4NCj4gPiA+IE5vdCByZXF1
aXJlZCBvbiB0aGUgY2xvY2tnZW4gbm9kZQ0KPiA+ID4NCj4gPiBSZXF1aXJlZCBieSBjaGlsZCBu
b2RlIG9mIGNsb2NrZ2VuLg0KPiANCj4gTXkgcG9pbnQgaXMgdGhhdCB5b3UncmUgbHVtcGluZyBz
ZXZlcmFsIGRpZmZlcmVudCB0eXBlcyBvZiBub2RlcyB0b2dldGhlcg0KPiB3aXRoIG9uZSBiaW5k
aW5nLCB3aGVuIHNvbWUgcGFydHMgb2YgdGhlIGJpbmRpbmcgYXJlIG5vdCBhcHBsaWNhYmxlIHRv
DQo+IHRoZSBjbG9ja2dlbiBub2RlLg0KPiANCk5vdCBzZXZlcmFsLCBqdXN0IHR3byB0eXBlcyBv
ZiBub2Rlcy4NCk9uZSBpcyBjbG9ja2dlbiBub2RlLCB0aGUgb3RoZXIgaXMgUExMIGFuZCBtdXgg
bm9kZXMuDQoNClRoZSByZWFzb24gdGhleSBsdW1wZWQgdG9nZXRoZXIgaXMgdGhhdCB0aGUgY2xv
Y2tnZW4gbm9kZSBpcyBub3Qgb25seSBJUCBibG9jaw0KTm9kZSBidXQgYWxzbyBhIGNsb2NrIHBy
b3ZpZGVyIG5vZGUuDQoNCkF0IGZpcnN0LCBJIHdhbnQgdG8gYWRkIGEgZXh0cmEgZml4ZWQtY2xv
Y2sgbm9kZSBhbmQgbW92ZSB0aGUgY2xvY2stZnJlcXVlbmN5IG9mIGNsb2NrZ2VuIA0KTm9kZSB0
byBpdCwgYnV0IGl0IGlzIGFnYWluc3QgdGhlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2hpY2gg
SSB0aGluayBpdCBpcyBub3QgYSBiaWcgZGVhbCwNCkJlY2F1c2Ugbm9ib2R5IGhhc24ndCB1c2Vk
IGl0IHlldC4NCklmIEkgYWRkIGEgZXh0cmEgbm9kZSB3aXRoIHRoZSBjbG9jay1mcmVxdWVuY3kg
cHJvcGVydHkgYW5kIGRvbid0IG1vdmUgdGhlDQpjbG9jay1mcmVxdWVuY3kgcHJvcGVydHkgb2Yg
Y2xvY2tnZW4sIHRoYXQgd291bGQgYmUgcmVkdW5kYW50IGJlY2F1c2UgYm90aCBjbG9ja2dlbiBu
b2RlDQphbmQgdGhlIGV4dHJhIG5vZGUgaGF2ZSB0aGUgc2FtZSBjbG9jay1mcmVxdWVuY3kgbm9k
ZS4NClNvLCBJIGNob29zZSB3aGF0IEkgZGlkIG5vdy4NCiANCkNvdWxkIHlvdSBnaXZlIG1lIHNv
bWUgc3VnZ2VzdGlvbnMgb24gdGhpcz8NClJlZ2FyZHMsDQpZdWFudGlhbg0KDQo+IC1TY290dA0K
PiANCg0K

^ permalink raw reply

* Re: [PATCH 1/2] powerpc/85xx: introduce cornet_generic machine
From: Kevin Hao @ 2013-09-13  1:11 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc
In-Reply-To: <1379011486.2536.46.camel@snotra.buserror.net>

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

On Thu, Sep 12, 2013 at 01:44:46PM -0500, Scott Wood wrote:
> On Thu, 2013-09-12 at 15:13 +0800, Kevin Hao wrote:
> > In the current kernel, the board files for p2041rdb, p3041ds, p4080ds,
> > p5020ds, p5040ds, t4240qds and b4qds are almost the same except the
> > machine name. So this introduces a cornet_generic machine to support
> > all these boards to avoid the code duplication.
> > 
> > Signed-off-by: Kevin Hao <haokexin@gmail.com>
> > ---
> > This patch is based on http://patchwork.ozlabs.org/patch/274390/
> > 
> >  arch/powerpc/platforms/85xx/Kconfig      | 10 ++++
> >  arch/powerpc/platforms/85xx/Makefile     |  8 +--
> >  arch/powerpc/platforms/85xx/b4_qds.c     | 97 --------------------------------
> >  arch/powerpc/platforms/85xx/corenet_ds.c | 86 ++++++++++++++++++++++++++++
> >  arch/powerpc/platforms/85xx/p2041_rdb.c  | 87 ----------------------------
> >  arch/powerpc/platforms/85xx/p3041_ds.c   | 89 -----------------------------
> >  arch/powerpc/platforms/85xx/p4080_ds.c   | 87 ----------------------------
> >  arch/powerpc/platforms/85xx/p5020_ds.c   | 93 ------------------------------
> >  arch/powerpc/platforms/85xx/p5040_ds.c   | 84 ---------------------------
> >  arch/powerpc/platforms/85xx/t4240_qds.c  | 93 ------------------------------
> >  10 files changed, 97 insertions(+), 637 deletions(-)
> >  delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
> >  delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
> >  delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
> >  delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
> >  delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
> >  delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
> >  delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
> 
> Why not merge patch 2/2 with this?

OK. I will fold the patch 2 into this one.

> 
> Did you use -M -C with git format-patch?

For this case, using '-M -C' or not would generate the same patch.

> 
> > diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> >  config TQM85xx
[...]
> >  	bool
> > +
> > +config CORENET_GENERIC
> > +	bool
> 
> Why do we need separate kconfig symbols for each board, if they all
> select the same code?

I thought it would be more obvious for the board support if we have a separate
option for each board. We can also use this option for some board specific
configuration if we have. Yes, it does seem a bit redundant. If you prefer I
can drop these boards options.

> 
> > +define_machine(corenet_generic) {
> > +	.name			= "CORENET GENERIC",
> 
> No allcaps please.

How about "CORENET Generic"?

BTW with these changes the file name "corenet_ds.c" seems not accurate anymore?
How about change it to "corenet_generic.c"?

Thanks,
Kevin
> 
> -Scott
> 
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: [PATCH v2] pstore: Adjust buffer size for compression for smaller registered buffers
From: Aruna Balakrishnaiah @ 2013-09-12 19:22 UTC (permalink / raw)
  To: Luck, Tony
  Cc: jkenisto@linux.vnet.ibm.com, keescook@chromium.org,
	mahesh@linux.vnet.ibm.com, cbouatmailru@gmail.com,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	ccross@android.com, seiji.aguchi@hds.com
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F31CF6AB8@ORSMSX106.amr.corp.intel.com>

On Thursday 12 September 2013 11:13 PM, Luck, Tony wrote:
> +	default:
> +		cmpr = 60;
> +		break;
> +	}
>
> Is this the right "default"?  It may be a good choice for a backend with a really
> tiny buffer (1 ... 999).  But less good for a (theoretical) backend with a larger
> buffer (10001 ... infinity and beyond).  Which are you trying to catch here?

Trying to catch lower buffers and also tried till 23k ( 10k * 100/45) of text with a
sample crash logit achieved a good compression of 25%. Since the upper limit is 
not known
and compression behavior is not tested above 10k chose to keep a higher default 
of 60.

> -Tony
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>

^ permalink raw reply

* Re: [PATCH 1/2] powerpc/85xx: introduce cornet_generic machine
From: Scott Wood @ 2013-09-12 18:44 UTC (permalink / raw)
  To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <1378969993-14991-2-git-send-email-haokexin@gmail.com>

On Thu, 2013-09-12 at 15:13 +0800, Kevin Hao wrote:
> In the current kernel, the board files for p2041rdb, p3041ds, p4080ds,
> p5020ds, p5040ds, t4240qds and b4qds are almost the same except the
> machine name. So this introduces a cornet_generic machine to support
> all these boards to avoid the code duplication.
> 
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> ---
> This patch is based on http://patchwork.ozlabs.org/patch/274390/
> 
>  arch/powerpc/platforms/85xx/Kconfig      | 10 ++++
>  arch/powerpc/platforms/85xx/Makefile     |  8 +--
>  arch/powerpc/platforms/85xx/b4_qds.c     | 97 --------------------------------
>  arch/powerpc/platforms/85xx/corenet_ds.c | 86 ++++++++++++++++++++++++++++
>  arch/powerpc/platforms/85xx/p2041_rdb.c  | 87 ----------------------------
>  arch/powerpc/platforms/85xx/p3041_ds.c   | 89 -----------------------------
>  arch/powerpc/platforms/85xx/p4080_ds.c   | 87 ----------------------------
>  arch/powerpc/platforms/85xx/p5020_ds.c   | 93 ------------------------------
>  arch/powerpc/platforms/85xx/p5040_ds.c   | 84 ---------------------------
>  arch/powerpc/platforms/85xx/t4240_qds.c  | 93 ------------------------------
>  10 files changed, 97 insertions(+), 637 deletions(-)
>  delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
>  delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
>  delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
>  delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
>  delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
>  delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
>  delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c

Why not merge patch 2/2 with this?

Did you use -M -C with git format-patch?

> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index de2eb93..3bee943 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -228,6 +228,7 @@ config P2041_RDB
>  	select GPIO_MPC8XXX
>  	select HAS_RAPIDIO
>  	select PPC_EPAPR_HV_PIC
> +	select CORENET_GENERIC
>  	help
>  	  This option enables support for the P2041 RDB board
>  
> @@ -241,6 +242,7 @@ config P3041_DS
>  	select GPIO_MPC8XXX
>  	select HAS_RAPIDIO
>  	select PPC_EPAPR_HV_PIC
> +	select CORENET_GENERIC
>  	help
>  	  This option enables support for the P3041 DS board
>  
> @@ -254,6 +256,7 @@ config P4080_DS
>  	select GPIO_MPC8XXX
>  	select HAS_RAPIDIO
>  	select PPC_EPAPR_HV_PIC
> +	select CORENET_GENERIC
>  	help
>  	  This option enables support for the P4080 DS board
>  
> @@ -278,6 +281,7 @@ config P5020_DS
>  	select GPIO_MPC8XXX
>  	select HAS_RAPIDIO
>  	select PPC_EPAPR_HV_PIC
> +	select CORENET_GENERIC
>  	help
>  	  This option enables support for the P5020 DS board
>  
> @@ -292,6 +296,7 @@ config P5040_DS
>  	select GPIO_MPC8XXX
>  	select HAS_RAPIDIO
>  	select PPC_EPAPR_HV_PIC
> +	select CORENET_GENERIC
>  	help
>  	  This option enables support for the P5040 DS board
>  
> @@ -323,6 +328,7 @@ config T4240_QDS
>  	select GPIO_MPC8XXX
>  	select HAS_RAPIDIO
>  	select PPC_EPAPR_HV_PIC
> +	select CORENET_GENERIC
>  	help
>  	  This option enables support for the T4240 QDS board
>  
> @@ -337,6 +343,7 @@ config B4_QDS
>  	select ARCH_REQUIRE_GPIOLIB
>  	select HAS_RAPIDIO
>  	select PPC_EPAPR_HV_PIC
> +	select CORENET_GENERIC
>  	help
>  	  This option enables support for the B4 QDS board
>  	  The B4 application development system B4 QDS is a complete
> @@ -348,3 +355,6 @@ endif # FSL_SOC_BOOKE
>  
>  config TQM85xx
>  	bool
> +
> +config CORENET_GENERIC
> +	bool

Why do we need separate kconfig symbols for each board, if they all
select the same code?

> +define_machine(corenet_generic) {
> +	.name			= "CORENET GENERIC",

No allcaps please.

-Scott

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox