I'm at a loss to explain whats been happening with this symbol.
ChangeSet 1.2370, 2005/01/11 17:41:32-08:00, [email protected]
[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 <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
ChangeSet 1.2514, 2005/01/12 09:02:21-08:00, [email protected]
[PATCH] ppc: fix removed MMCR0_PMXE define
In ChangeSet 1.2370, 2005/01/11 17:41:32-08:00, [email protected] 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, [email protected]
[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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
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 <[email protected]>
--- 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 */
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
--- Dave Jones <[email protected]> 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
Mikael Pettersson <[email protected]> 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.
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