linux-mips
[Top] [All Lists]

Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interfac

To: Chad Reese <kreese@caviumnetworks.com>
Subject: Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface.
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Sun, 23 Nov 2008 20:10:42 +0300
Cc: David Daney <ddaney@caviumnetworks.com>, linux-ide@vger.kernel.org, linux-mips <linux-mips@linux-mips.org>
In-reply-to: <492975B9.2000807@ru.mvista.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <49261BE5.2010406@caviumnetworks.com> <49280FC5.3040608@ru.mvista.com> <49282187.8090602@ru.mvista.com> <492851BA.3060306@caviumnetworks.com> <4929730B.2070904@ru.mvista.com> <492975B9.2000807@ru.mvista.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.18 (Windows/20081105)
Hello, I 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...

Ah, I forgot thet libata should be supporting polling mode, so should handle ERR=1 case. In this case the comment about the timeout contradicts your words about an interrupt being generated on DMA error.

  So, Octeon DMA can actually generate an error interrupt?

MBR, Sergei



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