* [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI mage
@ 2004-05-15 14:20 Pat LaVarre
2004-05-15 14:33 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 6+ messages in thread
From: Pat LaVarre @ 2004-05-15 14:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]
> > > Subject: Re: SATA ATAPI work in progress
> > > ...
> > > I doubt I can use this patch as is. I believe,
> > > because I assembled my drive from components myself,
> > > its op xA1 Identify data has not changed,
> > > so I will see a misleading 0 False at:
> > >
> > > #define ata_id_use_dmadir(dev) ((dev)->id[62] & (1 << 15))
>
> Theory confirmed!
Consequently now:
In t13.org since the dawn of time, I see the requirement that compliant
ATAPI devices tolerate hosts creatively choosing to copy
(cmd->sc_data_direction != SCSI_DATA_WRITE) into (ata_taskfile.feature &
x04 ATAPI_DMADIR).
I see devices constructed with Silicon Image 3611CT80 1.4 require such a
courtesy from the host.
Therefore I propose that Linux, as host, offer that courtesy always.
Pat LaVarre
P.S. Of course I still agree the firmware of devices manufactured with
this perhaps excessively transparent SATA/ PATA bridge should set "word"
62 mask x8000 ata_id_use_dmadir, after that proposal in fact becomes a
t13.org standard, presuming that standards development process doesn't
move or flip that bit.
Indeed, after the proposal is standard, I'll argue all PATA devices
should set this bit, on the chance that their actual connection with the
host is such an extremely transparent SATA/ PATA bridge.
But that argument I expect to lose to the fear that some hosts will
choose to refuse to speak DMA with devices that set ata_id_use_dmadir,
rather than choosing to disclose (cmd->sc_data_direction !=
SCSI_DATA_WRITE).
P.P.S. In passing in include/linux/, I vote we teach Linux to enum
together all the bits of the ata_taskfile.feature parameter of ATA op
xA0 ATA_CMD_PACKET.
--- o/drivers/scsi/libata-core.c 2004-05-15 07:31:49.000000000 -0600
+++ linux-2.6.6-bk1/drivers/scsi/libata-core.c 2004-05-15 07:53:40.520947904 -0600
@@ -1168,8 +1168,10 @@ retry:
if (ata_id_is_ata(dev)) /* sanity check */
goto err_out_nosup;
- if (ata_id_use_dmadir(dev))
- dev->flags |= ATA_DFLAG_DMADIR;
+ /* share cmd->sc_data_direction with device
+ * even when (!ata_id_use_dmadir(dev)) claims not needed
+ */
+ dev->flags |= ATA_DFLAG_DMADIR;
/* see if 16-byte commands supported */
tmp = dev->id[0] & 0x3;
--- o/include/linux/ata.h 2004-05-15 07:09:33.000000000 -0600
+++ linux-2.6.6-bk1/include/linux/ata.h 2004-05-15 07:58:15.181193200 -0600
@@ -84,8 +84,6 @@ enum {
ATA_ERR = (1 << 0), /* have an error */
ATA_SRST = (1 << 2), /* software reset */
ATA_ABORTED = (1 << 2), /* command aborted */
- ATAPI_DMADIR = (1 << 2), /* ATAPI data dir:
- 0=to device, 1=to host */
/* ATA command block registers */
ATA_REG_DATA = 0x00,
@@ -136,6 +134,8 @@ enum {
/* 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,
[-- Attachment #2: pel.patch.7b --]
[-- Type: text/x-troff-man, Size: 1193 bytes --]
--- o/drivers/scsi/libata-core.c 2004-05-15 07:31:49.000000000 -0600
+++ linux-2.6.6-bk1/drivers/scsi/libata-core.c 2004-05-15 07:53:40.520947904 -0600
@@ -1168,8 +1168,10 @@ retry:
if (ata_id_is_ata(dev)) /* sanity check */
goto err_out_nosup;
- if (ata_id_use_dmadir(dev))
- dev->flags |= ATA_DFLAG_DMADIR;
+ /* share cmd->sc_data_direction with device
+ * even when (!ata_id_use_dmadir(dev)) claims not needed
+ */
+ dev->flags |= ATA_DFLAG_DMADIR;
/* see if 16-byte commands supported */
tmp = dev->id[0] & 0x3;
--- o/include/linux/ata.h 2004-05-15 07:09:33.000000000 -0600
+++ linux-2.6.6-bk1/include/linux/ata.h 2004-05-15 07:58:15.181193200 -0600
@@ -84,8 +84,6 @@ enum {
ATA_ERR = (1 << 0), /* have an error */
ATA_SRST = (1 << 2), /* software reset */
ATA_ABORTED = (1 << 2), /* command aborted */
- ATAPI_DMADIR = (1 << 2), /* ATAPI data dir:
- 0=to device, 1=to host */
/* ATA command block registers */
ATA_REG_DATA = 0x00,
@@ -136,6 +134,8 @@ enum {
/* 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,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI mage
2004-05-15 14:20 [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI mage Pat LaVarre
@ 2004-05-15 14:33 ` Bartlomiej Zolnierkiewicz
2004-05-15 16:15 ` Jeff Garzik
0 siblings, 1 reply; 6+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2004-05-15 14:33 UTC (permalink / raw)
To: Pat LaVarre, Jeff Garzik; +Cc: linux-ide
On Saturday 15 of May 2004 16:20, Pat LaVarre wrote:
> > > > Subject: Re: SATA ATAPI work in progress
> > > > ...
> > > > I doubt I can use this patch as is. I believe,
> > > > because I assembled my drive from components myself,
> > > > its op xA1 Identify data has not changed,
> > > > so I will see a misleading 0 False at:
> > > >
> > > > #define ata_id_use_dmadir(dev) ((dev)->id[62] & (1 << 15))
> >
> > Theory confirmed!
>
> Consequently now:
>
> In t13.org since the dawn of time, I see the requirement that compliant
> ATAPI devices tolerate hosts creatively choosing to copy
> (cmd->sc_data_direction != SCSI_DATA_WRITE) into (ata_taskfile.feature &
> x04 ATAPI_DMADIR).
>
> I see devices constructed with Silicon Image 3611CT80 1.4 require such a
> courtesy from the host.
>
> Therefore I propose that Linux, as host, offer that courtesy always.
Makes sense.
Jeff, if you decide to do this remember to kill ata_id_use_dmadir()
and ATA_DFLAG_DMADIR completely. [ I'm sure you will. :-) ]
> Pat LaVarre
>
> P.S. Of course I still agree the firmware of devices manufactured with
> this perhaps excessively transparent SATA/ PATA bridge should set "word"
> 62 mask x8000 ata_id_use_dmadir, after that proposal in fact becomes a
> t13.org standard, presuming that standards development process doesn't
> move or flip that bit.
>
> Indeed, after the proposal is standard, I'll argue all PATA devices
> should set this bit, on the chance that their actual connection with the
> host is such an extremely transparent SATA/ PATA bridge.
>
> But that argument I expect to lose to the fear that some hosts will
> choose to refuse to speak DMA with devices that set ata_id_use_dmadir,
> rather than choosing to disclose (cmd->sc_data_direction !=
> SCSI_DATA_WRITE).
>
> P.P.S. In passing in include/linux/, I vote we teach Linux to enum
> together all the bits of the ata_taskfile.feature parameter of ATA op
> xA0 ATA_CMD_PACKET.
>
> --- o/drivers/scsi/libata-core.c 2004-05-15 07:31:49.000000000 -0600
> +++ linux-2.6.6-bk1/drivers/scsi/libata-core.c 2004-05-15
> 07:53:40.520947904 -0600 @@ -1168,8 +1168,10 @@ retry:
> if (ata_id_is_ata(dev)) /* sanity check */
> goto err_out_nosup;
>
> - if (ata_id_use_dmadir(dev))
> - dev->flags |= ATA_DFLAG_DMADIR;
> + /* share cmd->sc_data_direction with device
> + * even when (!ata_id_use_dmadir(dev)) claims not needed
> + */
> + dev->flags |= ATA_DFLAG_DMADIR;
>
> /* see if 16-byte commands supported */
> tmp = dev->id[0] & 0x3;
> --- o/include/linux/ata.h 2004-05-15 07:09:33.000000000 -0600
> +++ linux-2.6.6-bk1/include/linux/ata.h 2004-05-15 07:58:15.181193200 -0600
> @@ -84,8 +84,6 @@ enum {
> ATA_ERR = (1 << 0), /* have an error */
> ATA_SRST = (1 << 2), /* software reset */
> ATA_ABORTED = (1 << 2), /* command aborted */
> - ATAPI_DMADIR = (1 << 2), /* ATAPI data dir:
> - 0=to device, 1=to host */
>
> /* ATA command block registers */
> ATA_REG_DATA = 0x00,
> @@ -136,6 +134,8 @@ enum {
>
> /* 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,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI mage
2004-05-15 14:33 ` Bartlomiej Zolnierkiewicz
@ 2004-05-15 16:15 ` Jeff Garzik
2004-05-15 16:38 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2004-05-15 16:15 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Pat LaVarre, linux-ide
Bartlomiej Zolnierkiewicz wrote:
> On Saturday 15 of May 2004 16:20, Pat LaVarre wrote:
>
>>>>>Subject: Re: SATA ATAPI work in progress
>>>>>...
>>>>>I doubt I can use this patch as is. I believe,
>>>>>because I assembled my drive from components myself,
>>>>>its op xA1 Identify data has not changed,
>>>>>so I will see a misleading 0 False at:
>>>>>
>>>>>#define ata_id_use_dmadir(dev) ((dev)->id[62] & (1 << 15))
>>>
>>>Theory confirmed!
>>
>>Consequently now:
>>
>>In t13.org since the dawn of time, I see the requirement that compliant
>>ATAPI devices tolerate hosts creatively choosing to copy
>>(cmd->sc_data_direction != SCSI_DATA_WRITE) into (ata_taskfile.feature &
>>x04 ATAPI_DMADIR).
>>
>>I see devices constructed with Silicon Image 3611CT80 1.4 require such a
>>courtesy from the host.
>>
>>Therefore I propose that Linux, as host, offer that courtesy always.
>
>
> Makes sense.
>
> Jeff, if you decide to do this remember to kill ata_id_use_dmadir()
> and ATA_DFLAG_DMADIR completely. [ I'm sure you will. :-) ]
According to ATA/ATAPI7,
A device that does not support the DMADIR feature may abort a
command if the DMADIR bit is set to 1.
And this language makes sense, since it is unknown what all those cheap
old ATAPI devices will do. It's too risky to simply set this bit for
all ATAPI devices, without lots of testing.
We can do so for our development here, but a better solution based on
released parts will need to be found...
Jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI mage
2004-05-15 16:15 ` Jeff Garzik
@ 2004-05-15 16:38 ` Bartlomiej Zolnierkiewicz
2004-05-15 16:39 ` Jeff Garzik
2004-05-15 16:46 ` [PATCH] libata-core when not ata_id_use_dmadir despite yesSili conI mage Pat LaVarre
0 siblings, 2 replies; 6+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2004-05-15 16:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Pat LaVarre, linux-ide
On Saturday 15 of May 2004 18:15, Jeff Garzik wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Saturday 15 of May 2004 16:20, Pat LaVarre wrote:
> >>>>>Subject: Re: SATA ATAPI work in progress
> >>>>>...
> >>>>>I doubt I can use this patch as is. I believe,
> >>>>>because I assembled my drive from components myself,
> >>>>>its op xA1 Identify data has not changed,
> >>>>>so I will see a misleading 0 False at:
> >>>>>
> >>>>>#define ata_id_use_dmadir(dev) ((dev)->id[62] & (1 << 15))
> >>>
> >>>Theory confirmed!
> >>
> >>Consequently now:
> >>
> >>In t13.org since the dawn of time, I see the requirement that compliant
> >>ATAPI devices tolerate hosts creatively choosing to copy
> >>(cmd->sc_data_direction != SCSI_DATA_WRITE) into (ata_taskfile.feature &
> >>x04 ATAPI_DMADIR).
> >>
> >>I see devices constructed with Silicon Image 3611CT80 1.4 require such a
> >>courtesy from the host.
> >>
> >>Therefore I propose that Linux, as host, offer that courtesy always.
> >
> > Makes sense.
> >
> > Jeff, if you decide to do this remember to kill ata_id_use_dmadir()
> > and ATA_DFLAG_DMADIR completely. [ I'm sure you will. :-) ]
>
> According to ATA/ATAPI7,
>
> A device that does not support the DMADIR feature may abort a
> command if the DMADIR bit is set to 1.
>
> And this language makes sense, since it is unknown what all those cheap
> old ATAPI devices will do. It's too risky to simply set this bit for
> all ATAPI devices, without lots of testing.
OK
> We can do so for our development here, but a better solution based on
> released parts will need to be found...
Do you know of some way to detect SI 3611CT80 1.4?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI mage
2004-05-15 16:38 ` Bartlomiej Zolnierkiewicz
@ 2004-05-15 16:39 ` Jeff Garzik
2004-05-15 16:46 ` [PATCH] libata-core when not ata_id_use_dmadir despite yesSili conI mage Pat LaVarre
1 sibling, 0 replies; 6+ messages in thread
From: Jeff Garzik @ 2004-05-15 16:39 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Pat LaVarre, linux-ide
Bartlomiej Zolnierkiewicz wrote:
> On Saturday 15 of May 2004 18:15, Jeff Garzik wrote:
>>We can do so for our development here, but a better solution based on
>>released parts will need to be found...
>
>
> 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.
Jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] libata-core when not ata_id_use_dmadir despite yesSili conI mage
2004-05-15 16:38 ` Bartlomiej Zolnierkiewicz
2004-05-15 16:39 ` Jeff Garzik
@ 2004-05-15 16:46 ` Pat LaVarre
1 sibling, 0 replies; 6+ messages in thread
From: Pat LaVarre @ 2004-05-15 16:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, Bartlomiej Zolnierkiewicz
> > We can do so for our development here, but a better solution based on
> > released parts will need to be found...
>
> Do you know of some way to detect SI 3611CT80 1.4?
I don't.
Jeff G, do you?
> > And this language makes sense, since it is unknown what all those cheap
> > old ATAPI devices will do. It's too risky to simply set this bit for
> > all ATAPI devices, without lots of testing.
>
> OK
Yes.
> > According to ATA/ATAPI7,
> >
> > A device that does not support the DMADIR feature may abort a
> > command if the DMADIR bit is set to 1.
I believe this is a t13.org change that is NOT backwards-compatible,
analogous to the theft I remember of op xEC Identify "word" 128.
I will double-check ATA/ATAPI 4/ 5/ 6 and report the relevant language
here.
Pat LaVarre
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-05-15 16:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-15 14:20 [PATCH] libata-core when not ata_id_use_dmadir despite yes SiliconI mage Pat LaVarre
2004-05-15 14:33 ` Bartlomiej Zolnierkiewicz
2004-05-15 16:15 ` Jeff Garzik
2004-05-15 16:38 ` Bartlomiej Zolnierkiewicz
2004-05-15 16:39 ` Jeff Garzik
2004-05-15 16:46 ` [PATCH] libata-core when not ata_id_use_dmadir despite yesSili conI mage 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).