Re: [PATCH] libata DMADIR support

[Pat LaVarre <p.lavarre@ieee.org>]

> > 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