Message-ID: <50159036.7010605@meetr.de>
Date:	Sun, 29 Jul 2012 21:34:14 +0200
From:	Andreas Heider <andreas@...tr.de>
To:	David Woodhouse <dwmw2@...radead.org>
CC:	Dave Airlie <airlied@...ux.ie>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Arun Raghavan <arun.raghavan@...labora.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] apple-gmux: Restore switch registers on suspend/resume

Am 29.07.12 21:05, schrieb David Woodhouse:
> On Sun, 2012-07-29 at 09:46 +0200, Andreas Heider wrote:
>> Am 29.07.12 03:18, schrieb David Woodhouse:
>>> On Sun, 2012-07-29 at 01:42 +0100, David Woodhouse wrote:
>>>> If I don't hack it to switch the mux to IGD at boot time, I never manage
>>>> to get a sane picture out of the Intel device after switching to it.
>>>> It's late now, but I'll try to get a proper debug log of the working and
>>>> failing cases tomorrow.
>>>
>>>   From the hacked kernel (after fixing vga_switcheroo_enable() not to do:
>>> 		event.info = client->fb_info;
>>>    		fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, &event);
>>> if client->fb_info is NULL)...
>>>
>>> http://david.woodhou.se/dmesg-boot-to-IGD (blank screen)
>>> http://david.woodhou.se/dmesg-boot-to-IGD-and-switch-to-DIS (works)
>>> http://david.woodhou.se/dmesg-boot-to-IGD-and-switch-to-DIS-and-back-to-IGD (works)
>>>
>>> Without switching to IGD at startup...
>>>
>>> http://david.woodhou.se/dmesg-boot-to-DIS (works)
>>> http://david.woodhou.se/dmesg-boot-to-DIS-then-switch-to-IGD (blank)
>>>
>>
>> The general problem, at least for the case of booting to DIS and then
>> switching to IGD, is that the mode for the internal display isn't
>> correct, so it stays black.
>>
>> It could get the right mode via DDC but this line is muxed as well.
>> 0x728 controls the DDC mux, writing 1 lets the IGD access it, 2 is the DIS.
>
> So? We *switch* it before telling the IGD to enable its display (hotplug
> the LVDS). So the DDC *should* be working, surely? Is it just that the
> Intel driver is probing the LVDS once at boot when the panel isn't even
> connected, and it should be made hotplug-capable?

That would work and I like this solution the best, but I'm not familiar 
enough with i915 to comment on how feasible it is or implement it. It 
should even be possible to switch the DDC mux first, let i915 do the 
detection and switch the display later to avoid long black screens.

>
> The Radeon seems to cope... maybe. I note it doesn't actually come up in
> 1920x1200 with fbcon, although ISTR X was getting the right resolution.
>
>> So what happens in dmesg-boot-to-DIS is that the intel card can't get
>> the mode via DDC and falls back to the garbage mode from VBT.
>> Interestingly, there is a intel VBT on your MBP8,3, but it doesn't
>> contain the right modes. On my MBP6,2 there isn't a VBT at all and it
>> disables LVDS altogether if 0x728 isn't switched at boot.
>>
>> Manually switching the mux is a bit messy, so I'm not too surprised that
>> it's blank in dmesg-boot-to-IGD.
>
> That does actually work, if I disable the Radeon completely. With this
> in early boot:
> +       outb(1, 0x728);
> +       outb(2, 0x710);
> +       outb(2, 0x740);
> +       outb(0, 0x750);
> ... the Intel framebuffer then comes up just fine on the internal
> display. It *can't* drive external displays in that case (via the
> standard Apple DP-VGA or DP-DVI adapters; I haven't tried real DP), but
> the LVDS is fine.
>

Not sure about it, but it might be because vga_default_device is wrong 
if you switch the mux manually.

>> The gmux code you're using is a bit outdated, but if you use
>> git://kernel.ubuntu.com/sforshee/linux.git gmux-switcheroo and connect
>> an external display (I tested it with a DP one) you should be able to
>> boot to DIS and switch to the IGD and get output on the external display.
>>
>> This leaves the problem of how to get i915 the right mode. Generally,
>> there are two options:
>>
>> - Find a way so it gets the right mode when it initializes the LVDS.
>> This could be done by switching the DDC mux during lvds intialization.
>> See lock_ddc.patch for a crude prototype that works on my laptop if I'm
>> lucky and apple_gmux gets loaded before i915 and nouveau doesn't try to
>> use DDC at the same time.
>
> Again, why is the LVDS initialisation happening when the LVDS isn't
> connected anyway? Fix that, and your concerns become irrelevant. You
> *can't* switch to IGD before apple_gmux is loaded, and the discrete card
> shouldn't be poking it DDC when the panel has been hot-unplugged from it
> either.
>
>> Another way would be to get the right EDID without mux switching by
>> querying either the DIS driver or EFI (if you boot into the rEFIt shell
>> you can verify it's there, see http://andreas.meetr.de/efi/log/edid.txt,
>> to get it search for EdidDiscovered/EdidActive and dump it with dmem).
>> But to use this, we need a way to know which display this corresponds to
>> and I'm not sure how to do that.
>>
>> - Make vga_switcheroo reprobe handle this. This would mean that we start
>> with a possibly broken mode and resize it once the mux get's switched
>> through vga_switcheroo. I'm not sure if thats a good idea.
>
> "Possibly broken mode", in the case where there is no monitor attached
> to the display. I think we can live with that. Surely it's the case for
> an external monitor (which we also support) anyway?
>
> In fact speaking of external monitors... it looks like it should be
> possible to support using one graphics cards for the LVDS, and another
> for the external DisplayPort. Perhaps they could be different seats of a
> multi-seat system, with completely separate X servers, or maybe we'd do
> it just to work around size/bandwidth limitations or for performance
> reasons. Do we have any plan to allow that? We only switch both together
> for now...
>

Just as a sidenote, I tested running two X server and it does work as 
expected.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists