From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 23 Nov 2008 15:25:03 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:20619 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S23849996AbYKWPYz (ORCPT ); Sun, 23 Nov 2008 15:24:55 +0000 Received: from [127.0.0.1] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id C1AB13EC9; Sun, 23 Nov 2008 07:24:49 -0800 (PST) Message-ID: <492975B9.2000807@ru.mvista.com> Date: Sun, 23 Nov 2008 18:24:41 +0300 From: Sergei Shtylyov User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Chad Reese 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> <492851BA.3060306@caviumnetworks.com> <4929730B.2070904@ru.mvista.com> In-Reply-To: <4929730B.2070904@ru.mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 21398 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, I just wrote: >> + * stoppng and restarting the DMA, we'll let the hardware do it. >> If the > > stopping > >> + * DMA is really stopped early due to an error condition, a later I'm not sure which error condition is meant here: ERR=1 in the status register, some internal DMA error, both? >> + * timeout will force us to stop. > > Sigh... So any command error will result in a timeout. I wonder what > hardware genius decided that CF doesn't need an IRQ... All this makes me think that since the DMA error condition cannot be reliably detected, you'd better not try to emulate the BMDMA error bit as well... >>>> + 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 >> > Also, this fragment of octeon_cf_bmdma_status() looks doubtful to me: > > What warrants that 0xfffff doesn't mean 2 MB transfer? > >> 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. >> > > Note that In the real SFF-8038i BMDMA, error bit doesn't cause an > interrupt... So, Octeon DMA can actually generate an error interrupt? MBR, Sergei