On 01/06/11 23:56, Anoop P A wrote:
On Thu, 2011-01-06 at 15:31 -0800, Kevin D. Kissell wrote:
I'm sure I've said this before, and it's in various comments in the SMTC
code, but remember, one of the main problems that the SMTC kernel
had to solve was to prevent all TCs of a VPE from "convoying" after every
interrupt. The way this is done is that the interrupt vector code, before
clearing EXL, masks off the Status.IM bit associated with the incoming
interrupt. Of course, to get another interrupt from the same source
(or collection of sources), that IM bit needs to be restored. The "correct"
mechanism for this is by having the appropriate irq_hwmask[] value set,
so that smtc_im_ack_irq(), which should be invoked on an irq "ack()"
(meaning that the source has been quenched and any new occurrence
should be considered a new interrupt), will restore the bit in Status.
This function got moved around a bit in the various SMTC prototypes,
but it proved least intrusive to put it into the xxx_mask_and_ack()
functions
for the interrupt controllers - see irq-msc01.c and i8259.c. If you haven't
done the same in any equivalent code for a different on-chip controller,
you'll definitely have problems.
The Backstop scheme works OK for peripheral interrupts that didn't
have an appropriate irq_hwmask[] value set up, but clock interrupts
don't follow the same code paths and can't depend on the backstop.
Ok. Well thanks much for your detailed explanation. Well I hope I found
the root cause . smtc_clockevent_init() was overriding irq_hwmask even
if are using platform specific get_c0_compare_int. With following patch
everything seems to be working for me.
Would this still be with a "tickful" kernel? I was able to run some
experiments on a Malta over the weekend, using mostly default
Malta defconfig options including tickless operation. The 2.6.32.27
build comes up with both VPEs and all TCs firing. 2.6.36.2 with
the stackframe.h patch boots all the way up on a single VPE, but
VERY slowly - as if the Clock/Compare setups weren't being done
correctly and timer intervals were waiting the full Count register
rollover cycle. I've been looking at diffs, and merged one change
that was made to cevt-r4k.c into the analogous routine in cevt-smtc.c
(no change), but there's clearly more breakage to the SMTC/Malta
configuration post-2.6.32 than just the stackframe.h patch. Going
tickful may work around it, but tickful+SMTC is grossly inefficient.
Regards,
Kevin K.
