[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re : Waking up the AHCI device
Re : Waking up the AHCI device
Mon, 08 Feb 2021 16:59:30 -0500
> ---- Le dim., 07 févr. 2021 13:02:58 -0500 Paul Dufresne
> <firstname.lastname@example.org> é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:
and seeing in the
at 3.1.1 that bit 18 "only in Linux" is really CAP.SAM in the AHCI
"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:
which I believe correspond to IDE as shown:
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 220.127.116.11 for more information... but 18.104.22.168 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.