[PATCH] libata atapi work #5

[PATCH] libata atapi work #5

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 10 bytes --]

attached.

[-- Attachment #2: patch.5 --]
[-- Type: text/plain, Size: 2795 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/05/13 22:46:01-04:00 jgarzik@redhat.com 
#   [libata] kill ATA_QCFLAG_POLL flag
#   
#   The standard ATA bit nIEN in the Device Control register serves as
#   the indicator for whether we are polling or not.  As it mirrors
#   ATA_QCFLAG_POLL completely, eliminate that in favor of testing
#   ATA_NIEN bit.
# 
diff -Nru a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c	Fri May 14 14:24:25 2004
+++ b/drivers/scsi/libata-core.c	Fri May 14 14:24:25 2004
@@ -2733,7 +2733,7 @@
 			struct ata_queued_cmd *qc;
 
 			qc = ata_qc_from_tag(ap, ap->active_tag);
-			if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
+			if (qc && (!(qc->tf.ctl & ATA_NIEN)))
 				handled += ata_host_intr(ap, qc);
 		}
 	}
diff -Nru a/drivers/scsi/sata_promise.c b/drivers/scsi/sata_promise.c
--- a/drivers/scsi/sata_promise.c	Fri May 14 14:24:25 2004
+++ b/drivers/scsi/sata_promise.c	Fri May 14 14:24:25 2004
@@ -421,7 +421,7 @@
 			struct ata_queued_cmd *qc;
 
 			qc = ata_qc_from_tag(ap, ap->active_tag);
-			if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
+			if (qc && (!(qc->tf.ctl & ATA_NIEN)))
 				handled += pdc_host_intr(ap, qc);
 		}
 	}
diff -Nru a/drivers/scsi/sata_sx4.c b/drivers/scsi/sata_sx4.c
--- a/drivers/scsi/sata_sx4.c	Fri May 14 14:24:25 2004
+++ b/drivers/scsi/sata_sx4.c	Fri May 14 14:24:25 2004
@@ -748,7 +748,7 @@
 			struct ata_queued_cmd *qc;
 
 			qc = ata_qc_from_tag(ap, ap->active_tag);
-			if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
+			if (qc && (!(qc->tf.ctl & ATA_NIEN)))
 				handled += pdc20621_host_intr(ap, qc, (i > 4),
 							      mmio_base);
 		}
diff -Nru a/drivers/scsi/sata_vsc.c b/drivers/scsi/sata_vsc.c
--- a/drivers/scsi/sata_vsc.c	Fri May 14 14:24:25 2004
+++ b/drivers/scsi/sata_vsc.c	Fri May 14 14:24:25 2004
@@ -175,7 +175,7 @@
 				struct ata_queued_cmd *qc;
 
 				qc = ata_qc_from_tag(ap, ap->active_tag);
-				if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
+				if (qc && (!(qc->tf.ctl & ATA_NIEN)))
 					handled += ata_host_intr(ap, qc);
 			}
 		}
diff -Nru a/include/linux/libata.h b/include/linux/libata.h
--- a/include/linux/libata.h	Fri May 14 14:24:25 2004
+++ b/include/linux/libata.h	Fri May 14 14:24:25 2004
@@ -112,7 +112,6 @@
 	ATA_QCFLAG_DMA		= (1 << 2), /* data delivered via DMA */
 	ATA_QCFLAG_ATAPI	= (1 << 3), /* is ATAPI packet command? */
 	ATA_QCFLAG_SG		= (1 << 4), /* have s/g table? */
-	ATA_QCFLAG_POLL		= (1 << 5), /* polling, no interrupts */
 
 	/* various lengths of time */
 	ATA_TMOUT_EDD		= 5 * HZ,	/* hueristic */
@@ -483,7 +482,6 @@
 
 static inline void ata_qc_set_polling(struct ata_queued_cmd *qc)
 {
-	qc->flags |= ATA_QCFLAG_POLL;
 	qc->flags &= ~ATA_QCFLAG_DMA;
 	qc->tf.ctl |= ATA_NIEN;
 }

