From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263368AbTJVEbs (ORCPT ); Wed, 22 Oct 2003 00:31:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263406AbTJVEbs (ORCPT ); Wed, 22 Oct 2003 00:31:48 -0400 Received: from mtvcafw.SGI.COM ([192.48.171.6]:42514 "EHLO rj.sgi.com") by vger.kernel.org with ESMTP id S263368AbTJVEbr (ORCPT ); Wed, 22 Oct 2003 00:31:47 -0400 Date: Tue, 21 Oct 2003 21:30:58 -0700 From: Jeremy Higdon To: Bartlomiej Zolnierkiewicz Cc: gwh@sgi.com, jbarnes@sgi.com, aniket_m@hotmail.com, linux-kernel@vger.kernel.org Subject: Re: Patch to add support for SGI's IOC4 chipset Message-ID: <20031022043058.GC80096@sgi.com> References: <3F7CB4A9.3C1F1237@sgi.com> <200310162020.51303.bzolnier@elka.pw.edu.pl> <20031021063536.GA78855@sgi.com> <200310211639.28346.bzolnier@elka.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310211639.28346.bzolnier@elka.pw.edu.pl> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 21, 2003 at 04:39:28PM +0200, Bartlomiej Zolnierkiewicz wrote: > On Tuesday 21 of October 2003 08:35, Jeremy Higdon wrote: > > > - defining IDE_ARCH_ACK_INTR and ide_ack_intr() in sgiioc4.c is a no-op, > > > it should be done to make it work > > > (I think the same problem is present in 2.4.x) > > > > The definition in is only used if IDE_ARCH_ACK_INTR > > is not defined. sgiioc4.c defines IDE_ARCH_ACK_INTR before including that > > file, so I believe we get the definition we want without touching ide.h, > > don't we? > > ide_ack_intr() is used by ide-io.c. If IDE_ARCH_ACK_INTR is not defined > in ide.h (and it won't be cause you are doing this only in sgiioc4.c > /sgiioc4.h in 2.4.x case/ about which ide-io.c has abolutely no idea) > ide_ack_intr() will turn into no-op and hwif->ack_intr() won't be called. I see what you mean. Thanks for spotting and fixing this. I've run into a problem in testing. For some reason, I've started to get ide timeouts, and the error recovery is not working correctly, due to a problem in the driver. In sgiioc4_ide_dma_stop(), sgiioc4_ide_dma_end(), and sgiioc4_clearirq(), there are calls to xide_delay(), which uses schedule_timeout() to sleep. Since all of these sgiioc4_ functions can be called from interrupt context, that's an obvious problem. In sgiioc4_clearirq(), the delay function is while we're waiting for the interrupt to clear. In sgiioc4_ide_dma_stop(), we're waiting for the DMA bit to clear. In sgiioc4_ide_dma_end(), we're waiting for another DMA to finish. I believe that the right answer is to use udelay() and give up after a short period of time. My question is what does the ide layer expect? That is, if you call the dma_end function and the hardware driver can't succeed, what would you like us to do? Is there a way to return error, or should we just fail and the ide infrastructure will pick it up later and reset things? I am new to Linux IDE, so forgive these questions if the answers should be obvious. thanks jeremy