Hello,
I am writing to report two issues I'm having with a hybrid graphics laptop.
Namely, Sony Vaio SA3S9R with Intel HD3000 and Radeon HD6630M
First one looks like a regression introduced by the commit named
"gpu/vga_switcheroo: add driver control power feature. (v3)". After I echo
I am writing to report two issues I'm having with a hybrid graphics laptop.
Namely, Sony Vaio SA3S9R with Intel HD3000 and Radeon HD6630M
First one looks like a regression introduced by the commit named
"gpu/vga_switcheroo: add driver control power feature. (v3)". After I echo
the "OFF" command to the switch, the DGPU turns off. However, after that
the vga_switcheroo disappears. Reinserting the radeon module makes
the kernel print the stack trace.
I have uploaded the dmesg log to http://paste.debian.net/38539/ .
--
Regards, Alexander
Another issue I would like to bring up is the handling of suspend-resume
cycle on muxless laptops. On most intel/radeon laptops, the DGPU turns
on after a resume without an ACPI notification (which sound like a bug).
Switcheroo is still thinking it's off, and it keeps draining
its extra 10W of power. Now, if we do a "echo OFF", switcheroo does nothing.
If we do "echo ON", it fails and gets stuck for some seconds (because it
tries to power-up a powered-up card messing the initialization routine and
then a GPU hang happens). The hacky solution is to turn it on before suspend
and turn it off after via a suspend hook script, but this has several limitations:
1. Most distros don't ship the script by default leaving the inexperienced users
with hot laptops
2. Doesn't work well when someone is really using the DGPU
3. I have no idea, but maybe turning it on makes it drain more power in suspend
(well, since BIOSes tend to be buggy, who knows what happens next).
My hacky solution was to forcibly turn off the DGPU in the switcheroo driver
at resume if it was unused, ignoring its state inside the switcheroo struct.
I have already made a proof-of-concept patch back in 2012, but somehow
that received no attention.
Since fixing ACPI for every broken laptop or shipping a suspend hook is a no-go,
we need some kind of a workaround. I don't really know how it should be done,
via DMI probing or whatever, but I would like someone who has more knowledge
to look into that. Well, I guess, a solution would be to forcibly enable my hack
for radeon/intel combos and then blacklist the laptops for which it breaks the resume
cycle via DMI (i.e., I think that since most laptops behave this way, we should
make the powersaving behavior default one).
--
Regards, Alexander
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