Re: [PATCH] libata atapi work #5

[Pat LaVarre]

> -				if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
> +				if (qc && (!(qc->tf.ctl & ATA_NIEN)))
> ...
> -	ATA_QCFLAG_POLL		= (1 << 5), /* polling, no interrupts */

Back in PATA, when I set x02 ATA_NIEN, I mis/remember I saw INTRQ float,
rather than becoming reliably deasserted.

Is life better in SATA?

Pat LaVarre

Re: [PATCH] libata atapi work #5

[Jeff Garzik]

Pat LaVarre wrote:
>>-				if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
>>+				if (qc && (!(qc->tf.ctl & ATA_NIEN)))
>>...
>>-	ATA_QCFLAG_POLL		= (1 << 5), /* polling, no interrupts */
> 
> 
> Back in PATA, when I set x02 ATA_NIEN, I mis/remember I saw INTRQ float,
> rather than becoming reliably deasserted.
> 
> Is life better in SATA?

On pure SATA, you just have a bit in a FIS, as I mentioned in one of the 
other emails (in this current email flurry :)).

On bridged SATA, where either the host controller or the device, or 
both, have an on-device SATA<->PATA bridge, the bridge must deal with 
INTRQ.  On the whole it is _much_ more clean.

Read up in the SATA docs on the difference between a "command FIS" and a 
"control FIS".  Here's a quick intro...

Both are Host-to-Device Register FIS's.  The former is sent to the 
device when the Command shadow register is written.  The latter is sent 
to the device when the Device Control register is written.  Both types 
of H2D Register FIS, command and control, send a complete copy of the 
taskfile shadow registers to the device at that time.

Reading your emails, you sound like a "hardware guy" to me :)  SATA is 
_very_ different from PATA at the hardware level.  What used to be chip 
selects and signals are now bits in a data structure that is sent -- 
much like an ethernet frame -- over a serial link.

	Jeff

Re: [PATCH] libata atapi work #5

[Pat LaVarre]

> Read up in the SATA docs ...

Will do at t13.org ...

> Reading your emails, you sound like a "hardware guy" to me :)

Yes.

Kind of you to celebrate my sanity. :-)

Specifically, I was salaried in 1994..1999 mostly to write device
firmware: SCSI/ PPT/ ATAPI/ USB/ FireWire/ etc.  But often for test &
once to ship I wrote the host-side of the cable too, most recently x86
PATA UDMA.

Also I helped write the usb.org USB/ATAPI bridge spec, so I find serial/
parallel conversion familiar.  And always my employer mass-produced one
basic drive and then added bridges to support other kinds of cabling, so
bridging to PATA ATAPI was my whole world in 1997..1999.

Pat LaVarre
http://sourceforge.net/projects/iomrrdtools/
http://members.aol.com/plscsi/tools/pldd/
http://members.aol.com/plscsi/

Re: [PATCH] libata atapi work #5

[Jeff Garzik]

If you're really bored, my wet dream would be seeing an open IP core 
compliant to the AHCI specification:
http://www.intel.com/technology/serialata/pdf/rev1_0.pdf

Should be easy to verify with an FPGA and a couple SATA phys :)

	Jeff

Re: [PATCH] libata atapi work #5

[Pat LaVarre]

Jeff G:

> an open IP core 
> compliant to the AHCI specification:
> http://www.intel.com/technology/serialata/pdf/rev1_0.pdf

Does the web now offer PCI chip designs in open source?

1987..1990 or so I did register-transfer-level chip design (a la
Verilog).  I naturally prefer concurrent designs over sequential.

Pat LaVarre

Re: [PATCH] libata atapi work #5

[Leon Woestenberg]

Hello,

> Does the web now offer PCI chip designs in open source?
>
Yes. Most notably: http://www.opencores.org/

