ÂÂ It's still a hack here, but that's solve my problem.
The Compare/Count timer interrupt here is connect to irq7 here,
which means interrupt occurs hardware will set CAUSE TI bit to 7.
 The hardware, it's a integrated SOC platform shipped with mips24kc processor,
Still no public document released yet.
ÂÂ What's could explain that flush_data_cache_page fix the problem?
Cache misconfiguration?
ÂÂ Thanks
Dennis
On Sun, Mar 20, 2011 at 1:22 AM, Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote:
On Sat, Mar 19, 2011 at 08:42:17AM +0800, Dennis.Yxun wrote:The call local_flush_icache_range should already flushes the cache and
> HI ALL:
> Â Again, found that when come to set vect irq 7, do additional data flush
> fix my problem, here is the patch
>
> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index e971043..850ce58 100644
> --- a/arch/mips/kernel/traps.c
> +++ b/arch/mips/kernel/traps.c
> @@ -1451,6 +1451,9 @@ static void *set_vi_srs_handler(int n, vi_handler_t
> addr, int srs)
> Â Â Â Â Â Â Â Â *w = (*w & 0xffff0000) | (((u32)handler >> 16) & 0xffff);
> Â Â Â Â Â Â Â Â w = (u32 *)(b + ori_offset);
> Â Â Â Â Â Â Â Â *w = (*w & 0xffff0000) | ((u32)handler & 0xffff);
> + Â Â Â Â Â Â Â /* FIXME: need flash data cache, for timer irq */
> + Â Â Â Â Â Â Â if (n == 7)
> + Â Â Â Â Â Â Â Â Â Â Â flush_data_cache_page((unsigned int)b);
> Â Â Â Â Â Â Â Â local_flush_icache_range((unsigned long)b,
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â(unsigned long)(b+handler_len));
there should be no reason why a 2nd range makes it any better - or why
it would only be needed for irq 7 - and the timer isn't necessarily
always irq 7.
What is your hardware platform and processor?
ÂRalf
