LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 4/6 v2] powerpc/qe: update QE Serial Number
From: Haiying Wang @ 2009-05-01 19:40 UTC (permalink / raw)
  To: linuxppc-dev, galak; +Cc: Haiying Wang
In-Reply-To: <1241206851-27749-1-git-send-email-Haiying.Wang@freescale.com>

The latest QE chip may have more Serial Number(SNUM)s of thread to use. We will
get the number of SNUMs from device tree by reading the new property
"fsl,qe-num-snums", and set 28 as the default number of SNUMs so that it is
compatible with the old QE chips' device trees which don't have this new
property. The macro QE_NUM_OF_SNUM is defined as the maximum number in QE snum
table which is 256.
Also we update the snum_init[] array with 18 more new SNUMs which are
confirmed to be useful on new chip.

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
v2 change: rename the new property as "fsl,qe-num-snums" and move it to Required
section in qe.txt
 .../powerpc/dts-bindings/fsl/cpm_qe/qe.txt         |    2 +
 arch/powerpc/include/asm/qe.h                      |    3 +-
 arch/powerpc/sysdev/qe_lib/qe.c                    |   47 ++++++++++++++++++--
 3 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
index 39b5d1f..6e37be1 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
@@ -18,6 +18,8 @@ Required properties:
 - reg : offset and length of the device registers.
 - bus-frequency : the clock frequency for QUICC Engine.
 - fsl,qe-num-riscs: define how many RISC engines the QE has.
+- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
+  threads.
 
 Recommended properties
 - brg-frequency : the internal clock source frequency for baud-rate
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 60314ef..e0faf33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -22,7 +22,7 @@
 #include <asm/cpm.h>
 #include <asm/immap_qe.h>
 
-#define QE_NUM_OF_SNUM	28
+#define QE_NUM_OF_SNUM	256	/* There are 256 serial number in QE */
 #define QE_NUM_OF_BRGS	16
 #define QE_NUM_OF_PORTS	1024
 
@@ -153,6 +153,7 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier);
 int qe_get_snum(void);
 void qe_put_snum(u8 snum);
 unsigned int qe_get_num_of_risc(void);
+unsigned int qe_get_num_of_snums(void);
 
 /* we actually use cpm_muram implementation, define this for convenience */
 #define qe_muram_init cpm_muram_init
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 2533677..b28b0e5 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -61,6 +61,7 @@ struct qe_immap __iomem *qe_immr;
 EXPORT_SYMBOL(qe_immr);
 
 static struct qe_snum snums[QE_NUM_OF_SNUM];	/* Dynamically allocated SNUMs */
+static unsigned int qe_num_of_snum;
 
 static phys_addr_t qebase = -1;
 
@@ -264,10 +265,14 @@ static void qe_snums_init(void)
 		0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
 		0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89,
 		0x98, 0x99, 0xA8, 0xA9, 0xB8, 0xB9, 0xC8, 0xC9,
-		0xD8, 0xD9, 0xE8, 0xE9,
+		0xD8, 0xD9, 0xE8, 0xE9, 0x08, 0x09, 0x18, 0x19,
+		0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
+		0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
 	};
 