> 1987..1990 or so I did register-transfer-level chip design (a la
> Verilog).  I naturally prefer concurrent designs over sequential.
> 
Don't we all? :-)

BTW, your discussion makes good reading. Learning from it. (I used
to write SCSI drivers/applications mostly for rare devices and for
the SCSI vendor-unique command sets. I wish I had the time to
engineer along with you guys on SATA).

Regards,

Leon Woestenberg.

Re: [PATCH] libata atapi work #5

[Jeff Garzik]

Pat LaVarre wrote:
> Jeff G:
> 
> 
>>an open IP core 
>>compliant to the AHCI specification:
>>http://www.intel.com/technology/serialata/pdf/rev1_0.pdf
> 
> 
> Does the web now offer PCI chip designs in open source?

Yes.  http://www.opencores.org/projects.cgi/web/pci

The above IP core bridges from the PCI bus to the internal wishbone [IP 
core interconnect] bus.

In theory, you connect your AHCI IP core to the PCI IP core via 
wishbone.  opencores.org also has a wishbone-compliant DMA engine.


> 1987..1990 or so I did register-transfer-level chip design (a la
> Verilog).  I naturally prefer concurrent designs over sequential.

All good EE designs are concurrent rather than sequential ;-)

But I'm a computer scientist, what do I know...

	Jeff

Re: [PATCH] libata atapi work #5

[Leon Woestenberg]

Hello Jeff,

Jeff Garzik wrote:
> All good EE designs are concurrent rather than sequential ;-)
> 
> But I'm a computer scientist, what do I know...
 >
A rough guess: POSIX Threads :-)

And yes, that's IE*EE* POSIX Threads ;-)

Leon.

Re: [PATCH] libata atapi work #5

[Jeff Garzik]

Leon Woestenberg wrote:
> Hello Jeff,
> 
> Jeff Garzik wrote:
> 
>> All good EE designs are concurrent rather than sequential ;-)
>>
>> But I'm a computer scientist, what do I know...
> 
>  >
> A rough guess: POSIX Threads :-)
> 
> And yes, that's IE*EE* POSIX Threads ;-)

hehe.

Well, I actually don't like threads...  but down at the hardware level, 
circuits are inherently parallel.

	Jeff

Re: [PATCH] libata atapi work #5

[Pat LaVarre]

If I may continue our explosive growth in off-topic digressions here ...

1)

Thank you I blogged those open source PCI chip links to:

Subject: PCI chip designs in open source, now available
http://plavarre.blog-city.com/read/610412.htm

2)

I personally reviewed IEEE pthreads in late draft, for example on my own
time I flew to the New Orleans working group.  I argued to specify
pthreads so that they could efficiently do cooperative fibers, not just
indeterminately preemptive SMP, but I left town before that project
ended.  My least irrelevant blog might be:

fibers in C across platforms, if abused without asm
http://plavarre.blog-city.com/read/433074.htm

3)

I haven't seen anyone in software outside of chip simulation support
massively parallel threading with reasonable efficiency.

My least irrelevant blog for that might be:

http://groups.google.com/groups?threadm=2695edf1.0403121101.1d77a037%40posting.google.com
Newsgroups: comp.lang.forth
Subject: almost every if is a mistake goes mainstream
Date: 2004-03-12 11:01:09 PST 

which mentions the recent gcc adoption of the "indirect goto extension"
as in Maurer'shttp://cs.ecs.baylor.edu/~maurer/Metamorphic/
IEEE Computer March 2004, p.31, "Metamorphic Programming: Unconventional
High Performance".

Pat LaVarre

Re: [PATCH] libata atapi work #5

[Jeff Garzik]

BTW, here too is behavioral VHDL for a SATA host, from the "free model 
foundry", a VITAL model:
http://www.eda.org/fmf/fmf_public_models/bus/Hsata.vhd

http://vhdl.org/fmf/wwwpages/model_list.html