linux-mips
[Top] [All Lists]

Re: [PATCH 1/2] ide: Add tx4939ide driver

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: [PATCH 1/2] ide: Add tx4939ide driver
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Fri, 12 Sep 2008 20:44:36 +0400
Cc: linux-mips@linux-mips.org, linux-ide@vger.kernel.org, bzolnier@gmail.com, ralf@linux-mips.org
In-reply-to: <20080913.005904.07457691.anemo@mba.ocn.ne.jp>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <48C851ED.4090607@ru.mvista.com> <20080912.005243.48535230.anemo@mba.ocn.ne.jp> <48CA8BEE.1090305@ru.mvista.com> <20080913.005904.07457691.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Hello.

Atsushi Nemoto wrote:

+               /*
+                * If only one of XFERINT and HOST was asserted, mask
+                * this interrupt and wait for an another one.  Note

This comment somewhat contradicts the code which returns 1 if only HOST interupt is asserted if ERR is set.

Which is not its business to test. I think you should remove that above check -- if there's INTRQ asserted, then it's asserted. I wonder if BMIDE interrupt bit gets set in that case (suspecting it's not)...

Well, let me explain a bit.  The datasheed say I should wait _both_
XFERINT and HOST interrupt.  So, if only one of them was asserted, I

   Since this is SFF-8038i compatible, you should first check if the spec'ed
interrupt status bit (called IDE_INT here) is set. If it isn't [always] get
set when it should, you may check for other interrupt bits (XFEREND/HOST/etc.)
and take the necessary measures if you detect interrupt on them.

mask it and wait another one.  But on the error case, only HOST was
asserted and XFERINT was never asserted.

And I suspect that IDE_INT also doesn't get set, right? The check for ERR=1 however is not needed. If the drive does assert its interrupt signal (INTRQ), it knows better why.

Then I could not exit from "waiting another one" state, until timeout.

Well, at least most of the other [PCI] drivers will wait for timeout in the case of the DMA status register bit 2 (IDE_INT here) not set -- despite some IDE chips do have bits indicating the INTRQ status from IDE bus. But usually, INTRQ still comes thru to this bit even if a command ends in error... This isn't the case here?

MBR, Sergei

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