From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Shtylyov Subject: Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface. Date: Sun, 23 Nov 2008 18:24:41 +0300 Message-ID: <492975B9.2000807@ru.mvista.com> References: <49261BE5.2010406@caviumnetworks.com> <49280FC5.3040608@ru.mvista.com> <49282187.8090602@ru.mvista.com> <492851BA.3060306@caviumnetworks.com> <4929730B.2070904@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from homer.mvista.com ([63.81.120.155]:35663 "EHLO imap.sh.mvista.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1758195AbYKWPYv (ORCPT ); Sun, 23 Nov 2008 10:24:51 -0500 In-Reply-To: <4929730B.2070904@ru.mvista.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Chad Reese Cc: David Daney , linux-ide@vger.kernel.org, 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