[Top] [All Lists]

Re: [PATCH] malta4kec hang in calibrate_delay fix

To: "yshi" <>
Subject: Re: [PATCH] malta4kec hang in calibrate_delay fix
From: "Kevin D. Kissell" <>
Date: Tue, 4 Sep 2007 13:21:24 +0200
Cc: <>
Original-recipient: rfc822;
References: <> <006901c7eeda$d8049a50$10eca8c0@grendel> <1188901951.4106.16.camel@yshi.CORP>
> 在 2007-09-04二的 12:03 +0200,Kevin D. Kissell写道:
> > The 4KEc is a MIPS32 Release 2 processor, for which the implementation
> > of the Cause.TI bit (bit 30) is required.  You may have a defective board
> > or a bad FPGA bitfile.  Please work with your support contacts at MIPS
> > to verify that this is not the case.  It may also be that there's something 
> > more
> > subtle going on in the interrupt processing, such that the Cause.TI bit is 
> > being
> > cleared before it can be sampled by the code you've changed.  But while the
> > patch below presumably solves the symptoms of your problem, I really
> > don't think that a kernel hack based on detecting CoreFPA3 is an appropriate
> > solution.  I work every day with Malta/CoreFPGA3 bitfiles and have not
> > seen Cause.TI fail to function in any of the Release 2 core bitfiles I've 
> > used.
> My board's core is Release 1 core. So Cause.TI bit always is zero. Maybe
> I need update this patch to reflect this, i.e add #ifdef to distinguish
> Release 1 and Release 2. Thanks.

In that case, your core is a 4Kc and not a 4KEc.  The "r2" value in the
code you're looking at should therefore be zero.  I don't have the rest
of the kernel tree you're using in front of me, but I can't help but suspect
that either cpu_has_mips_r2 has a broken definition, or that handle_iperf_irq()
isn't correctly setting its return value if the r2 argument is zero.  There
should in principle be no need to add more #ifdefs than there already are
in the code in question.


            Kevin K.

<Prev in Thread] Current Thread [Next in Thread>