[ECOS] On demand FP context switch major problem.

[Sergei Organov]

I agree with your (random) thoughts. However for me it seems that on-demand
context switch is incompatible with ability to use of the floating point in
ISRs/DSRs. I actually even didn't start to try to implement this capability
when on-demand FP context switch is configured, but it seems that if
implemented, then *any* interrupt could clear FP bit in MSR, and thus the fact 
that scheduler is locked in the DSR code doesn't help :-(

Is the capability to use FP in ISRs/DSRs significant enough to deny on-demand
context switch implementation on the PowerPC?

Nick Garnett <nickg@cygnus.co.uk> writes:
> Sergei Organov <osv@javad.ru> writes:
> 
> > Nick,
> > 
> > I was very busy last two weeks, but now when I've got a chance to return to
> > the FP implementation, I've found another related problem.
> > 
> > The default interrupt handler calls 'hal_cpu_int_disable' close to the end of
> > the ISR processing. If I disable FP there, then *every* interrupt will result
> > in disabling of FP, that is obviously unacceptable. 
> > 
> > Yet another similar place is in the
> > 'hal_interrupt_stack_call_pending_DSRs' that restores interrupt settings
> > before return.
> > 
> > Do you see a way to handle above cases?
> 
> 
> I haven't thought a lot of this through, but here are some (random)
> thoughts:
> 
> There is no reason why the asm level macros should behave the same way
> as the user level ones do. These are all used in very specialized
> places where it may not matter. Looking at the code,apart from the
> merge in context.S, these are only used in the places you mention in
> vectors.S.
> 
> The disable in restore_state only actually disables interrupts when
> returning from an exception. When returning from an interrupt, they
> are already disabled at this point. Perhaps the disable should be
> taken out of here and put into a path that only the exception code
> will go through.
> 
> Perhaps the macros should only clear the FP enable if they actually
> change the interrupt state.
> 
> In the DSR code, we know that any interrupt that occurs will not cause
> a thread switch, since the scheduler lock is non-zero. Hence the FPU
> state will not have changed. So I don't think we have to clear the FP
> enable at all through this code.
> 
> 
> -- 
> Nick Garnett
> Cygnus Solutions, a Red Hat Company
> Cambridge, UK