Hello.
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
stopping
+ * 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...
Chad
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
