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