[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:13:15 +0300
Cc: David Daney <>,, linux-mips <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Thunderbird (Windows/20081105)

Chad Reese wrote:

+    /*
+     * Don't stop the DMA if the device deasserts DMARQ. Many compact
+ * flashes deassert DMARQ for a short time between sectors. Instead of

It's perfectly legal to do for any IDE device -- even not on the sector boundaries.

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

   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

  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...


MBR, Sergei

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