Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 58702
b: refs/heads/master
c: a09060f
h: refs/heads/master
v: v3
  • Loading branch information
Jeff Garzik committed Jul 9, 2007
1 parent 45aa3ad commit 89d4cae
Show file tree
Hide file tree
Showing 3 changed files with 53 additions and 4 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: df69c9c5438b4e396a64d42608b2a6c48a3e7475
refs/heads/master: a09060ffe516a0e55f29c89b7da2da760c9487d7
51 changes: 51 additions & 0 deletions trunk/drivers/ata/sata_sx4.c
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down Expand Up @@ -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,
Expand Down Expand Up @@ -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),
Expand Down
4 changes: 1 addition & 3 deletions trunk/drivers/ata/sata_via.c
Original file line number Diff line number Diff line change
Expand Up @@ -303,9 +303,7 @@ static int vt6420_prereset(struct ata_port *ap, unsigned long deadline)
if (!(ap->pflags & ATA_PFLAG_LOADING))
goto skip_scr;

/* Resume phy. This is the old resume sequence from
* __sata_phy_reset().
*/
/* Resume phy. This is the old SATA resume sequence */
svia_scr_write(ap, SCR_CONTROL, 0x300);
svia_scr_read(ap, SCR_CONTROL); /* flush */

Expand Down

0 comments on commit 89d4cae

Please sign in to comment.