[Top] [All Lists]

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

To: Chad Reese <>
Subject: Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface.
From: Sergei Shtylyov <>
Date: Sun, 23 Nov 2008 18:24:41 +0300
Cc: David Daney <>,, linux-mips <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <>
User-agent: Thunderbird (Windows/20081105)
Hello, I just wrote:

+ * stoppng and restarting the DMA, we'll let the hardware do it. If the


+     * 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

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