>Number:         24883
>Category:       port-mac68k
>Synopsis:       Patch for DMA SCSI on Quadra AV's
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-mac68k-maintainer
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 22 20:22:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Michael Zucca
>Release:        -current
>Organization:
>Environment:
Not really important
>Description:
A while ago I posted a patch to the port-mac68k mailing list that enables the use of the DMA engine on the Quadra AV machines to push data to and from the SCSI chip.

The link to the email with the code attached is here:
http://mail-index.netbsd.org/port-mac68k/2003/06/08/0000.html

I'm submitting this PR in the hopes that the code gets added to the source tree. It appears that little attention was paid to my initial email.

This patch is merely preliminary and only gives minor performance improvements. There is room for a lot of improvement. Namely, the SCSI chip stays in asynchronous transfer mode because sync negotiation in the generic NCR SCSI driver happens using unaligned and odd sized buffers. In such cases the new DMA code falls back to using PIO. I think the NCR doesn't like to do sync negotiation through PIO and falls back to async mode. Thus, we're losing out on a lot of performance. Another area of performance improvement is interrupt handling. Right now, the code is simple and just pushes a single dma map entry on the NCR chip's interrupt. It would be better to use the SCSI DMA interrupt to DMA an entire dma map. It also appears that the DMA engine is setup so that two transfers can be programmed in initially, and then, at interrupt, one transfer can run in the background while the just finished transfer can be updated with the next transfer segment. I don't know how to do that yet, 
 but it can't be that difficult and would help tremendously with transfer speed since we would be able to keep the NCR and DMA engine pushing or pulling as much data to/from the disk as the system can.

Other things to contemplate:
* Separating out the PSC's DMA channels into a device. Sort of like the DMA engine on other m68k platforms.
* Using this code as the basis to DMA-ify the serial driver.

Anyway, the patch I submitted is a good start. If there are any questions, feel free to email me.

>How-To-Repeat:
See above.
>Fix:
See above.
>Release-Note:
>Audit-Trail:
>Unformatted: