Re : Waking up the AHCI device

[Paul Dufresne]

 > ---- Le dim., 07 févr. 2021 13:02:58 -0500 Paul Dufresne 
 > <dufresnep@zoho.com> écrit ---- 
 >  
 >  > I suspect CAP.SAM was 0 in previous versions... did not check. 
 >  > But that most computers now have CAP.SAM to 1, so that GHC.AE should be 
 > written, even if already to 1, to "wake up" the device. 
 >  > I suspect current implementation of AHCI in Mach does not it. 
 >  > 
 > I guess I was confused there. 
 > CAP.SAM means Supports AHCI mode only. 
 > So if CAP.SAM=1, GHC.AhciEnable is read-only, and always to 1. 
 > If CAP.SAM is 0, GHC.AhciEnable is writable, and 0 'by default'. Meaning no 
 > commands should be sent to AHCI before putting it to 1. 
 >  
 > BTW my main computer have no option to disable AHCI in firmware... but does 
 > show the phy device offline error. 
 > But don't know if CAP.SAM is really 1. 
 >  
 I did not write any new code yet.
Still reading the doc... the more I read it the more it make sense.

I have confirmed that my system have an HBA (HBA is an acronym for “host bus 
adapter”.  A host bus adapter refers to the silicon that implements the AHCI 
specification to communicate between system memory and Serial ATA devices.) 
which have CAP.SAM to 1:
(On Linux) paul@jacko:~/hurd8fev$ sudo dmesg| grep ahci
[    0.618248] ahci 0000:00:17.0: version 3.0
[    0.629098] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 4 ports 6 Gbps 0xf 
impl SATA mode
[    0.629099] ahci 0000:00:17.0: flags: 64bit ncq sntf led clo only pio slum 
part ems deso sadm sds apst 
the only flag is CAP.SAM... as can be seen from at the end of this patch:
https://patchwork.ozlabs.org/project/linux-ide/patch/4AB6B487.3010907@gmail.com/

and seeing in the 
file:///home/paul/T%C3%A9l%C3%A9chargements/serial-ata-ahci-spec-rev1-3-1.pdf
at 3.1.1 that bit 18 "only in Linux" is really CAP.SAM in the AHCI 
documentation:
"A  value  of  '0'  indicates  that  in  addition  to  the  native  AHCI 
mechanism  (via  ABAR),  the  SATA  controller  implements  a  legacy,  
task-file  based register interface such as SFF-8038i"
So my HBA does not support SFF-8038i: 
http://www.freedoors.org/idework/specs/8038-r01.pdf (1994)
which I believe correspond to IDE as shown: 
https://wiki.osdev.org/PCI_IDE_Controller

So... it shows that the problem is not just that we need to set CAP.AE before 
using other registers than the Generic Host Control (section 3.1),
because on my HBA, it is always on (and read-only).

So I guess this is more related to the need of:
Setting PxCMD.ICC (Px means the register of the Port x, Interface  
Communication  Control  (ICC):This  field isused  to  control  power management 
statesof the interface. to 1 meaning Active (rather than some sleeping).
See 3.3.7 for the register details.
And 8.3.1.2 for more information... but 8.3.1.1 seems to suggest that "By  
default,  a  device  that  supports  initiating  interface  power  management  
states  has  the  capability disabled" ... so maybe this is not necessary.
Did not really check if Mach AHCI driver cares about that.
And if it scan through GHC.PI (Ports Implemented by the BIOS), to only use the 
one permitted by the BIOS.

Somehow, I begin to prefer to use specificaton terms, like CAP.SAM... that 
often have other name in the AHCI driver of Mach (in the Linux part of it).
But maybe, as it is in the Linux part, I should kept the term they use.