Closed ctr0 closed 13 years ago
Lekensteyn
commented
13 years ago We (me and ArchangeGabriel) have been reading the ACPI spec too and are trying find the definitive working methods.
So far, we found out that _ON and _OFF should never be called as that method should be called after other methods (_Dn methods). We're in #bumblebee-dev on freenode for talk.
ArchangeGabriel
commented
13 years ago I've been testing bumblebee configs in my laptop for a few days and i've found some interesting things:
- The system boots with the card ON
- The ACPI call to turn the card ON is: _SB.PCI0.P0P2.PEGP._ON
- The ACPI call to turn the card OFF is: _SB.PCI0.P0P2.PEGP._OFF
The are some calls from the ACPI Spec4 supported by the card:
_SB.PCI0.P0P2.PEGP._PS3 _SB.PCI0.P0P2.PEGP._PS1 _SB.PCI0.P0P2.PEGP._PS0
To set the power state to D3, D1 and D0 respectively. Setting this state has no apparent effect, but the state persist and >can be queried by the command _SB.PCI0.P0P2.PEGP._PSC
I've found two more calls working: _SB.PCI0.P0P2.PEGP._STA that returns always 1 no matter the card is on or off, >and _SB.PCI0.P0P2.PEGP._SDM an unknown "Specific Device Method" that apparently takes no params and always >return 0x80000001 (or something like this).
- Two consecutive calls to the OFF command makes the nvidia driver unusable until reboot (No such device).
- Suspending while the card is turned OFF also results in the No such device error the next time bumblebee tries to >load the nVidia driver. No problem if the card is turned ON.
ON and OFF sould never be called as standalone. They are called by PS0 and PS3.
Most of time, PS1 does nothing.
PS0 and PS3 may do nothing if SDM (or DSM) is not called before with the good parameters.
PSC is in fact a var that stores the state.
Disabling twice the card is in fact dangerous, that's why SDM must also be called before, as it prevent from disabling the card twice (look at the U43Jc disable script).
As the system shutdown the card at shutdown time (amazing !), it has the same result.
ctr0
commented
13 years ago Good to know.
So _DSM must be called, what about its params? UUID, Revision ID, Function Index and Arguments, how to find it? Any advice?
Lekensteyn
commented
13 years ago @ctr0
mkdir ~/acpiinfo ; cd ~/acpiinfo
sudo acpidump > acpidump.txt
# enter password
sudo acpixtract acpidump.txt
ls *.dat | while read i; do iasl -d "${i}"; doneThe .dsl files contains everything you need. DSDT.dsl is the main table, SSDT.dsl are additional tables. Look in the header, my SSDT1.dsl file contains nvidia-related stuff in addition to DSDT.dsl
ArchangeGabriel
commented
13 years ago I think that they originally should be created by an other function which use one (or more) specific buffer(s) for that. For Asus computer, it looks to be a function called WMMX. On other brand, I've found a function called NVOP that may do this.
Those you can found in the actual scripts comes from reverting the DSM function.
We found them by looking in the DSDT and SSDT tables.
But for now, they aren't enough stable to be used as it. We must to find out what I'm speaking about in the first paragraph.
In the future, I would like to write a tool that grab this automatically, but for now, this is the only way we found.
EDIT : Lekensteyn, when you want to use a * in your text, you must put a \ before for Markdown to ignore it. Dit that for you ;)
ctr0
commented
13 years ago The DSM params for qt310 are the same as for U43Jc (same card, maybe was obvious).
I've tried these ones, but the error on resume still there. I have a function called WMMX too, that calls DSM on another device that calls DSM on nvidia card.
ArchangeGabriel
commented
13 years ago For the WMMX function, that's a good new, mine do the same.
You will still have such errors as long as we won't have implemented acpi_call correctly.
I've been testing bumblebee configs in my laptop for a few days and i've found some interesting things:
The are some calls from the ACPI Spec4 supported by the card:
_SB.PCI0.P0P2.PEGP._PS3 _SB.PCI0.P0P2.PEGP._PS1 _SB.PCI0.P0P2.PEGP._PS0
To set the power state to D3, D1 and D0 respectively. Setting this state has no apparent effect, but the state persist and can be queried by the command _SB.PCI0.P0P2.PEGP._PSC
I've found two more calls working: _SB.PCI0.P0P2.PEGP._STA that returns always 1 no matter the card is on or off, and _SB.PCI0.P0P2.PEGP._SDM an unknown "Specific Device Method" that apparently takes no params and always return 0x80000001 (or something like this).
I'm testing a lot of things here, i think a more accurate tuning of pm-utils is needed. Other system devices are disabled after the mem sleep and bumblebee script disablecard-on-powerup turns the card OFF after. It is curious see what happens in the pci buss while resuming whth the card ON and with the card OFF:
Card ON:
Card OFF:
Note the 0xffffffff value that is always restored... Just curious and maybe relevant. I keep working.