Hello, On 12/02/2010 11:23 AM, Lin Mac wrote: >> One thing which could be possible is that the controller stashes the >> result code for the PMP aware SRST according to the PMP number instead >> of the usual place, so the driver can't see it. In that case, the >> driver can be modified to check both places I suppose but if the >> hardware can be fixed, that would be great. > the usual place, I presume you mean PxTFD+PxSIG. > I've check RFIS of received FIS structure after softreset failed and > nothing there. (UFIS neither) > Is there any other suspect to check? Have you checked all PxTFDs? It could be that the controller is saving it in the wrong slot. > My situation is that device is sending D2H Reg FIS, but controller is > not reflecting it on PxTFD, PxSIG, or RFIS of received FIS > structure.With the patch I sent, it seems the controller receives D2H > Reg FIS of the same PMP setting of the previous sent H2D Reg FIS, and > drop the different one. If the controller is dropping the D2H Reg FIS altogether, it'll probably need more intricate workaround. :-( > The AHCI controller I used is AHCI v1.1 compatible, command-based switching. > > In SATA spec (rev2.6) 16.7.1, it says: > > A host controller may support command-based switching by implementing > the Port Multiplier Port (PMP) field in the SControl register as > detailed in section 14.1.3.In order to use this mechanism, host > software would set the PMP field appropriately before issuing a > command to a device conected to the Port Multiplier. (...) Note that > the PMP field shall be set to the control port when host software > issues commands to the Port Multiplier itself. > -- > > In AHCI spec, the PMP field of PxSCTL "is not used by AHCI".Does it > implies AHCI would set it and software doesn't need to do anything? > > 13.13.4.1 Port Multiplier Discovery > If a device is present, the host issues a software reset with the PM > Port field set to the control port. The host checks the signature > value returned and if.... > -- > > SATA spec didn't says what to do IF it received a data with PMP > setting doesn't match it's current setting (did it?). While 13.13.4.1 > only implies the host should receive the signature successfully, even > if it is of different PMP setting. The probing sequence is described somewhere in the ahci spec and I'm fairly sure the dropping behavior you're describing is out of spec. You'll need to find a way to reliably distinguish a PMP device and then probably implement the workaround in custom hardreset or softreset method for the specific controller. Good luck. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
