UDMA for Compact Flash over PC Card?

[Iain Barker]

For the benefit of anyone else who's interested in this thread, with the previous changes you may see "unexpected interrupt" on the IDE device.

Investigation showed this only happens when the Linux IDE driver is being run in MEMORY mode for sector writes to the Compact Flash (CF), and only at the very start of a multi-sector write transaction. i.e. the CF ~BUSY/READY line transitions from low to high when it is configured for MEMORY mode.

The reason for the event can be explained by text found in the Sandisk product spec that describes the WRITE SECTOR command. The text states ...

    "When this command is accepted, the CompactFlash Memory Card sets
    BSY, then sets DRQ and clears BSY, then waits for the host to fill
    the sector buffer with the data to be written. No interrupt is
    generated to start the first buffer fill operation."

The Linux IDE code (intended for IO mode) does not expect to receive an interrupt when the CF is ready to accept the first buffer fill of a WRITE SECTOR command. Instead, the IDE code polls the device and waits for DRQ to be asserted.

The 'unexpected interrupt' message is therefore harmless, as the DRQ is being serviced from polling anyway.  

The 'quick hack' solution is to add code in the IDE driver that sets an 'ignore_interrupt' flag just prior to issuing the WRITE SECTOR command to the drive when the CF is configured for MEMORY mode, and code in the IDE interrupt handler that senses this flag and does not log an 'unexpected interrupt' message when the flag is asserted. I'm sure there's a cleaner way of doing it, but this works.

For reference, with corresponding PCI changes for our arch to support DMA access to the CF memory buffer for PIO transfers, we get approx 4x the performance that we did with IO based simple PIO.

i.e. it's not as fast as true UDMA would be, but for a CF controller such as PCI1510 which doesn't support DMA natively, it's a big improvement and a lower CPU overhead.