-	for (i = 0; i < QE_NUM_OF_SNUM; i++) {
+	qe_num_of_snum = qe_get_num_of_snums();
+
+	for (i = 0; i < qe_num_of_snum; i++) {
 		snums[i].num = snum_init[i];
 		snums[i].state = QE_SNUM_STATE_FREE;
 	}
@@ -280,7 +285,7 @@ int qe_get_snum(void)
 	int i;
 
 	spin_lock_irqsave(&qe_lock, flags);
-	for (i = 0; i < QE_NUM_OF_SNUM; i++) {
+	for (i = 0; i < qe_num_of_snum; i++) {
 		if (snums[i].state == QE_SNUM_STATE_FREE) {
 			snums[i].state = QE_SNUM_STATE_USED;
 			snum = snums[i].num;
@@ -297,7 +302,7 @@ void qe_put_snum(u8 snum)
 {
 	int i;
 
-	for (i = 0; i < QE_NUM_OF_SNUM; i++) {
+	for (i = 0; i < qe_num_of_snum; i++) {
 		if (snums[i].num == snum) {
 			snums[i].state = QE_SNUM_STATE_FREE;
 			break;
@@ -603,3 +608,37 @@ unsigned int qe_get_num_of_risc(void)
 }
 EXPORT_SYMBOL(qe_get_num_of_risc);
 
+unsigned int qe_get_num_of_snums(void)
+{
+	struct device_node *qe;
+	int size;
+	unsigned int num_of_snums;
+	const u32 *prop;
+
+	num_of_snums = 28; /* The default number of snum for threads is 28 */
+	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
+	if (!qe) {
+		/* Older devices trees did not have an "fsl,qe"
+		 * compatible property, so we need to look for
+		 * the QE node by name.
+		 */
+		qe = of_find_node_by_type(NULL, "qe");
+		if (!qe)
+			return num_of_snums;
+	}
+
+	prop = of_get_property(qe, "fsl,qe-num-snums", &size);
+	if (prop && size == sizeof(*prop)) {
+		num_of_snums = *prop;
+		if ((num_of_snums < 28) || (num_of_snums > QE_NUM_OF_SNUM)) {
+			/* No QE ever has fewer than 28 SNUMs */
+			pr_err("QE: number of snum is invalid\n");
+			return -EINVAL;
+		}
+	}
+
+	of_node_put(qe);
+
+	return num_of_snums;
+}
+EXPORT_SYMBOL(qe_get_num_of_snums);
-- 
1.6.0.2

^ permalink raw reply related

* [PATCH 5/6 v2] net/ucc_geth: Assign six threads to Rx for UEC
From: Haiying Wang @ 2009-05-01 19:40 UTC (permalink / raw)
  To: linuxppc-dev, galak; +Cc: Haiying Wang
In-Reply-To: <1241206851-27749-2-git-send-email-Haiying.Wang@freescale.com>

in the case the QE has 46 SNUMs for the threads to support four UCC Ethernet at
1000Base-T simultaneously.

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
v2 change: Add comments for the Rx threads change.
 drivers/net/ucc_geth.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 44f8392..1cb2710 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3702,7 +3702,15 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
 		ug_info->uf_info.utfet = UCC_GETH_UTFET_GIGA_INIT;
 		ug_info->uf_info.utftt = UCC_GETH_UTFTT_GIGA_INIT;
 		ug_info->numThreadsTx = UCC_GETH_NUM_OF_THREADS_4;
-		ug_info->numThreadsRx = UCC_GETH_NUM_OF_THREADS_4;
+
+		/* If QE's snum number is 46 which means we need to support
+		 * 4 UECs at 1000Base-T simultaneously, we need to allocate
+		 * more Threads to Rx.
+		 */
+		if (qe_get_num_of_snums() == 46)
+			ug_info->numThreadsRx = UCC_GETH_NUM_OF_THREADS_6;
+		else
+			ug_info->numThreadsRx = UCC_GETH_NUM_OF_THREADS_4;
 	}
 
 	if (netif_msg_probe(&debug))
-- 
1.6.0.2

^ permalink raw reply related

* [PATCH 2/6 v2] powerpc/qe: update risc allocation for QE
From: Haiying Wang @ 2009-05-01 19:40 UTC (permalink / raw)
  To: linuxppc-dev, galak; +Cc: Haiying Wang

Change the RISC allocation to macros instead of enum, add function to read the
number of risc engines from the new property "fsl,qe-num-riscs" under qe node
in dts. Add new property "fsl,qe-num-riscs" description in qe.txt

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
v2 change: rename the new property to "fsl,qe-num-riscs" and move this node to
Required section in qe.txt.
 .../powerpc/dts-bindings/fsl/cpm_qe/qe.txt         |    1 +
 arch/powerpc/include/asm/qe.h                      |   18 ++++++++----
 arch/powerpc/sysdev/qe_lib/qe.c                    |   28 ++++++++++++++++++++
 3 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
index 78790d5..39b5d1f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
@@ -17,6 +17,7 @@ Required properties:
 - model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
 - reg : offset and length of the device registers.
 - bus-frequency : the clock frequency for QUICC Engine.
+- fsl,qe-num-riscs: define how many RISC engines the QE has.
 
 Recommended properties
 - brg-frequency : the internal clock source frequency for baud-rate
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 2701753..60314ef 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -152,6 +152,8 @@ unsigned int qe_get_brg_clk(void);
 int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier);
 int qe_get_snum(void);
 void qe_put_snum(u8 snum);
+unsigned int qe_get_num_of_risc(void);
+
 /* we actually use cpm_muram implementation, define this for convenience */
 #define qe_muram_init cpm_muram_init
 #define qe_muram_alloc cpm_muram_alloc
@@ -231,12 +233,16 @@ struct qe_bd {
 #define QE_ALIGNMENT_OF_PRAM	64
 
 /* RISC allocation */
-enum qe_risc_allocation {
-	QE_RISC_ALLOCATION_RISC1 = 1,	/* RISC 1 */
-	QE_RISC_ALLOCATION_RISC2 = 2,	/* RISC 2 */
-	QE_RISC_ALLOCATION_RISC1_AND_RISC2 = 3	/* Dynamically choose
-						   RISC 1 or RISC 2 */
-};
+#define QE_RISC_ALLOCATION_RISC1	0x1  /* RISC 1 */
+#define QE_RISC_ALLOCATION_RISC2	0x2  /* RISC 2 */
+#define QE_RISC_ALLOCATION_RISC3	0x4  /* RISC 3 */
+#define QE_RISC_ALLOCATION_RISC4	0x8  /* RISC 4 */
+#define QE_RISC_ALLOCATION_RISC1_AND_RISC2	(QE_RISC_ALLOCATION_RISC1 | \
+						 QE_RISC_ALLOCATION_RISC2)
+#define QE_RISC_ALLOCATION_FOUR_RISCS	(QE_RISC_ALLOCATION_RISC1 | \
+					 QE_RISC_ALLOCATION_RISC2 | \
+					 QE_RISC_ALLOCATION_RISC3 | \
+					 QE_RISC_ALLOCATION_RISC4)
 
 /* QE extended filtering Table Lookup Key Size */
 enum qe_fltr_tbl_lookup_key_size {
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 01bce37..2533677 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -575,3 +575,31 @@ struct qe_firmware_info *qe_get_firmware_info(void)
 }
 EXPORT_SYMBOL(qe_get_firmware_info);
 
+unsigned int qe_get_num_of_risc(void)
+{
+	struct device_node *qe;
+	int size;
+	unsigned int num_of_risc = 0;
+	const u32 *prop;
+
+	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
+	if (!qe) {
+		/* Older devices trees did not have an "fsl,qe"
+		 * compatible property, so we need to look for
+		 * the QE node by name.
+		 */
+		qe = of_find_node_by_type(NULL, "qe");
+		if (!qe)
+			return num_of_risc;
+	}
+
+	prop = of_get_property(qe, "fsl,qe-num-riscs", &size);
+	if (prop && size == sizeof(*prop))
+		num_of_risc = *prop;
+
+	of_node_put(qe);
+
+	return num_of_risc;
+}
+EXPORT_SYMBOL(qe_get_num_of_risc);
+
-- 
1.6.0.2

^ permalink raw reply related

* Should ppc32 use CONFIG_HIGHPTE or not?
From: Dave Hansen @ 2009-05-01 18:37 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Paul Mackerras

arch/powerpc/mm/pgtable_32.c has the following function:

pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long address)
{
        struct page *ptepage;

#ifdef CONFIG_HIGHPTE
        gfp_t flags = GFP_KERNEL | __GFP_HIGHMEM | __GFP_REPEAT | __GFP_ZERO;
#else
        gfp_t flags = GFP_KERNEL | __GFP_REPEAT | __GFP_ZERO;
#endif
...

But there's no trace of CONFIG_HIGHPTE anywhere in arch/powerpc.  But,
the one and only definition on 32-bit of pte_offset_map() (in
arch/powerpc/include/asm/pgtable-ppc32.h) seems to have HIGHPTE
semantics:

#define pte_offset_map(dir, addr)               \
        ((pte_t *) kmap_atomic(pmd_page(*(dir)), KM_PTE0) + pte_index(addr))
#define pte_offset_map_nested(dir, addr)        \
        ((pte_t *) kmap_atomic(pmd_page(*(dir)), KM_PTE1) + pte_index(addr))

So, it looks like ppc32 never actually allocates highmem pte pages, but
it *does* go to the trouble of at least trying to kmap_atomic() them.
Should we just give ppc32 unconditional direct-mapped ptes?  Or, should
we remove that #ifdef and let it allocate them in highmem when it can
since we also have the code to support that?

-- Dave

^ permalink raw reply

* Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.
From: H. Peter Anvin @ 2009-05-01 17:47 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Tim Abbott, Heiko Carstens, linuxppc-dev, Paul Mackerras,
	Greg Ungerer, sparclinux, Thomas Gleixner, linux-s390,
	Jesper Nilsson, Yoshinori Sato, Helge Deller, Ingo Molnar,
	Geert Uytterhoeven, Russell King, user-mode-linux-devel,
	microblaze-uclinux, Jeff Dike, Jeff Arnold, dev-etrax,
	Mikael Starvik, Cyrill Gorcunov, Michal Simek, Waseem Daher,
	Richard Henderson, Chris Zankel, Bryan Wu, Tony Luck,
	linux-parisc, Haavard Skinnemoen, Hirokazu Takata,
	Linux kernel mailing list, Ralf Baechle, Anders Kaseorg,
	Kyle McMartin, Paul Mundt, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <20090501174457.GA26559@uranus.ravnborg.org>

Sam Ravnborg wrote:
>>
>> What's wrong with @?
> arm does not support it :-(
> I recall it denote a comment in arm assembler.
> 
> I could do some magic to detect the ARM case but I'm reluctant to do so.
> I could also ignore the arm issue for now as it is not used by arm,
> but that strikes me as the wrong approach.
> 

If we really have to use different tokens, I would say:

#ifdef __ARM__
# define _PROGBITS %progbits	/* or whatever */
# define _NOBITS   %nobits
#else
# define _PROGBITS @progbits
# define _NOBITS   @nobits
#endif

Otherwise we probably need to ask the binutils people...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

^ permalink raw reply

* Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.
From: Sam Ravnborg @ 2009-05-01 17:44 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Tim Abbott, Heiko Carstens, linuxppc-dev, Paul Mackerras,
	Greg Ungerer, sparclinux, Thomas Gleixner, linux-s390,
	Jesper Nilsson, Yoshinori Sato, Helge Deller, Ingo Molnar,
	Geert Uytterhoeven, Russell King, user-mode-linux-devel,
	microblaze-uclinux, Jeff Dike, Jeff Arnold, dev-etrax,
	Mikael Starvik, Cyrill Gorcunov, Michal Simek, Waseem Daher,
	Richard Henderson, Chris Zankel, Bryan Wu, Tony Luck,
	linux-parisc, Haavard Skinnemoen, Hirokazu Takata,
	Linux kernel mailing list, Ralf Baechle, Anders Kaseorg,
	Kyle McMartin, Paul Mundt, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <49FB2EDC.9050300@zytor.com>

On Fri, May 01, 2009 at 10:18:20AM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> > On Fri, May 01, 2009 at 09:33:13AM -0700, H. Peter Anvin wrote:
> >> Tim Abbott wrote:
> >>> On Fri, 1 May 2009, Sam Ravnborg wrote:
> >>>
> >>>> On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote:
> >>>>> +#define __PAGE_ALIGNED_DATA	.section ".data.page_aligned", "aw", @progbits
> >>>>> +#define __PAGE_ALIGNED_BSS	.section ".bss.page_aligned", "aw", @nobits
> >>>> It is my understanding that the linker will automatically
> >>>> assume nobits for section names starting with .bss and likewise
> >>>> progbits for section names starting with .data - so we can leave them out?
> >>> I believe that is correct.
> >>>
> >> ... but that doesn't mean it's the right thing to do.
> >>
> >> It's better to be fully explicit when macroizing this kind of stuff.
> >> This is part of why macroizing it is good: it means we end up with *one*
> >> place that determines this stuff, not some magic heuristics in the linker.
> > 
> > Do you know if we can use % in place of @?
> > I could see that gas supports both - at least in trunk in cvs.
> > 
> 
> I think it might depend on the architecture(!)... but it would
> definitely have to be an issue with testing a bunch of different versions.
> 
> What's wrong with @?
arm does not support it :-(
I recall it denote a comment in arm assembler.

I could do some magic to detect the ARM case but I'm reluctant to do so.
I could also ignore the arm issue for now as it is not used by arm,
but that strikes me as the wrong approach.


	Sam

^ permalink raw reply

* Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.
From: H. Peter Anvin @ 2009-05-01 17:18 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Tim Abbott, Heiko Carstens, linuxppc-dev, Paul Mackerras,
	Greg Ungerer, sparclinux, Thomas Gleixner, linux-s390,
	Jesper Nilsson, Yoshinori Sato, Helge Deller, Ingo Molnar,
	Geert Uytterhoeven, Russell King, user-mode-linux-devel,
	microblaze-uclinux, Jeff Dike, Jeff Arnold, dev-etrax,
	Mikael Starvik, Cyrill Gorcunov, Michal Simek, Waseem Daher,
	Richard Henderson, Chris Zankel, Bryan Wu, Tony Luck,
	linux-parisc, Haavard Skinnemoen, Hirokazu Takata,
	Linux kernel mailing list, Ralf Baechle, Anders Kaseorg,
	Kyle McMartin, Paul Mundt, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <20090501171717.GA26401@uranus.ravnborg.org>

Sam Ravnborg wrote:
> On Fri, May 01, 2009 at 09:33:13AM -0700, H. Peter Anvin wrote:
>> Tim Abbott wrote:
>>> On Fri, 1 May 2009, Sam Ravnborg wrote:
>>>
>>>> On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote:
>>>>> +#define __PAGE_ALIGNED_DATA	.section ".data.page_aligned", "aw", @progbits
>>>>> +#define __PAGE_ALIGNED_BSS	.section ".bss.page_aligned", "aw", @nobits
>>>> It is my understanding that the linker will automatically
>>>> assume nobits for section names starting with .bss and likewise
>>>> progbits for section names starting with .data - so we can leave them out?
>>> I believe that is correct.
>>>
>> ... but that doesn't mean it's the right thing to do.
>>
>> It's better to be fully explicit when macroizing this kind of stuff.
>> This is part of why macroizing it is good: it means we end up with *one*
>> place that determines this stuff, not some magic heuristics in the linker.
> 
> Do you know if we can use % in place of @?
> I could see that gas supports both - at least in trunk in cvs.
> 

I think it might depend on the architecture(!)... but it would
definitely have to be an issue with testing a bunch of different versions.

What's wrong with @?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

^ permalink raw reply

* [PATCH] Fix oprofile sampling of marked events on POWER7
From: Maynard Johnson @ 2009-05-01 17:17 UTC (permalink / raw)
  To: linuxppc-dev

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

Description
-----------
Change ppc64 oprofile kernel driver to use the SLOT bits (MMCRA[37:39]only on 
older processors where those bits are defined.

Background
----------
The performance monitor unit of the 64-bit POWER processor family has the 
ability to collect accurate instruction-level samples when profiling on marked 
events (i.e., "PM_MRK_<event-name>").  In processors prior to POWER6, the MMCRA 
register contained "slot information" that the oprofile kernel driver used to 
adjust the value latched in the SIAR at the time of a PMU interrupt.  But as of 
POWER6, these slot bits in MMCRA are no longer necessary for oprofile to use, 
since the SIAR itself holds the accurate sampled instruction address.  With 
POWER6, these MMCRA slot bits were zero'ed out by hardware so oprofile's use of 
these slot bits was, in effect, a NOP.  But with POWER7, these bits are no 
longer zero'ed out; however, they serve some other purpose rather than slot 
information.  Thus, using these bits on POWER7 to adjust the SIAR value results 
in samples being attributed to the wrong instructions.  The attached patch 
changes the oprofile kernel driver to ignore these slot bits on all newer 
processors starting with POWER6.

Thanks.
-Maynard

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

[-- Attachment #2: oprof-p7.patch --]
[-- Type: text/plain, Size: 1222 bytes --]

diff -paur linux/arch/powerpc/oprofile/op_model_power4.c linux-p7-oprofile-patch//arch/powerpc/oprofile/op_model_power4.c
--- linux/arch/powerpc/oprofile/op_model_power4.c	2009-05-01 08:20:21.000000000 -0500
+++ linux-p7-oprofile-patch//arch/powerpc/oprofile/op_model_power4.c	2009-05-01 08:20:05.000000000 -0500
@@ -26,6 +26,7 @@
 static unsigned long reset_value[OP_MAX_COUNTER];
 
 static int oprofile_running;
+static int use_slot_nums;
 
 /* mmcr values are set in power4_reg_setup, used in power4_cpu_setup */
 static u32 mmcr0_val;
@@ -61,6 +62,12 @@ static int power4_reg_setup(struct op_co
 	else
 		mmcr0_val |= MMCR0_PROBLEM_DISABLE;
 
+	if (__is_processor(PV_POWER4) || __is_processor(PV_POWER4p) ||
+	    __is_processor(PV_970) || __is_processor(PV_970FX) ||
+	    __is_processor(PV_970MP) || __is_processor(PV_970GX) ||
+	    __is_processor(PV_POWER5) || __is_processor(PV_POWER5p))
+		use_slot_nums = 1;
+
 	return 0;
 }
 
@@ -206,7 +213,7 @@ static unsigned long get_pc(struct pt_re
 
 	mmcra = mfspr(SPRN_MMCRA);
 
-	if (mmcra & MMCRA_SAMPLE_ENABLE) {
+	if (use_slot_nums && (mmcra & MMCRA_SAMPLE_ENABLE)) {
 		slot = ((mmcra & MMCRA_SLOT) >> MMCRA_SLOT_SHIFT);
 		if (slot > 1)
 			pc += 4 * (slot - 1);

^ permalink raw reply

* Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.
From: Sam Ravnborg @ 2009-05-01 17:17 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Tim Abbott, Heiko Carstens, linuxppc-dev, Paul Mackerras,
	Greg Ungerer, sparclinux, Thomas Gleixner, linux-s390,
	Jesper Nilsson, Yoshinori Sato, Helge Deller, Ingo Molnar,
	Geert Uytterhoeven, Russell King, user-mode-linux-devel,
	microblaze-uclinux, Jeff Dike, Jeff Arnold, dev-etrax,
	Mikael Starvik, Cyrill Gorcunov, Michal Simek, Waseem Daher,
	Richard Henderson, Chris Zankel, Bryan Wu, Tony Luck,
	linux-parisc, Haavard Skinnemoen, Hirokazu Takata,
	Linux kernel mailing list, Ralf Baechle, Anders Kaseorg,
	Kyle McMartin, Paul Mundt, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <49FB2449.1010301@zytor.com>

On Fri, May 01, 2009 at 09:33:13AM -0700, H. Peter Anvin wrote:
> Tim Abbott wrote:
> > On Fri, 1 May 2009, Sam Ravnborg wrote:
> > 
> >> On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote:
> >>> +#define __PAGE_ALIGNED_DATA	.section ".data.page_aligned", "aw", @progbits
> >>> +#define __PAGE_ALIGNED_BSS	.section ".bss.page_aligned", "aw", @nobits
> >> It is my understanding that the linker will automatically
> >> assume nobits for section names starting with .bss and likewise
> >> progbits for section names starting with .data - so we can leave them out?
> > 
> > I believe that is correct.
> > 
> 
> ... but that doesn't mean it's the right thing to do.
> 
> It's better to be fully explicit when macroizing this kind of stuff.
> This is part of why macroizing it is good: it means we end up with *one*
> place that determines this stuff, not some magic heuristics in the linker.

Do you know if we can use % in place of @?
I could see that gas supports both - at least in trunk in cvs.

	Sam

^ permalink raw reply

* Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.
From: H. Peter Anvin @ 2009-05-01 16:33 UTC (permalink / raw)
  To: Tim Abbott
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Heiko Carstens, linuxppc-dev, Paul Mackerras, Greg Ungerer,
	sparclinux, Sam Ravnborg, Thomas Gleixner, linux-s390,
	Jesper Nilsson, Yoshinori Sato, Helge Deller, Ingo Molnar,
	Geert Uytterhoeven, Russell King, user-mode-linux-devel,
	microblaze-uclinux, Jeff Dike, Jeff Arnold, dev-etrax,
	Mikael Starvik, Cyrill Gorcunov, Michal Simek, Waseem Daher,
	Richard Henderson, Chris Zankel, Bryan Wu, Tony Luck,
	linux-parisc, Haavard Skinnemoen, Hirokazu Takata,
	Linux kernel mailing list, Ralf Baechle, Anders Kaseorg,
	Kyle McMartin, Paul Mundt, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <alpine.DEB.1.10.0905010951100.3955@vinegar-pot.mit.edu>

Tim Abbott wrote:
> On Fri, 1 May 2009, Sam Ravnborg wrote:
> 
>> On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote:
>>> +#define __PAGE_ALIGNED_DATA	.section ".data.page_aligned", "aw", @progbits
>>> +#define __PAGE_ALIGNED_BSS	.section ".bss.page_aligned", "aw", @nobits
>> It is my understanding that the linker will automatically
>> assume nobits for section names starting with .bss and likewise
>> progbits for section names starting with .data - so we can leave them out?
> 
> I believe that is correct.
> 

... but that doesn't mean it's the right thing to do.

It's better to be fully explicit when macroizing this kind of stuff.
This is part of why macroizing it is good: it means we end up with *one*
place that determines this stuff, not some magic heuristics in the linker.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

^ permalink raw reply

* Re: Using archaic I2C with OF
From: Gary Thomas @ 2009-05-01 16:08 UTC (permalink / raw)
  To: Wolfram Sang; +Cc: Linux PPC Development
In-Reply-To: <20090501160403.GA7943@pengutronix.de>

Wolfram Sang wrote:
>> Post this on the i2c list. Jean has made an effort to convert all
>> drivers. He must have missed that one.
> 
> What Jean did was converting all drivers who used the legacy i2c-binding to use
> the new binding which is a lot better suited to the driver model. The above
> mentioned driver already uses the new binding.
> 
> The problem coming up here is another issue and also long standing and not yet
> solved. There are drivers which require platform_data with function pointers.
> You cannot encode function pointers to the device tree.
> 
> One solution is to create a custom driver for your board with the needed
> specific function and create a platform device from there. Sometimes it
> works to add a bit more info to the device tree (e.g. some gpios) and
> parse it via an of_wrapper around the platform driver.

Pretty much as I expected.

Are there examples of how to do this?  In particular how to
correlate a GPIO (with interrupt) to another (I2C) device?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply

* Re: Using archaic I2C with OF
From: Wolfram Sang @ 2009-05-01 16:04 UTC (permalink / raw)
  To: Jon Smirl; +Cc: Linux PPC Development, Gary Thomas
In-Reply-To: <9e4733910905010755g595d686fmf075a40d6012e3fc@mail.gmail.com>

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

> Post this on the i2c list. Jean has made an effort to convert all
> drivers. He must have missed that one.

What Jean did was converting all drivers who used the legacy i2c-binding to use
the new binding which is a lot better suited to the driver model. The above
mentioned driver already uses the new binding.

The problem coming up here is another issue and also long standing and not yet
solved. There are drivers which require platform_data with function pointers.
You cannot encode function pointers to the device tree.

One solution is to create a custom driver for your board with the needed
specific function and create a platform device from there. Sometimes it
works to add a bit more info to the device tree (e.g. some gpios) and
parse it via an of_wrapper around the platform driver.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

^ permalink raw reply

* [PATCH] powerpc/boot: add simpleImage.* to clean-files list
From: Grant Likely @ 2009-05-01 15:54 UTC (permalink / raw)
  To: linuxppc-dev, benh

From: Grant Likely <grant.likely@secretlab.ca>

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

 arch/powerpc/boot/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4458abb..bff7f12 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -367,7 +367,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
 clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
 	zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
 	zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
-	otheros.bld *.dtb
+	simpleImage.* otheros.bld *.dtb
 
 # clean up files cached by wrapper
 clean-kernel := vmlinux.strip vmlinux.bin

^ permalink raw reply related

* Re: [PATCH 6/6] Add support for __read_mostly to linux/cache.h
From: Christoph Lameter @ 2009-05-01 13:52 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Greg Ungerer, Heiko Carstens, linuxppc-dev, Paul Mackerras,
	H. Peter Anvin, sparclinux, Thomas Gleixner, linux-arm-kernel,
	linux-s390, Jesper Nilsson, linux-am33-list, Yoshinori Sato,
	Helge Deller, Ingo Molnar, Geert Uytterhoeven, Russell King,
	user-mode-linux-devel, microblaze-uclinux, Jeff Dike, Jeff Arnold,
	dev-etrax, Mikael Starvik, Tony Luck, Cyrill Gorcunov,
	Michal Simek, Waseem Daher, Richard Henderson, Chris Zankel,
	Bryan Wu, linux-m32r, linux-parisc, Haavard Skinnemoen,
	Hirokazu Takata, Tim Abbott, Ralf Baechle, Anders Kaseorg,
	Kyle McMartin, Paul Mundt, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <20090501094407.GD18326@uranus.ravnborg.org>

On Fri, 1 May 2009, Sam Ravnborg wrote:

> Are there any specific reason why we do not support read_mostly on all
> architectures?

Not that I know of.

> read_mostly is about grouping rarely written data together
> so what is needed is to introduce this section in the remaining
> archtectures.
>
> Christoph - git log says you did the inital implmentation.
> Do you agree?

Yes.

There is some concern that __read_mostly is needlessly applied to
numerous variables that are not used in hot code paths. This may make
__read_mostly ineffective and actually increase the cache footprint of a
function since global variables are no longer in the same cacheline. If
such a function is called and the caches are cold then two cacheline
fetches have to be done instead of one.

^ permalink raw reply

* Re: Using archaic I2C with OF
From: Jon Smirl @ 2009-05-01 14:55 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <49FB0C3B.3000209@mlbassoc.com>

On Fri, May 1, 2009 at 10:50 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> Jon Smirl wrote:
>> On Fri, May 1, 2009 at 10:39 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>> On Fri, May 1, 2009 at 9:04 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>> I'd like to use an existing I2C driver (a touchscreen device)
>>>> with my 834x based platform. =A0How do I arrange to provide
>>>> platform data (i2c_client->dev.platform_data) from my OF world?
>>> It is easier to convert the i2c driver to work in the current model.
>>
>> All in-tree drivers have already been converted.
>
> I'm looking at drivers/input/touchscreen/tsc2007.c (the one I need)
> from Kumar's 'next' tree. =A0It most definitely still uses the old
> model.
>
> Can you suggest another place to look?

Post this on the i2c list. Jean has made an effort to convert all
drivers. He must have missed that one.

>
> --
> ------------------------------------------------------------
> Gary Thomas =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Consulting for the
> MLB Associates =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Embedded world
> ------------------------------------------------------------
>



--=20
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* mmap dma address
From: Gabriel Johnson @ 2009-05-01 15:03 UTC (permalink / raw)
  To: linuxppc-dev

Could someone tell me how to mmap a dma buffer allocated with
dma_alloc_coherent?  I have found some patches that Takashi Iwai
submitted to create a dma_mmap_coherent function but it doesn't look
like its been accepted upstream, is there a reason why?  Is there a
better way for mmaping a dma address?  I am trying to get mmaping
working on a mpc5121e i2s audio driver so that I can do alsa audio
mixing.

Thanks,
Gabe

^ permalink raw reply

* Re: Using archaic I2C with OF
From: Gary Thomas @ 2009-05-01 14:50 UTC (permalink / raw)
  To: Jon Smirl; +Cc: Linux PPC Development
In-Reply-To: <9e4733910905010739p6c4fddf3oab1b583b72df4eeb@mail.gmail.com>

Jon Smirl wrote:
> On Fri, May 1, 2009 at 10:39 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Fri, May 1, 2009 at 9:04 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>> I'd like to use an existing I2C driver (a touchscreen device)
>>> with my 834x based platform.  How do I arrange to provide
>>> platform data (i2c_client->dev.platform_data) from my OF world?
>> It is easier to convert the i2c driver to work in the current model.
> 
> All in-tree drivers have already been converted.

I'm looking at drivers/input/touchscreen/tsc2007.c (the one I need)
from Kumar's 'next' tree.  It most definitely still uses the old
model.

Can you suggest another place to look?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply

* Re: Using archaic I2C with OF
From: Jon Smirl @ 2009-05-01 14:39 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <9e4733910905010739q4038555ck211ee61b9b443f01@mail.gmail.com>

On Fri, May 1, 2009 at 10:39 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Fri, May 1, 2009 at 9:04 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>> I'd like to use an existing I2C driver (a touchscreen device)
>> with my 834x based platform. =A0How do I arrange to provide
>> platform data (i2c_client->dev.platform_data) from my OF world?
>
> It is easier to convert the i2c driver to work in the current model.

All in-tree drivers have already been converted.

>
> --
> Jon Smirl
> jonsmirl@gmail.com
>

--=20
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Using archaic I2C with OF
From: Jon Smirl @ 2009-05-01 14:39 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <49FAF351.4010409@mlbassoc.com>

On Fri, May 1, 2009 at 9:04 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> I'd like to use an existing I2C driver (a touchscreen device)
> with my 834x based platform. =A0How do I arrange to provide
> platform data (i2c_client->dev.platform_data) from my OF world?

It is easier to convert the i2c driver to work in the current model.

--=20
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [PATCH v2 0/6] macros for section name cleanup
From: Sam Ravnborg @ 2009-05-01 14:21 UTC (permalink / raw)
  To: Tim Abbott
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Greg Ungerer, Jeff Arnold, linuxppc-dev, Paul Mackerras,
	H. Peter Anvin, sparclinux, Waseem Daher, linux-s390,
	Jesper Nilsson, Yoshinori Sato, Helge Deller, Ingo Molnar,
	Geert Uytterhoeven, microblaze-uclinux, Russell King,
	user-mode-linux-devel, Heiko Carstens, Jeff Dike, dev-etrax,
	Mikael Starvik, Cyrill Gorcunov, Michal Simek, Richard Henderson,
	Chris Zankel, Bryan Wu, Tony Luck, linux-parisc,
	Haavard Skinnemoen, Hirokazu Takata, Linux kernel mailing list,
	Ralf Baechle, Anders Kaseorg, Kyle McMartin, Paul Mundt,
	Thomas Gleixner, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <1241121253-32341-1-git-send-email-tabbott@mit.edu>

On Thu, Apr 30, 2009 at 03:54:07PM -0400, Tim Abbott wrote:
> (this patch series differs from v1 only in the CC list; some of the
> architecture lists I sent the previous one to are moderated against
> non-members; all replies should go to this version).
> 
> Here are the architecture-independent macro definitions needed for
> to clean up the kernel's section names.  The overall diffstat from
> this section name cleanup project is:
> 
>  96 files changed, 261 insertions(+), 503 deletions(-)
> 
> The decrease results from removing a lot of redundancy in the linker
> scripts.
> 
> The long-term goal here is to add support for building the kernel with
> -ffunction-sections -fdata-sections.  This requires renaming all the
> magic section names in the kernel of the form .text.foo, .data.foo,
> .bss.foo, and .rodata.foo to not have collisions with sections
> generated for code like:
> 
> static int nosave = 0; /* -fdata-sections places in .data.nosave */
> static void head(); /* -ffunction-sections places in .text.head */
> 
> Sam Ravnborg proposed that rather than just renaming all the sections
> outright, we should start by first getting more control over the
> section names used in the kernel so that we can later rename sections
> without touching too many files.  These patch series implement that
> cleanup.  Later, there will be another patch series to actually rename
> the sections.
> 
> I'm hoping we can get just these macro definitions into 2.6.30 so that
> the arch maintainers don't have to grab the macro definitions for
> their trees while reviewing the patches for 2.6.31.
> 
> Shortly, I'm going to send one patch series for each of the
> architectures updating those architectures to use these new macros
> (and otherwise cleaning up section names on those architectures).
> 
> 	-Tim Abbott
> 
> Tim Abbott (6):
>   Add new macros for page-aligned data and bss sections.
>   Add new NOSAVE_DATA linker script macro.
>   Add new CACHELINE_ALIGNED_DATA linker script macro.
>   Add new INIT_TASK_DATA() linker script macro.
>   Add new READ_MOSTLY_DATA(align) linker script macro.

I am about to apply this part of your patches.
I am doing some additional modifications and
will most likely apply them as one patch.

Will post to linux-arch for review when it is ready.

	Sam

^ permalink raw reply

* Re: [PATCH 1/2] Add support for Designware SATA controller driver
From: Jeff Garzik @ 2009-05-01 14:07 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Feng Kan, linux-ide
In-Reply-To: <1241167748.1781.3.camel@pasglop>

Benjamin Herrenschmidt wrote:
> Patch 2/2 is just adding the device-tree bits to the platform for
> this driver to match against, so it's no big deal. However, Feng,
> we already mentioned that you do a lot of unrelated changes to the
> Kconfig file that shouldn't be part of this patch, just add the
> entry for this chip, don't move stuff around in Kconfig, unless I
> missed a good reason why this is done that way.


Quite correct -- those drivers/ata/Kconfig changes are bogus.

	Jeff

^ permalink raw reply

* Re: [PATCH v2 1/6] Add new macros for page-aligned data and bss sections.
From: Tim Abbott @ 2009-05-01 13:54 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Greg Ungerer, Jeff Arnold, linuxppc-dev, Paul Mackerras,
	H. Peter Anvin, sparclinux, Waseem Daher, linux-s390,
	Jesper Nilsson, Yoshinori Sato, Helge Deller, Ingo Molnar,
	Geert Uytterhoeven, microblaze-uclinux, Russell King,
	user-mode-linux-devel, Heiko Carstens, Jeff Dike, dev-etrax,
	Mikael Starvik, Cyrill Gorcunov, Michal Simek, Richard Henderson,
	Chris Zankel, Bryan Wu, Tony Luck, linux-parisc,
	Haavard Skinnemoen, Hirokazu Takata, Linux kernel mailing list,
	Ralf Baechle, Anders Kaseorg, Kyle McMartin, Paul Mundt,
	Thomas Gleixner, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <20090501091848.GB18326@uranus.ravnborg.org>

On Fri, 1 May 2009, Sam Ravnborg wrote:

> On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote:
> > +#define __PAGE_ALIGNED_DATA	.section ".data.page_aligned", "aw", @progbits
> > +#define __PAGE_ALIGNED_BSS	.section ".bss.page_aligned", "aw", @nobits
> 
> It is my understanding that the linker will automatically
> assume nobits for section names starting with .bss and likewise
> progbits for section names starting with .data - so we can leave them out?

I believe that is correct.

	-Tim Abbott

^ permalink raw reply

* Using archaic I2C with OF
From: Gary Thomas @ 2009-05-01 13:04 UTC (permalink / raw)
  To: Linux PPC Development

I'd like to use an existing I2C driver (a touchscreen device)
with my 834x based platform.  How do I arrange to provide
platform data (i2c_client->dev.platform_data) from my OF world?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply

* Re: [PATCH] powerpc: fix mktree build error on Mac OS X host
From: Josh Boyer @ 2009-05-01 12:47 UTC (permalink / raw)
  To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1241151404-5274-1-git-send-email-timur@freescale.com>

On Thu, Apr 30, 2009 at 11:16:44PM -0500, Timur Tabi wrote:
>The mktree utility defines some variables as "uint", although this is not a
>standard C type, and so cross-compiling on Mac OS X fails.  Change this to
>"unsigned int".
>
>Signed-off-by: Timur Tabi <timur@freescale.com>

I believe this is only used by the 4xx boards anyway.

Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

>---
> arch/powerpc/boot/mktree.c |   10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/arch/powerpc/boot/mktree.c b/arch/powerpc/boot/mktree.c
>index 45d06a8..c2baae0 100644
>--- a/arch/powerpc/boot/mktree.c
>+++ b/arch/powerpc/boot/mktree.c
>@@ -42,7 +42,7 @@ int main(int argc, char *argv[])
> {
> 	int	in_fd, out_fd;
> 	int	nblks, i;
>-	uint	cksum, *cp;
>+	unsigned int	cksum, *cp;
> 	struct	stat	st;
> 	boot_block_t	bt;
> 
>@@ -90,7 +90,7 @@ int main(int argc, char *argv[])
> 
> 	cksum = 0;
> 	cp = (void *)&bt;
>-	for (i=0; i<sizeof(bt)/sizeof(uint); i++)
>+	for (i = 0; i < sizeof(bt) / sizeof(unsigned int); i++)
> 		cksum += *cp++;
> 
> 	/* Assume zImage is an ELF file, and skip the 64K header.
>@@ -101,7 +101,7 @@ int main(int argc, char *argv[])
> 		exit(4);
> 	}
> 
>-	if ((*(uint *)tmpbuf) != htonl(0x7f454c46)) {
>+	if ((*(unsigned int *)tmpbuf) != htonl(0x7f454c46)) {
> 		fprintf(stderr, "%s is not an ELF image\n", argv[1]);
> 		exit(4);
> 	}
>@@ -125,8 +125,8 @@ int main(int argc, char *argv[])
> 			perror("zImage read");
> 			exit(5);
> 		}
>-		cp = (uint *)tmpbuf;
>-		for (i=0; i<sizeof(tmpbuf)/sizeof(uint); i++)
>+		cp = (unsigned int *)tmpbuf;
>+		for (i = 0; i < sizeof(tmpbuf) / sizeof(unsigned int); i++)
> 			cksum += *cp++;
> 		if (write(out_fd, tmpbuf, sizeof(tmpbuf)) != sizeof(tmpbuf)) {
> 			perror("boot-image write");
>-- 
>1.6.2.4
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Re: [PATCH 6/6] Add support for __read_mostly to linux/cache.h
From: Sam Ravnborg @ 2009-05-01  9:44 UTC (permalink / raw)
  To: Tim Abbott, Christoph Lameter
  Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Denys Vlasenko,
	Greg Ungerer, Jeff Arnold, linuxppc-dev, Paul Mackerras,
	H. Peter Anvin, sparclinux, Waseem Daher, linux-arm-kernel,
	linux-s390, Jesper Nilsson, linux-am33-list, Yoshinori Sato,
	Helge Deller, Ingo Molnar, Geert Uytterhoeven, microblaze-uclinux,
	Russell King, user-mode-linux-devel, Heiko Carstens, Jeff Dike,
	dev-etrax, Mikael Starvik, Tony Luck, Cyrill Gorcunov,
	Michal Simek, Richard Henderson, Chris Zankel, Bryan Wu,
	linux-m32r, linux-parisc, Haavard Skinnemoen, Hirokazu Takata,
	Ralf Baechle, Anders Kaseorg, Kyle McMartin, Paul Mundt,
	Thomas Gleixner, linux-alpha, Martin Schwidefsky,
	uclinux-dist-devel, Linus Torvalds, David S. Miller
In-Reply-To: <1241119956-31453-7-git-send-email-tabbott@mit.edu>

On Thu, Apr 30, 2009 at 03:32:36PM -0400, Tim Abbott wrote:
> Signed-off-by: Tim Abbott <tabbott@mit.edu>
> ---
>  include/linux/cache.h |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/cache.h b/include/linux/cache.h
> index 97e2488..99d8a6f 100644
> --- a/include/linux/cache.h
> +++ b/include/linux/cache.h
> @@ -13,7 +13,13 @@
>  #endif
>  
>  #ifndef __read_mostly
> +#ifdef CONFIG_HAVE_READ_MOSTLY_DATA
> +#define __read_mostly __attribute__((__section__(".data.read_mostly")))
> +#define __READ_MOSTLY .section ".data.read_mostly", "aw"
> +#else
>  #define __read_mostly
> +#define __READ_MOSTLY
> +#endif /* CONFIG_HAVE_READ_MOSTLY_DATA */
>  #endif

Are there any specific reason why we do not support read_mostly on all
architectures?

read_mostly is about grouping rarely written data together
so what is needed is to introduce this section in the remaining
archtectures.

Christoph - git log says you did the inital implmentation.
Do you agree?

	Sam

^ 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