The crazy (escalating from weird) rules to workaround the HW bug(s) mean
that we need to chop up the command tag range into blocks of 32 even tag
indexes per SATA device; this means that SATA device #0 can use 64, 66,
68, 70...126. device #1 can use 128, 130, 132,..., device #2 can use
192, 194,...
I don't know how you can take a rq tag and generate a command tag
suitable for a SATA device.
Actually, you can.
We can setup a _distinct_ tagset per SATA device.
Eg we can setup a shared tagset for SAS (which is half the size of the
original tagset), and shift the tags by one to get a valid SAS tag.
For SATA we can setup a _distinct_ tagset per device, containing 32
tags. The we can invoke some calculation to transform the tag (which is
not guaranteed to be in the range of 0-31) into a valid hardware tag.
Should actually work.
ok, fine. I suppose that each SATA device having its own tagset could be
more efficient, as in reality the tags are separate.
Problem is that we'd need to set aside some tags for TMF,
It not just TMF to consider, but the HW also supports "internal abort",
which also requires a unique tag. And in some scenarios we send ATA
softreset, as is the abort flow design for this host.
but I really
don't think that we can or should do command aborts on SATA; while there
is the 'abort NCQ' command, it'll work only for NCQ commands, and won't
help us for 'normal' commands.
And seeing that on error all NCQ commands will be aborted anyway, plus
the standard ATA error handler will be resulting into a device reset, I
guess we should skip command abort on SATA and escalate to device reset
straightaway. That would also have the nice benefit that we need only to
set _one_ tag aside for TMF, as we will only send one TMF at a time.
Yeah, I think that it should be ok. All error handlng is sequential.
Thanks very much,
John
Cheers,
Hannes
