3rd, and hopefully final, MIPS 24K hwpmc patch...

[M. Warner Losh]

In message: <BD8E018D-68E9-4566-BB0F-D52B84A62C11 at freebsd.org>
            Rui Paulo <rpaulo at FreeBSD.org> writes:
: > http://people.freebsd.org/~gnn/mipshwpmc_3.diff
: > 
: > The biggest change was breaking out MIPS24K from generic MIPS, which will allow for the easy addition
: > of other types of MIPS chips in the near future.

@@ -2681,6 +2724,10 @@
 	} else if (pe >= PMC_EV_XSCALE_FIRST && pe <= PMC_EV_XSCALE_LAST) {
 		ev = xscale_event_table;
 		evfence = xscale_event_table + PMC_EVENT_TABLE_SIZE(xscale);
+	} else if (pe >= PMC_EV_MIPS24K_FIRST && pe <= PMC_EV_MIPS24K_LAST) {
+		ev = mips24k_event_table;
+		evfence = mips24k_event_table + PMC_EVENT_TABLE_SIZE(mips24k
+);

Looks like a stray new line.

There does seem to be a number of places where we mix mips, arm, and
x86 CPUs in case statements and the like.  Yet there are other places
we carefully ifdef them.  What's the determining factors here?

Also, the mips24k counters are specific to the mips24k, but the
harvesting of the counters is fairly generic to the mips architecture
(when counters are present).  Why encode all the counter knowledge in
the kernel when it might make better sense to have the userland
routines do that decoding based on the core that's used?  Maybe I'm
misunderstanding something here, but I do know that linux asks the CPU
how many performance counters there are and harvests them generically
across a wide range of MIPS cores.

Warner