Re: [RFC PATCH 05/10] alpha: Primitive support for CPU power down.

[Richard Henderson <rth@twiddle.net>]

On 07/16/2013 10:17 PM, Matt Turner wrote:
> On Tue, Jul 16, 2013 at 10:34 AM, Richard Henderson <rth@twiddle.net> wrote:
>> Use WTINT to wait for the next interrupt.  Squash the WTINT call
>> if the PALcode doesn't support it (e.g. MILO).  No attempt is yet
>> made to skip clock ticks during normal scheduling in order to stay
>> in power down mode longer.
> 
> The architecture reference manual says
> 
>> The counter, PCC, may increment at a lower rate or may stop entirely
>> during wtint execution. This side effect is implementation dependent.
> 
> Is that anything to worry about?

Hmm, yes.  It means that we can't use both this and rpcc as a clocksource.
Which we can't do while SMP either, so perhaps that's not so bad.  So, right
now, with an SMP EV6 system we ought not worry.  Care to report whether that
hypothesis is true?

It may well be a tradeoff we want to CONFIG though, since nothing in the EV5
thru PCA56 can make use of the power down state, and were often uniprocessor
systems...

>> @@ -243,6 +243,18 @@ do_entIF(unsigned long type, struct pt_regs *regs)
>>                                (const char *)(data[1] | (long)data[2] << 32),
>>                                data[0]);
>>                 }
>> +               if (type == 4) {
>> +                       /* If CALL_PAL WTINT is not supported by the PALcode,
>> +                          "emulate" it by overwriting the insn.  */
> 
> The pseudo-code for WTINT contains an IF(implemented) check, where the
> ELSE case just does v0 <- 0. So is overwriting with nop just an
> optimization to avoid the (expensive) PAL call? If it is, could we
> clarify the comment?

No, notice where this code is: entIF, aka SIGILL.  Looking at MILO sources
I can tell you that WTINT isn't implemented at all.  Overwriting with the
mov insn is what I call "emulating" the unimplemented PALcall.


r~