Re: [PATCH] apple-gmux: Restore switch registers on suspend/resume

From: Seth Forshee
Date: Tue Jul 31 2012 - 11:19:02 EST


On Sun, Jul 29, 2012 at 09:59:00PM +0100, Matthew Garrett wrote:
> On Sun, Jul 29, 2012 at 09:52:51PM +0100, David Woodhouse wrote:
> > On Sun, 2012-07-29 at 20:39 +0100, Matthew Garrett wrote:
> > > And it looks like intel_lvds->edid is only set during intel_lvds_init().
> > > That seems less than ideal. How about something like this entirely
> > > untested patch?
> >
> > Actually, it works if I write 'MIGD' first and then 'IGD'. Looks like we
> > aren't switching the DDC over to the new gfx card soon enough in the
> > process?
>
> Yes, the call to the switcheroo code only comes after the card is
> powered on. Cc:ing Dave Airlie - what are the expectations here? It
> looks like i915 should have a reprobe function.

I dove into this yesterday and ended up with something similar to what
you had. I'm rescanning for the EDID from the reprobe callback, and I
also made it so that intel_lvds_init() will still keep the LVDS
connector even if the panel isn't attached at boot and
intel_lvds_detect() returns connected/disconnected based on whether or
not we found an EDID for the LVDS.

All of this is working to the extent that I can boot with the Radeon
card active, switch over to the Intel card, and get the EDID for the
internal panel and an external monitor (although oddly on an HDMI
connector, no on the DP like I expected). Both screens are remaining
blank though. However I'm also getting blank screens if I mux over to
the Intel GPU from grub before loading the kernel, which used to work
for the LVDS panel at least.

I've copied the whole series of patches I'm running on top of 3.5 to
http://people.canonical.com/~sforshee/apple-gmux-patches if anyone else
wants to give them a try. The i915 changes are in patches 13-17. I've
also pushed the i915 patches to my gmux-switcheroo branch.

Seth

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/