Matthew Dillon wrote: > More on the port multiplier spec. It turns out that the port-multiplier > port selector is in the command table, so it is per command-tag. There > is confusion in the spec though: > > section 9.1: > > In this mode of operation, a communication path is opened between the > HBA and a device through the Port Multiplier. Since Port Multipliers are > meant to be simple, the burden of making a connection is on the AHCI > software, to ensure that multiple commands are not outstanding to > different devices behind the Port Multiplier. > > section 9.1.2: > > "Since queued commands result in two different operations (command issue, > clear of BSY, then data transfer), if commands were sent to different > ports, the Port Multiplier may issue FISes back to the HBA in > an interleaved manner from different ports. This will break an HBA that > only supports command-based switching. Therefore, when executing native > command queueing commands, system software must only add commands > to the command list that target a single port behind the Port Multiplier, > wait for the commands to finish (PxSACT bits all cleared), then add > commands for a different port. Additionally, the tags used > must match the command slot entries." > > -- > > It's unclear to me what this means. Can we use NCQ to queue multiple > commands to multiple ports behind a single port multiplier in parallel > or can't we? It's very confusing. As I read the above, this: > ensure that multiple commands are not outstanding to > different devices behind the Port Multiplier combined with this: > system software must only add commands > to the command list that target a *single port* behind the Port Multiplier, > *wait for the commands to finish* suggests strongly that you many not send multiple commands out to a single port multiplier. However, I agree that it's not crystal clear, and may not be what was intended. GaryReceived on Fri Jun 05 2009 - 14:34:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:49 UTC