Re: SMTC support status in latest git head.

["Kevin D. Kissell" <kevink@paralogos.com>]

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.