ppc32 MMCR0_PMXE saga.

ppc32 MMCR0_PMXE saga.

[Dave Jones]

I'm at a loss to explain whats been happening with this symbol.


ChangeSet 1.2370, 2005/01/11 17:41:32-08:00, tglx@linutronix.de

    [PATCH] ppc: remove duplicate define

    The MMCR0_PMXE is already defined in reg.h, so no need to redefine it here.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ChangeSet 1.2514, 2005/01/12 09:02:21-08:00, dwmw2@infradead.org

    [PATCH] ppc: fix removed MMCR0_PMXE define

    In ChangeSet 1.2370, 2005/01/11 17:41:32-08:00, tglx@linutronix.de wrote:
    >
    >         [PATCH] ppc: remove duplicate define
    >
    >         The MMCR0_PMXE is already defined in reg.h...

    Er, no it's not. But perhaps it should be...

ChangeSet 1.1992.2.33, 2005/02/02 08:36:04-08:00, albert_herranz@yahoo.es

    [PATCH] ppc32: perfctl-ppc: fix duplicate mmcr0 define

    Fix a compilation warning due to a duplicate definition of MMCR0_PMXE.

    The definition comes in perfctr-ppc.patch, but was recently introduced too
    in Linus tree.

    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>


Clearly it *is* needed, as without it, this happens ..

arch/ppc/kernel/perfmon.c:55: error: `MMCR0_PMXE' undeclared (first use in this function)

grep shows no occurances of MMCR0_PMXE in include/asm-ppc that I can
see, so that last changeset is very confusing.

		Dave

Unbreak ppc32 perfctr build.

Signed-off-by: Dave Jones <davej@redhat.com>


--- linux-2.6.10/include/asm-ppc/reg.h~	2005-02-02 23:28:14.000000000 -0500
+++ linux-2.6.10/include/asm-ppc/reg.h	2005-02-02 23:28:36.000000000 -0500
@@ -333,6 +333,7 @@
 #define MMCR0_PMC2_CYCLES	0x1
 #define MMCR0_PMC2_ITLB		0x7
 #define MMCR0_PMC2_LOADMISSTIME	0x5
+#define MMCR0_PMXE	(1 << 26)
 
 /* Short-hand versions for a number of the above SPRNs */
 #define CTR	SPRN_CTR	/* Counter Register */

Re: ppc32 MMCR0_PMXE saga.

[Thomas Gleixner]

On Wed, 2005-02-02 at 23:47 -0500, Dave Jones wrote:
> I'm at a loss to explain whats been happening with this symbol.

The macro was duplicated in -mm1.
I sent a patch against -mm1
The patch went upstream without the perfctr-ppc.patch, which contained
the macro define in regs.h.

So a bit of confusion came up

tglx

Re: ppc32 MMCR0_PMXE saga.

[Albert Herranz]

 --- Dave Jones <davej@redhat.com> escribió: 
> I'm at a loss to explain whats been happening with
> this symbol.

My patch was against the -mm series, as reported in
the original subject.

In the -mm series, the perfctr-ppc.patch already
defines that symbol. As that patch contains all the
perfctr related bits, it made sense to remove the
definition coming from the Linus tree and keep the
definition from the perfctr-ppc.patch. But just on
-mm.

Cheers,
Albert



		
______________________________________________ 
Renovamos el Correo Yahoo!: ¡250 MB GRATIS! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es

Re: ppc32 MMCR0_PMXE saga.

[Mikael Pettersson]

Thomas Gleixner writes:
 > On Wed, 2005-02-02 at 23:47 -0500, Dave Jones wrote:
 > > I'm at a loss to explain whats been happening with this symbol.
 > 
 > The macro was duplicated in -mm1.
 > I sent a patch against -mm1
 > The patch went upstream without the perfctr-ppc.patch, which contained
 > the macro define in regs.h.
 > 
 > So a bit of confusion came up

The sane thing to do is to split -mm's perfctr-ppc.patch so that
the new symbolic constants can go into -linus w/o having to drag
in the experimental perfctr stuff from -mm.

This wasn't an issue before because the -linus kernel didn't
acquire any use of PMXE until very recently.

/Mikael

Re: ppc32 MMCR0_PMXE saga.

[Andrew Morton]

Mikael Pettersson <mikpe@csd.uu.se> wrote:
>
> Thomas Gleixner writes:
>   > On Wed, 2005-02-02 at 23:47 -0500, Dave Jones wrote:
>   > > I'm at a loss to explain whats been happening with this symbol.
>   > 
>   > The macro was duplicated in -mm1.
>   > I sent a patch against -mm1
>   > The patch went upstream without the perfctr-ppc.patch, which contained
>   > the macro define in regs.h.
>   > 
>   > So a bit of confusion came up
> 
>  The sane thing to do is to split -mm's perfctr-ppc.patch so that
>  the new symbolic constants can go into -linus w/o having to drag
>  in the experimental perfctr stuff from -mm.

ah, so that's what happened.

I'll tweak perfctr-ppc.patch for now.