* [PATCH] libata DMADIR support
@ 2004-05-15 21:46 Jeff Garzik
0 siblings, 0 replies; 17+ messages in thread
From: Jeff Garzik @ 2004-05-15 21:46 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
This patch goes by the specification -- which means it apparently
doesn't work with at least one bridge. So modify this patch as necessary.
Until a definitive solution is found, DMADIR will remain a "branch" off
the main work.
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2130 bytes --]
diff -Nru a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c Sat May 15 17:44:43 2004
+++ b/drivers/scsi/libata-core.c Sat May 15 17:44:43 2004
@@ -1167,6 +1167,9 @@
if (ata_id_is_ata(dev)) /* sanity check */
goto err_out_nosup;
+ if (ata_id_use_dmadir(dev))
+ dev->flags |= ATA_DFLAG_DMADIR;
+
/* see if 16-byte commands supported */
tmp = dev->id[0] & 0x3;
if (tmp == 1)
diff -Nru a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c Sat May 15 17:44:43 2004
+++ b/drivers/scsi/libata-scsi.c Sat May 15 17:44:43 2004
@@ -920,6 +920,9 @@
qc->flags |= ATA_QCFLAG_SG; /* data is present; dma-map it */
qc->tf.protocol = ATA_PROT_ATAPI_DMA;
qc->tf.feature |= ATAPI_PKT_DMA;
+ if ((qc->dev->flags & ATA_DFLAG_DMADIR) &&
+ (cmd->sc_data_direction != SCSI_DATA_WRITE))
+ qc->tf.feature |= ATAPI_DMADIR;
}
return 0;
diff -Nru a/include/linux/ata.h b/include/linux/ata.h
--- a/include/linux/ata.h Sat May 15 17:44:43 2004
+++ b/include/linux/ata.h Sat May 15 17:44:43 2004
@@ -134,6 +134,8 @@
/* ATAPI stuff */
ATAPI_PKT_DMA = (1 << 0),
+ ATAPI_DMADIR = (1 << 2), /* ATAPI data dir:
+ 0=to device, 1=to host */
/* cable types */
ATA_CBL_NONE = 0,
@@ -203,6 +205,7 @@
#define ata_id_has_wcache(dev) ((dev)->id[82] & (1 << 5))
#define ata_id_has_lba(dev) ((dev)->id[49] & (1 << 8))
#define ata_id_has_dma(dev) ((dev)->id[49] & (1 << 9))
+#define ata_id_use_dmadir(dev) ((dev)->id[62] & (1 << 15))
#define ata_id_u32(dev,n) \
(((u32) (dev)->id[(n) + 1] << 16) | ((u32) (dev)->id[(n)]))
#define ata_id_u64(dev,n) \
diff -Nru a/include/linux/libata.h b/include/linux/libata.h
--- a/include/linux/libata.h Sat May 15 17:44:43 2004
+++ b/include/linux/libata.h Sat May 15 17:44:43 2004
@@ -90,6 +90,7 @@
ATA_DFLAG_MASTER = (1 << 2), /* is device 0? */
ATA_DFLAG_WCACHE = (1 << 3), /* has write cache we can
* (hopefully) flush? */
+ ATA_DFLAG_DMADIR = (1 << 4), /* use DMADIR bit in ATAPI */
ATA_DEV_UNKNOWN = 0, /* unknown device */
ATA_DEV_ATA = 1, /* ATA device */
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
@ 2004-05-16 14:19 Pat LaVarre
2004-05-16 23:16 ` Jeff Garzik
0 siblings, 1 reply; 17+ messages in thread
From: Pat LaVarre @ 2004-05-16 14:19 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
Jeff G:
I've now slowly and awkwardly synced as the following tty log of patch
and a #define patch of my own show. Therefore I ask:
Have you considered an include/linux/libata.h approach like:
+ #undef ATA_FORCE_DMADIR /* give Si DMADIR to all SATA ATAPI DMA */
+ #include <linux/ata.h>
+ #ifdef ATA_FORCE_DMADIR
+ #undef ata_id_use_dmadir
+ #define ata_id_use_dmadir(dev) 1
+ #endif
I'll save time in the end if I volunteer to write such a patch, after
you reply to say you would consider such a patch, if in fact you would.
Pat LaVarre
$ cd linux-2.6.6-bk3/
$
$ patch --dry-run -p1 <~/patch.2.1
patching file drivers/scsi/libata-core.c
patching file drivers/scsi/libata-scsi.c
$ patch --dry-run -p1 <~/patch.dmadir
patching file drivers/scsi/libata-core.c
patching file drivers/scsi/libata-scsi.c
patching file include/linux/ata.h
patching file include/linux/libata.h
$
$ patch -p1 <~/patch.2.1
patching file drivers/scsi/libata-core.c
patching file drivers/scsi/libata-scsi.c
$ patch -p1 <~/patch.dmadir
patching file drivers/scsi/libata-core.c
patching file drivers/scsi/libata-scsi.c
Hunk #1 succeeded at 927 (offset 7 lines).
patching file include/linux/ata.h
patching file include/linux/libata.h
$
diff -Nurp o/include/linux/ata.h linux-2.6.6-bk3-pel/include/linux/ata.h
--- o/include/linux/ata.h 2004-05-16 08:06:04.000000000 -0600
+++ linux-2.6.6-bk3-pel/include/linux/ata.h 2004-05-16
08:09:04.473768304 -0600
@@ -205,7 +205,7 @@ struct ata_taskfile {
#define ata_id_has_wcache(dev) ((dev)->id[82] & (1 << 5))
#define ata_id_has_lba(dev) ((dev)->id[49] & (1 << 8))
#define ata_id_has_dma(dev) ((dev)->id[49] & (1 << 9))
-#define ata_id_use_dmadir(dev) ((dev)->id[62] & (1 << 15))
+#define ata_id_use_dmadir(dev) 1 /* ((dev)->id[62] & (1 << 15)) */
#define ata_id_u32(dev,n) \
(((u32) (dev)->id[(n) + 1] << 16) | ((u32) (dev)->id[(n)]))
#define ata_id_u64(dev,n) \
diff -Nurp o/include/linux/libata.h
linux-2.6.6-bk3-pel/include/linux/libata.h
--- o/include/linux/libata.h 2004-05-16 08:06:23.000000000 -0600
+++ linux-2.6.6-bk3-pel/include/linux/libata.h 2004-05-16
08:09:22.811980472 -0600
@@ -33,11 +33,11 @@
* compile-time options
*/
#undef ATA_FORCE_PIO /* do not configure or use DMA */
-#undef ATA_DEBUG /* debugging output */
-#undef ATA_VERBOSE_DEBUG /* yet more debugging output */
+#define ATA_DEBUG /* debugging output */
+#define ATA_VERBOSE_DEBUG /* yet more debugging output */
#undef ATA_IRQ_TRAP /* define to ack screaming irqs */
#undef ATA_NDEBUG /* define to disable quick runtime checks */
-#undef ATA_ENABLE_ATAPI /* define to enable ATAPI support */
+#define ATA_ENABLE_ATAPI /* define to enable ATAPI support */
#undef ATA_ENABLE_PATA /* define to enable PATA support in some
* low-level drivers */
diff -Nurp o/drivers/scsi/libata-core.c
linux-2.6.6-bk3-pel/drivers/scsi/libata-core.c
diff -Nurp o/drivers/scsi/libata-scsi.c
linux-2.6.6-bk3-pel/drivers/scsi/libata-scsi.c
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] libata DMADIR support
2004-05-16 14:19 Pat LaVarre
@ 2004-05-16 23:16 ` Jeff Garzik
2004-05-17 18:48 ` Pat LaVarre
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Garzik @ 2004-05-16 23:16 UTC (permalink / raw)
To: Pat LaVarre; +Cc: linux-ide
Pat LaVarre wrote:
> + #undef ATA_FORCE_DMADIR /* give Si DMADIR to all SATA ATAPI DMA */
> I'll save time in the end if I volunteer to write such a patch, after
> you reply to say you would consider such a patch, if in fact you would.
Should be atapi patch #2.2, which I just commited and pushed upstream.
Jeff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-16 23:16 ` Jeff Garzik
@ 2004-05-17 18:48 ` Pat LaVarre
2004-05-17 19:08 ` Jeff Garzik
0 siblings, 1 reply; 17+ messages in thread
From: Pat LaVarre @ 2004-05-17 18:48 UTC (permalink / raw)
To: linux-ide
I remember I promised cross-references into the t13.org theories. Over
time I hope to walk back thru ATA/PI 7, 6, 5, and 4. Here first is most
of a DMADIR grep in ATA/PI 7, quoted below.
I think I see that text:
(a) requires a DMADIR device to tell legacy hosts that the device talks
PIO only
(b) requires a DMADIR device to tell new hosts that the device does not
talk SWDMA/ MWDMA
(c) claims a DMADIR device should reward a host confused over direction
with nothing more violent than SK 5 "ILLEGAL REQUEST", and
(d) lets a not-DMADIR device choose to rudely fail classic UDMA Data In
commands, when a host chooses to help by setting the Features & x04
DMADIR bit.
Pat LaVarre
----- d1532v1r4b ATA-ATAPI-7.pdf
...
21 April 2004
...
[page 169 of 390]
6.18 IDENTIFY PACKET DEVICE [xA1]
...
6.18.18 Word 49: Capabilities
...
Bit 15 of word 49 is used to indicate that the device supports
interleaved DMA data transfer for overlapped DMA commands. Devices
which require the DMADIR bit in the Packet command shall clear this bit
to 0.
...
Bit 8 of word 49 indicates that DMA is supported. Devices which require
the DMADIR bit in the Packet command shall clear this bit to 0
...
6.18.24 Word 62: DMADIR
ATAPI devices that use a serial ATA bridge chip for connection to a
serial ATA host may require use of the DMADIR bit to indicate transfer
direction for Packet DMA commands. Word 62 is used to indicate if such
support is required.
If bit 15 of word 62 is set to one, then DMADIR bit in the Packet
Command is required by the device for Packet DMA and Bits 2:0 of word
63, bits 15 and 8 in word 49, and bits 6:0 of word 88 shall be cleared
to 0,.
If bit 15 of word 62 is cleared to 0, DMADIR bit in the PACKET command
is not required. If bit 15 of word 62 is cleared to zero, then all bits
of word 62 shall be cleared to zero.
Bits (14:11) are reserved.
Bits (10:1) indicate DMA mode support. Since the DMADIR bit is only
used for a Serial ATAPI device, all of these bits are set to 1.
...
6.18.25 Word 63: Multiword DMA transfer
...
If the serial interface is implemented, this bit shall be set to one
except this bit shall be cleared 0 for Serial ATAPI devices requiring
the DMADIR bit in the PACKET command.
...
6.18.41 Word 88:Ultra DMA modes
Word 88 shall have the content described for word 88 of the IDENTIFY
DEVICE command, except bits 6:0 shall be cleared to 0 for Serial ATAPI
devices which require the DMADIR bit in the Packet command.
...
[page 186 of 390]
6.25 PACKET [xA0]
...
6.25.4 Inputs
...
Features register -
DMADIR -
This bit indicates Packet DMA direction and is used only for devices
that implement the Packet Command feature set with a Serial ATA bridge
that require direction indication from the host. Support for this bit
is determined by reading bit 15 of word 62 in the IDENTIFY PACKET
DEVICE data. If bit 15 of word 62 is set to 1, the device requires the
use of the DMADIR bit for Packet DMA commands.
If the device requires the DMADIR bit to be set for Packet DMA
operations and the current operations is DMA (i.e. bit 0, the DMA bit,
is set), this bit indicates the direction of data transfer (0 =
transfer to the device; 1 = transfer to the host). If the device
requires the DMADIR bit to be set for Packet DMA operations but the
current operations is PIO (i.e. bit 0, the DMA bit, is cleared), this
bit is ignored.
Since the data transfer direction will be set by the host as the command
is constructed, the DMADIR bit should not conflict with the data
transfer direction of the command. If a conflict between the command
transfer direction and the DMADIR bit occurs, the device should return
with an ABORTED command, and the sense key set to ILLEGAL REQUEST.
If the device does not require the DMADIR bit for Packet DMA operations,
this bit should be cleared to 0.
A device that does not support the DMADIR feature may abort a command if
the DMADIR bit is set to 1.
...
----
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 18:48 ` Pat LaVarre
@ 2004-05-17 19:08 ` Jeff Garzik
2004-05-17 21:06 ` Pat LaVarre
2004-05-17 21:20 ` Pat LaVarre
0 siblings, 2 replies; 17+ messages in thread
From: Jeff Garzik @ 2004-05-17 19:08 UTC (permalink / raw)
To: Pat LaVarre; +Cc: linux-ide
Pat LaVarre wrote:
> I remember I promised cross-references into the t13.org theories. Over
> time I hope to walk back thru ATA/PI 7, 6, 5, and 4. Here first is most
> of a DMADIR grep in ATA/PI 7, quoted below.
Under the "documents 2003" link on http://www.t13.org/ there is also the
original Silicon Image proposal:
ATAPI DMA Direction issues Proposal 12/21/03 Hartney
http://www.t13.org/docs2003/e03132r3.pdf
Though the latest rev of ATA/ATAPI7 docs are probably a more up-to-date
guide.
> If bit 15 of word 62 is cleared to 0, DMADIR bit in the PACKET command
> is not required. If bit 15 of word 62 is cleared to zero, then all bits
> of word 62 shall be cleared to zero.
I bet your bridge doesn't _require_ DMADIR, therefore it doesn't bother
with word 62? </wild guess>
Jeff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 19:08 ` Jeff Garzik
@ 2004-05-17 21:06 ` Pat LaVarre
2004-05-17 21:40 ` Jeff Garzik
2004-05-17 21:20 ` Pat LaVarre
1 sibling, 1 reply; 17+ messages in thread
From: Pat LaVarre @ 2004-05-17 21:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
> Re: [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI
> From: Jeff Garzik <jgarzik () pobox ! com>
> Date: 2004-05-15 16:39:57
> ...
> > Do you know of some way to detect SI 3611CT80 1.4?
>
> Not right now.
>
> I need to see the full IDENTIFY PACKET DEVICE
> data to discover a way... (and I need to
> write some code before libata dumps the full
> identify-device page)
>
> Other bridges add an identifying string to the
> -end- of the ATA device's model name, maybe
> SiI does too.
Sorry to say,
My op xA1 "IDENTIFY" bytes appear nybble-for-nybble identical, no matter
if sampled via the SATA ATAPI of Si 3611CT80 r1.4 or if sampled via the
original PATA ATAPI.
I quote:
$ cat /var/log/messages | grep ata_dump_id >sata
$ emacs sata
$ # reboot to disconnect bridge from host and from device
$ sudo cat /proc/ide/hdc/identify >pata
$ diff sata pata
12c12
< 203f 0000 0000 0000 0000 404f 0000 0000
---
> 043f 0000 0000 0000 0000 604f 0000 0000
$ #88 . 89 . 90 . 91 . 92 . 93 . 94 . 95 are the "word" indices
$
At first glance, you might think you just saw the upper halves of
"word"s 88 and 93 change, after calculating 88 = 8 * (line 12 - 1)).
But all that's actually changed in "word" 88 is the initially "selected"
UDMA "mode". x20XX = UDMA 5, x04XX = UDMA 2. And all that's actually
changed in "word" 93 is the CBLDID- detect of mask x2000 i.e. you caught
me using a 40-pin PATA cable in place of an 80-pin PATA cable.
Bottom line, all the bits of the "F" set ("F" = "Fixed" = change no more
often than discs change) have not changed.
I presume by intent as yet we don't mean to appear among the devices of
/proc/ide/. I checked all /proc and all /sys, saw our SATA host appear
there voluminously, but nothing that my newbie eye recognised as device
data.
Pat LaVarre
P.S. As I wrote the trivial experimental patch below to gather op xA1
"IDENTIFY" data, I was painfully reminded that DPRINTK flushes per
invocation, not only at EOL, and that /var/log/messages omits duplicate
lines.
diff -Nurp linux-2.6.6-bk4/drivers/scsi/libata-core.c linux-2.6.6-bk4-pel/drivers/scsi/libata-core.c
--- linux-2.6.6-bk4/drivers/scsi/libata-core.c 2004-05-17 12:50:15.000000000 -0600
+++ linux-2.6.6-bk4-pel/drivers/scsi/libata-core.c 2004-05-17 14:18:37.000000000 -0600
@@ -974,6 +974,24 @@ static inline void ata_dump_id(struct at
"93==0x%04x\n",
dev->id[88],
dev->id[93]);
+
+ /* all "word"s, as in lk 2.4 `sudo cat /proc/ide/hd$v/identify` */
+ do {
+ int ix;
+ for (ix = 0; ix < 0x100; ix += 8) {
+ DPRINTK("0x%03X: "
+ "%04x %04x %04x %04x %04x %04x %04x %04x\n",
+ ix * 2,
+ dev->id[ix+0],
+ dev->id[ix+1],
+ dev->id[ix+2],
+ dev->id[ix+3],
+ dev->id[ix+4],
+ dev->id[ix+5],
+ dev->id[ix+6],
+ dev->id[ix+7]);
+ }
+ } while (0);
}
/**
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] libata DMADIR support
2004-05-17 19:08 ` Jeff Garzik
2004-05-17 21:06 ` Pat LaVarre
@ 2004-05-17 21:20 ` Pat LaVarre
2004-05-17 21:32 ` Jeff Garzik
1 sibling, 1 reply; 17+ messages in thread
From: Pat LaVarre @ 2004-05-17 21:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
> "documents 2003" link on http://www.t13.org/ ...
> ATAPI DMA Direction issues Proposal 12/21/03 Hartney
> http://www.t13.org/docs2003/e03132r3.pdf
Links! Thank you.
> > If bit 15 of word 62 is cleared to 0, DMADIR bit in the PACKET command
> > is not required. If bit 15 of word 62 is cleared to zero, then all bits
> > of word 62 shall be cleared to zero.
>
> I bet your bridge doesn't _require_ DMADIR, therefore it doesn't bother
> with word 62? </wild guess>
Your courage in aggressively sharing wild guesses, I appreciate, thank
you, but in this instance:
My memory of my share of the SATA ATAPI UDMA flurry tells me that my Si
3611CT80 r1.4 bridge hangs with status = xD0 if we ask it to copy DMA
Data In, without having prepared op xA0 "PACKET" features = x05 DMA In
rather than x01 DMA Out.
Are you not convinced?
What further experiments should I run or repeat or reemphasise?
I agree, by connecting my compliant only-DMADIR-capable bridge to a
compliant PATA DMA device I have ended up violating ATA/PI 6 by claiming
classic UDMA in op xA1 "IDENTIFY" "word" 88 (line 12 offset 0), when in
fact the abomination I built only actually supports the DMADIR that
ATA/PI 7 claims will be described in "word" 62 (line 7 offset 6).
I see that as me falling into the pit that t13.org dug for me, while I
admittedly wasn't watching closely enough to notice.
I imagine I was not the first and I will not be the last to fall into
this spiked pit. Particularly vulnerable will be the people who resell
compliant PATA ATAPI UDMA devices and then fall into erroneously
believing that adding a compliant SATA/PATA bridge makes a compliant
SATA ATAPI UDMA device.
Do you disagree?
Pat LaVarre
$ cat sata
85c0 0000 0000 0000 0000 0000 0000 0000
0000 0000 3139 3130 4343 3944 4345 3442
4646 4145 2020 2020 0000 0000 0000 3734
2e42 2020 2020 496f 6d65 6761 2020 5252
4420 2020 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 0000
0000 0f00 0000 0200 0000 0006 0000 0000
0000 0000 0000 0000 0000 0000 0000 0007
0003 0078 0078 0078 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0040 0000 4218 4000 4000 4218 0000 4000
203f 0000 0000 0000 0000 404f 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 436f 7079 7269 6768 7420 2863 2920
3230 3034 2049 6f6d 6567 6120 436f 7270
2e20 2041 6c6c 2072 6967 6874 7320 7265
7365 7276 6564 2e00 3032 2f32 372f 3034
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
$
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 21:20 ` Pat LaVarre
@ 2004-05-17 21:32 ` Jeff Garzik
2004-05-17 21:34 ` Jeff Garzik
2004-05-17 22:05 ` Pat LaVarre
0 siblings, 2 replies; 17+ messages in thread
From: Jeff Garzik @ 2004-05-17 21:32 UTC (permalink / raw)
To: Pat LaVarre; +Cc: linux-ide
Pat LaVarre wrote:
> My memory of my share of the SATA ATAPI UDMA flurry tells me that my Si
> 3611CT80 r1.4 bridge hangs with status = xD0 if we ask it to copy DMA
> Data In, without having prepared op xA0 "PACKET" features = x05 DMA In
> rather than x01 DMA Out.
>
> Are you not convinced?
I am convinced that your hardware requires DMADIR.
I am not convinced that there is no way to detect this condition at
runtime, based on some hardware characteristic, or output.
> I agree, by connecting my compliant only-DMADIR-capable bridge to a
> compliant PATA DMA device I have ended up violating ATA/PI 6 by claiming
> classic UDMA in op xA1 "IDENTIFY" "word" 88 (line 12 offset 0), when in
> fact the abomination I built only actually supports the DMADIR that
> ATA/PI 7 claims will be described in "word" 62 (line 7 offset 6).
Well, the expected behavior is proper implementation of word 62, bit 15
at the very least :)
If hardware requires the DMADIR bit, it should set the feature bit that
says "I require DMADIR". If not, one could justifyably claim the
hardware is not operating to spec.
> I imagine I was not the first and I will not be the last to fall into
> this spiked pit. Particularly vulnerable will be the people who resell
> compliant PATA ATAPI UDMA devices and then fall into erroneously
> believing that adding a compliant SATA/PATA bridge makes a compliant
> SATA ATAPI UDMA device.
<shrug> Honestly, I think the requirement of a data-direction bit was
inevitable. I'm surprised you don't have one for ATA devices.
Consider: what data direction will a vendor-reserved SCSI opcode
require? The OS driver cannot know.
If you accept that premise, then these changes to ATA were required...
Jeff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 21:32 ` Jeff Garzik
@ 2004-05-17 21:34 ` Jeff Garzik
2004-05-17 22:05 ` Pat LaVarre
1 sibling, 0 replies; 17+ messages in thread
From: Jeff Garzik @ 2004-05-17 21:34 UTC (permalink / raw)
To: Pat LaVarre; +Cc: linux-ide
Jeff Garzik wrote:
> Consider: what data direction will a vendor-reserved SCSI opcode
> require? The OS driver cannot know.
s/OS driver/bridge/ obviously...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 21:32 ` Jeff Garzik
2004-05-17 21:34 ` Jeff Garzik
@ 2004-05-17 22:05 ` Pat LaVarre
2004-05-17 22:36 ` Jeff Garzik
1 sibling, 1 reply; 17+ messages in thread
From: Pat LaVarre @ 2004-05-17 22:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
> > my Si 3611CT80 r1.4 bridge ...
>
> I am convinced that your hardware requires DMADIR.
Me too.
> I am not convinced that there is no way to detect this condition at
> runtime, based on some hardware characteristic, or output.
I agree.
Shall we try timeout, reset, and retry of the initial DMA op x12
Inquiry?
If that fails for timeout with xD0 status, then we guess oh DMADIR and
try again with Features = x05 Dma In, rather than our default of x01 Dma
Out/classic?
> > My op xA1 "IDENTIFY" bytes appear nybble-for-nybble identical, no
> > matter if sampled via the SATA ATAPI of Si 3611CT80 r1.4 or if
> > sampled via the original PATA ATAPI.
>
> Disappointing...
Yes. We may have a phasing trouble here: the bridge appeared before the
final definition of the relevant op xA1 "IDENTIFY" "word"s.
> word 62
Ouch, ouch, ouch.
I just dug up the fact that mask x0707 of word 62 used to mean single
word DMA e.g. in page 54 of 111, ATA-2 of 1996-03-18, d0948r4c.pdf.
t13.org ATA/PI 7 redefining word 62 to mean DMADIR may become a
pernicious way of searching out anyone who still thinks SWDMA exists.
> <shrug> Honestly, I think the requirement of a data-direction bit was
> inevitable. I'm surprised you don't have one for ATA devices.
> Consider: what data direction will a vendor-reserved SCSI opcode
> require? The OS driver cannot know.
>
> If you accept that premise, then these changes to ATA were required...
I agree, vehemently.
Indeed, we have more trouble coming eventually. If we compare the
serial USB CBW to what we see on a serial SATA emulation of a parallel
PATA cable, what's missing is:
bCBLength = length of the CDB
bmCBWFlags.Direction = Data In/Out
dCSWDataResidue = data bytes clocked but not copied
All the missing info causes trouble in one way or another. Also both
USB and ATAPI die when we cross the 64-bit lba barrier that takes us
past 16 bytes/CDB. Also both may break as aligning data only to 32-bit
boundaries rather than 64-bit boundaries starts to matter.
> > Consider: what data direction will a vendor-reserved SCSI opcode
> > require? The OS driver cannot know.
>
> s/OS driver/bridge/ obviously...
I think you're saying that knowing the SCSI opcode does not decide the
data copy direction.
I agree, vehemently.
By definition, knowing the opcode cannot decide the data copy direction
of vendor-specific and newly standard commands.
Also in theory, the data copy direction of SCSI opcodes may vary in
accord with PDT (= Peripheral Device Type = mask x1F of byte 0 of op x12
"INQUIRY" = x 0E/ 07/ 04/ 00 SBC of HDD/ Flash = x05 MMC of DVD/CD).
Also in practice, some (rudely designed) vendor-specific ops move data
both ways.
None of those facts have kept people over the years from writing host
software that thinks the op decides the direction. I think I remember
seeing Linux-2.2 broken that way.
Pat LaVarre
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 22:05 ` Pat LaVarre
@ 2004-05-17 22:36 ` Jeff Garzik
2004-05-17 23:04 ` Pat LaVarre
2004-05-18 22:40 ` Pat LaVarre
0 siblings, 2 replies; 17+ messages in thread
From: Jeff Garzik @ 2004-05-17 22:36 UTC (permalink / raw)
To: Pat LaVarre; +Cc: linux-ide
Pat LaVarre wrote:
>>I am not convinced that there is no way to detect this condition at
>>runtime, based on some hardware characteristic, or output.
>
>
> I agree.
>
> Shall we try timeout, reset, and retry of the initial DMA op x12
> Inquiry?
>
> If that fails for timeout with xD0 status, then we guess oh DMADIR and
> try again with Features = x05 Dma In, rather than our default of x01 Dma
> Out/classic?
I dunno. Feel free to play around. :)
Silicon Image is sending me a couple bridges, we'll see how they behave.
>>word 62
>
>
> Ouch, ouch, ouch.
>
> I just dug up the fact that mask x0707 of word 62 used to mean single
> word DMA e.g. in page 54 of 111, ATA-2 of 1996-03-18, d0948r4c.pdf.
>
> t13.org ATA/PI 7 redefining word 62 to mean DMADIR may become a
> pernicious way of searching out anyone who still thinks SWDMA exists.
SWDMA never existed for ATAPI devices. Word 62 has -always- been
reserved, until now.
> None of those facts have kept people over the years from writing host
> software that thinks the op decides the direction. I think I remember
> seeing Linux-2.2 broken that way.
Yep. Bart, our illustrious IDE maintainer, recently removed one such
opcode table.
Jeff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 22:36 ` Jeff Garzik
@ 2004-05-17 23:04 ` Pat LaVarre
2004-05-18 22:40 ` Pat LaVarre
1 sibling, 0 replies; 17+ messages in thread
From: Pat LaVarre @ 2004-05-17 23:04 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
>>> word 62
>> Ouch, ouch, ouch.
>> I just dug up the fact that mask x0707 of word 62 used to mean single
>> word DMA e.g. in page 54 of 111, ATA-2 of 1996-03-18, d0948r4c.pdf.
>> t13.org ATA/PI 7 redefining word 62 to mean DMADIR may become a
>> pernicious way of searching out anyone who still thinks SWDMA exists.
>
> SWDMA never existed for ATAPI devices. Word 62 has -always- been
> reserved, until now.
To SFF we owe many perniciously slight binary incompatibilities. Re
ops xEC/A1 "IDENTIFY" we have:
----- http://www.google.com/search?q=storage+cornucopia
----- http://www.bswd.com/cornucop.htm
----- SFF-8020i, Rev. 2.6: ATAPI for CD-ROMs (old and antiquated)
----- http://www.bswd.com/sff8020i.pdf
... January 22, 1996 ...
----- page 80 of 224
7.1.7.9 Single Word DMA Transfer (Word 62) The low order byte
identifies by bit all of the modes which are supported, e.g., if Mode 0
is supported, bit 0 is set. The high order byte contains a single bit
set to indicate which mode is active, e.g., if Word 0 is active, bit8
is set.
-----
Pat LaVarre
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-17 22:36 ` Jeff Garzik
2004-05-17 23:04 ` Pat LaVarre
@ 2004-05-18 22:40 ` Pat LaVarre
2004-05-18 23:07 ` Pat LaVarre
1 sibling, 1 reply; 17+ messages in thread
From: Pat LaVarre @ 2004-05-18 22:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
> Feel free to play around. :)
>
> Silicon Image is sending me a couple bridges, we'll see how they
> behave.
Heads up, I have a second sample of hardware now:
kernel: ata_exec_command_pio: ata2: cmd 0xA1
kernel: ata2: dev 0 cfg 49:0e00 82:4218 83:4000 84:4000 85:4218 86:0000 87:4000 88:0000
Its ata_piix.ko op x12 "INQUIRY" doesn't yet work at all, perhaps by way
of more accurately simulating what we may see in mass distribution.
You'll remember, the first hardware sample I acquired was a
massively-distributed PATA ATAPI DMA drive combined with an Si 3611CT80
r1.4 SATA/ PATA bridge.
My second sample is that same bridge, but now with a different drive
behind it, specifically a drive whose firmware purportedly implements
the "d1532v1r4b ATA-ATAPI-7.pdf" proposal to substitute:
PATA ATAPI:
id[49] = id[ 7 * 8 - 8 + 1] = x0F00 // DMA
id[62] = id[ 8 * 8 - 8 + 6] = x0000 // SWDMA not
id[63] = id[ 8 * 8 - 8 + 7] = x0007 // MWDMA 2 1 0
id[88] = id[12 * 8 - 8 + 0] = xXX3F // UDMA 5 4 2 1 0
SATA ATAPI per 2004-04-21 d1532v1r4b:
id[49] = id[ 7 * 8 - 8 + 1] = x0E00
id[62] = id[ 8 * 8 - 8 + 6] = x87FF // ATA-7: DMADIR, ATA-2: SWDMA 2 1 0
id[63] = id[ 8 * 8 - 8 + 7] = x0000
id[88] = id[12 * 8 - 8 + 0] = xXX00
I'll go digging now.
I imagine I'll find I can most concisely make this work by copying into
words 49 63 88 the bits of word 62.
Pat LaVarre
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] libata DMADIR support
2004-05-18 22:40 ` Pat LaVarre
@ 2004-05-18 23:07 ` Pat LaVarre
2004-05-18 23:50 ` Jeff Garzik
0 siblings, 1 reply; 17+ messages in thread
From: Pat LaVarre @ 2004-05-18 23:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
> a second sample of hardware ...
>
> kernel: ata_exec_command_pio: ata2: cmd 0xA1
> kernel: ata2: dev 0 cfg 49:0e00 82:4218 83:4000 84:4000 85:4218 86:0000 87:4000 88:0000
>
> Its ata_piix.ko op x12 "INQUIRY" doesn't yet work at all ...
>
> I imagine I'll find I can most concisely make this work by copying into
> words 49 63 88 the bits of word 62.
Yep.
diff -Nurp linux-2.6.6-bk5/drivers/scsi/libata-core.c linux-2.6.6-bk5-pel/drivers/scsi/libata-core.c
--- linux-2.6.6-bk5/drivers/scsi/libata-core.c 2004-05-18 14:20:05.000000000 -0600
+++ linux-2.6.6-bk5-pel/drivers/scsi/libata-core.c 2004-05-18 16:53:29.000000000 -0600
@@ -1076,6 +1076,22 @@ retry:
ata_irq_on(ap); /* re-enable interrupts */
+ /* see DMADIR as a variation on classic UDMA/ MWDMA */
+
+#ifdef ATAPI_ENABLE_DMADIR
+ printk(KERN_DEBUG "ata%u: dev %u cfg "
+ "62:%04x\n",
+ ap->id, device, dev->id[62]);
+ if (dev->id[62] & (1 << 15)) { /* 0x8000 DMADIR */
+ u16 * id = dev->id;
+ if (id[62] & (1 << 10)) { /* 0x0400 DMA */
+ id[49] |= (1 << 8);
+ id[63] |= ((id[62] >> 7) & 0x07); /* 0x0380 MWDMA */
+ id[88] |= ((id[62] >> 0) & 0x3F); /* 0x007F UDMA */
+ }
+ }
+#endif
+
/* print device capabilities */
printk(KERN_DEBUG "ata%u: dev %u cfg "
"49:%04x 82:%04x 83:%04x 84:%04x 85:%04x 86:%04x 87:%04x 88:%04x\n",
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] libata DMADIR support
2004-05-18 23:07 ` Pat LaVarre
@ 2004-05-18 23:50 ` Jeff Garzik
2004-05-19 22:47 ` Pat LaVarre
0 siblings, 1 reply; 17+ messages in thread
From: Jeff Garzik @ 2004-05-18 23:50 UTC (permalink / raw)
To: Pat LaVarre; +Cc: linux-ide
Pat LaVarre wrote:
> +#ifdef ATAPI_ENABLE_DMADIR
> + printk(KERN_DEBUG "ata%u: dev %u cfg "
> + "62:%04x\n",
> + ap->id, device, dev->id[62]);
> + if (dev->id[62] & (1 << 15)) { /* 0x8000 DMADIR */
> + u16 * id = dev->id;
> + if (id[62] & (1 << 10)) { /* 0x0400 DMA */
> + id[49] |= (1 << 8);
> + id[63] |= ((id[62] >> 7) & 0x07); /* 0x0380 MWDMA */
> + id[88] |= ((id[62] >> 0) & 0x3F); /* 0x007F UDMA */
> + }
> + }
> +#endif
Yeah, something like this needs to be done for DMADIR bridges.
Jeff
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] libata DMADIR support
2004-05-18 23:50 ` Jeff Garzik
@ 2004-05-19 22:47 ` Pat LaVarre
0 siblings, 0 replies; 17+ messages in thread
From: Pat LaVarre @ 2004-05-19 22:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
> Yeah, something like this needs to be done for DMADIR bridges.
Do you like FIXME? Merging the following would help me remember where
to bring this up again after we get more of ATAPI_ENABLE_DMADIR working.
Pat LaVarre
diff -Nurp linux-2.6.6-bk6/drivers/scsi/libata-core.c linux-2.6.6-bk6-pel/drivers/scsi/libata-core.c
--- linux-2.6.6-bk6/drivers/scsi/libata-core.c 2004-05-19 13:35:25.000000000 -0600
+++ linux-2.6.6-bk6-pel/drivers/scsi/libata-core.c 2004-05-19 16:44:52.974294696 -0600
@@ -1059,6 +1059,8 @@ retry:
ata_irq_on(ap); /* re-enable interrupts */
+ /* FIXME: infer UDMA/ MWDMA from new DMADIR dev->id[62] (was SWDMA) */
+
/* print device capabilities */
printk(KERN_DEBUG "ata%u: dev %u cfg "
"49:%04x 82:%04x 83:%04x 84:%04x 85:%04x 86:%04x 87:%04x 88:%04x\n",
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-05-19 22:47 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-15 21:46 [PATCH] libata DMADIR support Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2004-05-16 14:19 Pat LaVarre
2004-05-16 23:16 ` Jeff Garzik
2004-05-17 18:48 ` Pat LaVarre
2004-05-17 19:08 ` Jeff Garzik
2004-05-17 21:06 ` Pat LaVarre
2004-05-17 21:40 ` Jeff Garzik
2004-05-17 21:20 ` Pat LaVarre
2004-05-17 21:32 ` Jeff Garzik
2004-05-17 21:34 ` Jeff Garzik
2004-05-17 22:05 ` Pat LaVarre
2004-05-17 22:36 ` Jeff Garzik
2004-05-17 23:04 ` Pat LaVarre
2004-05-18 22:40 ` Pat LaVarre
2004-05-18 23:07 ` Pat LaVarre
2004-05-18 23:50 ` Jeff Garzik
2004-05-19 22:47 ` Pat LaVarre
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).