On Monday 09 April 2007 08:01, Toru Nishimura wrote:
> Chris Gilbert says;
>
> [ ... proposal to add "common irq code path" ... ]
>
> > So instead I've taken the footbridge irqhandler code, and made it a
> > common file. (The footbridge version was based on Jason's work for
> > xscale platforms)
>
> I agree with that providing "the common" is an better idea, but it
> should be emphasised that it has limitations which might be inadequate
> for some cases.
I'll echo that. While the common code may be useful during early bring-up
of a new port, there is no substitute for an implementation targetted
directly at the flavour of interrupt controller. This code is critical
to good performance. In particular, the spl(9) implementation must be as
small as possible. I have a few comments...
1. Consider the proposed arm_intr_splx() implementation. Right at the
start there are a whole bunch of 'extern foo' declarations. Each one of
those variables will generate, on ARM, a PC-relative load just to find
the address of the variable. This is all inlined code, so even small
functions like this contrived example:
{
extern volatile int x;
int s = splbio();
x = 0;
splx(s);
}
when compiled will be very much larger than you'd expect. Consider moving
some state into cpu_info.
2. As you noted, the 'mask' approach whereby pending interrupts are
recorded in a mask which mirrors the hardware's mask registers does not
scale well with more than 32 individual interrupt sources. It also
becomes extremely unwieldy in splx(9) where you'd have to logically AND
multiple 32-bit values to determine if an interrupt is pending. Instead,
on CPUs with an ffs(2)-like instruction ("clz" for example) you can use
a single 32-bit variable to record pending interrupts per IPL_*. Then
splx(9) can simply use "clz" to determine if it needs to invoke the
'dispatch pending' heavy lifter. You also greatly reduce the number of
external variable references in splx(9).
Using the above two suggestions in tandem, the spl(9) implementation will
be much smaller, the code will scale to multiple hardware masks much
more easily, and you may find some more opportunities to factor out
common/shared code.
Cheers, Steve