How to dynamically disable/enable CPU features?

[Gerhard Pircher]

Hi,

-------- Original-Nachricht --------
> Datum: Fri, 22 Feb 2008 11:24:38 -0600
> Von: Milton Miller <miltonm at bga.com>
> An: Gerhard Pircher <gerhard_pircher at gmx.net>
> CC: ppcdev <linuxppc-dev at ozlabs.org>
> Betreff: Re: How to dynamically disable/enable CPU features?

> We handle cpu features in a couple of ways:
> (1) we replace assembly instructions with nop early in the kernel boot
I'm pretty sure that is the problem.

> (2) we test the feature flags in c code
> 
> In (2), we form two expressions for features that are
> (a) always set
> (b) never set
> so that the compiler can eliminate the test based on the config.
> 
> To change a flag, you must make sure its in POSSIBLE but not ALWAYS, 
> and also set it before it is used, either to nop out instructions (see 
> early_init in setup-32.c for 32 bit), or tested by c code (in this 
> case, maybe the initial_mmu setup is testing NEED_COHERENT, which is 
> between early_init and probe). The code path is a bit different for 64
> bit.
The flag is in POSSIBLE. I now use this code in the platform probe
function to nop out the code affected by the flag:

cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
/* Patch out unwanted feature. */
do_feature_fixups(cur_cpu_spec->cpu_features,
		  PTRRELOC(&__start___ftr_fixup),
		  PTRRELOC(&__stop___ftr_fixup));

It seems to work so far, but I would like to know if this is the right
way to do it, or if calling do_feature_fixups() more than once can have
any side effects.

regards,

Gerhard
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger