Re: [PATCH] malta4kec hang in calibrate_delay fix

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

> 在 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.

            Regards,

            Kevin K.