Intel/Radeon muxless laptop issues

Alexander Tarasikov alexander.tarasikov at
Wed Sep 11 14:07:30 PDT 2013

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 .

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
1. Most distros don't ship the script by default leaving the inexperienced
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
(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
we need some kind of a workaround. I don't really know how it should be
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
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
make the powersaving behavior default one).

Regards, Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the dri-devel mailing list