From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 Nov 2008 18:39:48 +0000 (GMT) Received: from smtp2.caviumnetworks.com ([209.113.159.134]:20011 "EHLO smtp2.caviumnetworks.com") by ftp.linux-mips.org with ESMTP id S23840107AbYKVSjl (ORCPT ); Sat, 22 Nov 2008 18:39:41 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by smtp2.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Sat, 22 Nov 2008 13:39:37 -0500 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 10:38:54 -0800 Received: from [192.168.111.195] ([64.169.86.201]) by exch4.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 10:38:54 -0800 Message-ID: <492851BA.3060306@caviumnetworks.com> Date: Sat, 22 Nov 2008 10:38:50 -0800 From: Chad Reese User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080829 Iceape/1.1.12 (Debian-1.1.12-1) MIME-Version: 1.0 To: Sergei Shtylyov CC: David Daney , linux-ide@vger.kernel.org, linux-mips Subject: Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface. References: <49261BE5.2010406@caviumnetworks.com> <49280FC5.3040608@ru.mvista.com> <49282187.8090602@ru.mvista.com> In-Reply-To: <49282187.8090602@ru.mvista.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2008 18:38:54.0580 (UTC) FILETIME=[92753340:01C94CD1] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kreese@caviumnetworks.com Precedence: bulk X-list: linux-mips Sergei Shtylyov wrote: > Also, this fragment of octeon_cf_bmdma_status() looks doubtful to me: > >> + else if (mio_boot_dma_cfg.s.size != 0xfffff) >> + result |= ATA_DMA_ERR; > > I suppose this only makes sense when DMA interrupt is active. What > does this bitfield mean? When you start the Octeon DMA engine, you program mio_boot_dma_cfg.s.size with the number of 16bit words to transfer. As the DMA runs, the hardware decrements this field. At the end it ends up decrementing past 0 to -1. The above check is simply checking if the DMA completed. Since this specific interrupt can only be generated by the DMA engine, it must have been caused by an error condition if the size is not -1. Chad