Re: WIP: ATA to CAM integration
- From: Alexander Motin <mav@xxxxxxxxxxxxx>
- Date: Fri, 05 Jun 2009 19:54:27 +0300
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
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: WIP: ATA to CAM integration
- From: Poul-Henning Kamp
- Re: WIP: ATA to CAM integration
- From: Matthew Dillon
- Re: WIP: ATA to CAM integration
- References:
- WIP: ATA to CAM integration
- From: Alexander Motin
- Re: WIP: ATA to CAM integration
- From: Matthew Dillon
- WIP: ATA to CAM integration
- Prev by Date: Re: Clang: now available from a SVN server near you!
- Next by Date: Re: WIP: ATA to CAM integration
- Previous by thread: Re: WIP: ATA to CAM integration
- Next by thread: Re: WIP: ATA to CAM integration
- Index(es):
Relevant Pages
|
