Kumar Gala wrote:
On Mar 18, 2008, at 12:05 PM, Scott Wood wrote:
On Fri, Mar 07, 2008 at 05:59:03PM -0600, Andy Fleming wrote:
Not all e300 cores support the performance monitors, and the ones
that don't will be confused by the mf/mtpmr instructions. This
allows the support to be optional, so the 8349 can turn it off
while the 8379 can turn it on. Sadly, those aren't config options,
so it will be left to the defconfigs and the users to make that
determination.
So does this mean we can't do multiplatform of something with perfmon and
something without perfmon? Seems like this should come from the device
tree, or PVR, or some other runtime check.
It possible if your binutils supports generating the instructions. I
believe Kim was going to look at doing a patch to use a #define
MFPMR(x)/#define MTPMR() so we don't have to worry about toolchain
versions.
- k
Hi Kumar, Scott,
Per Andy (and my limited reading of the UMs), some 83xx have the PMR
registers and some don't. The compiler either supports the PMR register
or it doesn't. If you make it runtime configurable, people running CPUs
that don't support the specific PMR will have to change compiler
configurations in order to compile with the PMR register in there (could
have unintended consequences).
Also, if you look at the code (arch/powerpc/kernel/pmc.c), there are
several different types of PMR registers, based on the core and flavor
of the core. Finding or making a compiler setup that supports all of
the possible PMR registers could be a problem.
You would still have to make the PMR read/write runtime selectable
because the CPUs that don't support that register will raise an
exception IIRC (an Really Bad Thing[tm]).
It crossed my mind /very briefly/ to use the FDT to select this but was
not willing to put that much effort into it.
* Toolchain issues (first & second objection, above) - non-trivial
* Would have to read the enable/disable into a static (global?) variable
to minimize the time impact for the runtime decision - ugh
* Need to add yet another definition to the booting-without-of.txt
(bwoof) and appropriate .dts files - OK, I'm lazy
Best regards,
gvb
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
