Re: [PATCH v2] Make 83xx perfmon support selectable

[Jerry Van Baren <gvb.linuxppc.dev@gmail.com>]

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