Problems with the blackfin port

Allan Hessenflow allanh-rtems2 at kallisti.com
Tue Apr 1 17:32:34 UTC 2008


Thomas D?rfler wrote:
> The first point is, that bfin obviously only increments the
> thread_dispatch_level in certain conditions. In other architectures it
> is incremented in any case, this blocks dispatches to actually occur
> during interrupt handling. Have a look e.g. into the m68k implementation.
> 
> Normally a context switch should be triggered only, when the outermost
> ISR leaves (it decrements thread_dispatch_disable_level to zero).

I think Alain's code actually achieves the same thing, but even if it
doesn't, that isn't the issue here.

> Would it help if you changed the bfin ISR handling in that way and
> possibly add RETI (or some more vital resources) to the ISR/task context?

The basic problem is that RTI in the Blackfin has side effects.  First,
an RTI must be done prior to calling thread dispatch because that is the
only documented way to reenable lower priority interrupts.  That much isn't
a problem, just modify the RETI register to point to a wrapper that calls
thread dispatch, much like some other ports.  The problem comes in when 
thread dispatch returns.  At that point it cannot do another RTI because
another side effect of that instruction is that the outermost one switches
the processor to user mode, which we don't want.  We are normally running
inside the lowest priority interrupt all the time to stay in supervisor
mode.  So we can only use RTI once per interrupt.  There is no other way
to branch without destroying some register the interrupted task could care
about (other than perhaps some self modifying code).

The best solution I know of is to, instead of modifying RETI in the ISR
to return to a thread dispatch wrapper, raise a software interrupt which
will be taken right after the ISR returns.  Then that software interrupt
calls thread dispatch, and it can legitimately do an RTI to return to the
original task.  That software interrupt is the lowest priority interrupt
so it does not block any other interrupts, and it can be self-nested to
allow additional preemptive context switches.

allan

-- 
Allan N. Hessenflow      allanh at kallisti.com



More information about the users mailing list