[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120806201648.GD28213@thinkpad-t410>
Date: Mon, 6 Aug 2012 15:16:48 -0500
From: Seth Forshee <seth.forshee@...onical.com>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: dri-devel@...ts.freedesktop.org, David Airlie <airlied@...ux.ie>,
linux-kernel@...r.kernel.org, Andreas Heider <andreas@...tr.de>
Subject: Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we
can't get a panel mode
On Mon, Aug 06, 2012 at 01:23:17PM +0100, Matthew Garrett wrote:
> On Sun, Aug 05, 2012 at 11:40:16PM +0200, Daniel Vetter wrote:
>
> > As long as it's only apple shipping multi-gpu machines with
> > broken/non-existing vbt, I'll happily stomach the quirk list entries.
> > They're bad, but imo the lesser evil.
>
> Doing this via quirks means that we'll always be broken on the hardware
> at the point where it ships. Implementing the functionality means we
> stand some chance of working out of the box.
I've been thinking some today about how this functionality might be
implemented.
It looks like the simplest way to let the inactive GPU have the i2c bus
temporarily is to have drm_get_edid() control the mux and serialize it
with a mutex. It should be pretty easy to make vga_switcheroo support
muxing the DDC separately from the display.
There is the problem of vga_switcheroo not really being operational
until it has two clients and a handler, and the graphics drivers not
registering clients until they've initialized LVDS. This probably won't
be too dificult to solve.
The bigger problem is still making sure the switcheroo handler is
registered, when it's needed, before trying to read the EDID. We could
potentially delay initializing non-active graphics devices until after a
switcheroo handler has been registered, but that's a problem if the
handler is implemented by the driver for the secondary GPU (is this ever
the case?). Otherwise we seem to be stuck with making i915 able to cope
with getting modes for LVDS after initialization, which kind of puts us
back where we started.
Any other ideas?
--
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