Re: WIP: ATA to CAM integration

Hi.

Matthew Dillon wrote:
>     The biggest issue with AHCI (and ATA) interfacing is that AHCI devices
>     attach either as DISK or ATAPI.  A device which attaches as a DISK
>     does not typically support ATAPI commands (though it would be an
>     interesting experiment to see if some did).  This means that no matter
>     what you do a SCSI<->ATA translation layer needs to do some significant
>     fake-ups for DISK attachments, similar to what OpenBSD does in their
>     SCSI<->ATA layer.  ATA DISK attachments simply do not support enough
>     of the SCSI command set for direct integration into CAM (IMHO).

I think ATAPI disk device is theoretically possible, but I believe it 
does not exist in practice, as industry do not need it. It will become 
SCSI disk opponent from commands PoV, but with all ATA interface ugly 
growth problems. And I am not sure that it will have more benefits then 
contras comparing to SCSI or plain ATA.

When I was talking about common CAM layer, I was directly speaking that 
there will be _no_command_translation_ for ATA disks! There will be 
separate native ATA disk driver withing CAM infrastructure.

>     The second biggest issue is that it is really unclear to me how the
>     hell one probes an ATAPI device for NCQ support.  The OpenBSD driver
>     only uses AHCI-NCQ for DISK attachments, where the NCQ support is
>     returned in the IDENTIFY command.  I'm sure there must be a way to
>     probe an ATAPI device for NCQ support but I don't know what it is.

I have never seen opposite, and I believe that NCQ is just not 
implemented for ATAPI devices. NCQ requires different ATA commands usage 
for ATA disk drives and that makes drive to behave very different on FIS 
level. NCQ uses First Party DMA and special command completion FISes, 
that IMHO just not implemented for ATA PACKET command.

>     The OpenBSD driver does not have port multiplier support but adding
>     it to the DFly driver will be pretty easy... I just need some hardware
>     to test it with (it's on the way).   Unfortunately the AHCI-1.0
>     specfication says it cannot be used for high-performance multi-disk
>     I/O because all parallel commands in operation are only allowed to go
>     to a single target at a time.  i.e. you can't mix parallel commands
>     to different targets on the same port.  That's a serious problem.
> 
>     (Does anyone know if the AHCI-1.1 or 1.2 specifications do anything
>     about that?).

Latest AHCI specifications define feature named FIS Based Switching. It 
allows controller independently track state of every device beyond port 
multiplier. It should be quite easy to use it, but actually none of my 
controllers have that capability.

>     It is unclear to me from reading the specification as to whether
>     AHCI-NCQ is supported for SATA ATAPI attachments.  If anyone has an
>     answer to that I'm looking for a way to probe the device's
>     max-commands for ATAPI.  for DISKs the IDENTIFY command has the
>     necessary feature bits and information.  I'm sure the host controller
>     supports it natively but the real question is how to probe
>     the capability on the attached device and whether the device(s)
>     support it.

ATAPI devices have their own equivalent of ATA IDENTIFY command.

>     Ultimately the best way to expand-out an AHCI interface is with
>     SCSI pass-through over ATAPI, assuming NCQ can be supported somehow.
>     The port-multiplier spec is badly broken (at least in Intel's AHCI-1.0
>     spec).  It is a bit annoying, actually, I wouldn't have though that
>     Intel would have made such a basic mistake.  All they had to do was
>     implement 4 bits in the FIS and the problem would have been solved.
>     Instead they have routing bits in a port register.  Sigh.

Latest AHCI specifications are definitely better, but now we have a lot 
of hardware conforming early 1.0 and 1.1 revisions.

-- 
Alexander Motin