Re: Cannot detect SATA disks w/ CONFIG_SATA_PMP w/o actually using SATA multiplier

[Tejun Heo <htejun@gmail.com>]

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