diff options
author | Jeff Garzik <jeff@garzik.org> | 2007-05-28 08:17:06 -0400 |
---|---|---|
committer | Jeff Garzik <jeff@garzik.org> | 2007-07-09 12:17:33 -0400 |
commit | a09060ffe516a0e55f29c89b7da2da760c9487d7 (patch) | |
tree | 806801905926d8f9b1854b51c5fe88fb037b223a /drivers/ata/sata_sx4.c | |
parent | df69c9c5438b4e396a64d42608b2a6c48a3e7475 (diff) |
[libata] sata_sx4, sata_via: minor documentation updates
sata_sx4:
- describe overall driver theory of operation
- add a few constants that will be used in the future
sata_via:
- remove mention of an old-EH function that is going away
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'drivers/ata/sata_sx4.c')
-rw-r--r-- | drivers/ata/sata_sx4.c | 51 |
1 files changed, 51 insertions, 0 deletions
diff --git a/drivers/ata/sata_sx4.c b/drivers/ata/sata_sx4.c index ff0a78dc8b8..3d83ee27338 100644 --- a/drivers/ata/sata_sx4.c +++ b/drivers/ata/sata_sx4.c @@ -30,6 +30,54 @@ * */ +/* + Theory of operation + ------------------- + + The SX4 (PDC20621) chip features a single Host DMA (HDMA) copy + engine, DIMM memory, and four ATA engines (one per SATA port). + Data is copied to/from DIMM memory by the HDMA engine, before + handing off to one (or more) of the ATA engines. The ATA + engines operate solely on DIMM memory. + + The SX4 behaves like a PATA chip, with no SATA controls or + knowledge whatsoever, leading to the presumption that + PATA<->SATA bridges exist on SX4 boards, external to the + PDC20621 chip itself. + + The chip is quite capable, supporting an XOR engine and linked + hardware commands (permits a string to transactions to be + submitted and waited-on as a single unit), and an optional + microprocessor. + + The limiting factor is largely software. This Linux driver was + written to multiplex the single HDMA engine to copy disk + transactions into a fixed DIMM memory space, from where an ATA + engine takes over. As a result, each WRITE looks like this: + + submit HDMA packet to hardware + hardware copies data from system memory to DIMM + hardware raises interrupt + + submit ATA packet to hardware + hardware executes ATA WRITE command, w/ data in DIMM + hardware raises interrupt + + and each READ looks like this: + + submit ATA packet to hardware + hardware executes ATA READ command, w/ data in DIMM + hardware raises interrupt + + submit HDMA packet to hardware + hardware copies data from DIMM to system memory + hardware raises interrupt + + This is a very slow, lock-step way of doing things that can + certainly be improved by motivated kernel hackers. + + */ + #include <linux/kernel.h> #include <linux/module.h> #include <linux/pci.h> @@ -58,6 +106,8 @@ enum { PDC_INT_SEQMASK = 0x40, /* Mask of asserted SEQ INTs */ PDC_HDMA_CTLSTAT = 0x12C, /* Host DMA control / status */ + PDC_CTLSTAT = 0x60, /* IDEn control / status */ + PDC_20621_SEQCTL = 0x400, PDC_20621_SEQMASK = 0x480, PDC_20621_GENERAL_CTL = 0x484, @@ -89,6 +139,7 @@ enum { PDC_MASK_INT = (1 << 10), /* HDMA/ATA mask int */ PDC_RESET = (1 << 11), /* HDMA/ATA reset */ + PDC_DMA_ENABLE = (1 << 7), /* DMA start/stop */ PDC_MAX_HDMA = 32, PDC_HDMA_Q_MASK = (PDC_MAX_HDMA - 1), |