On Mon, 7 Feb 2011 12:26:52 -0800, Jesse Barnes
wrote:
> We had some conversions over to the _PIPE macros, but didn't get
> everything. So hide the per-pipe regs with an _ (still used in a few
> places for legacy) and add a few _PIPE based macros, then make sure
> everyone uses them.
In the en
This is a horrible layering violation; we should be doing this in the
connector/encoder ->prepare instead, but we don't always have enough
information there about the config to know whether it will actually be
necessary or just cause unnecessary flicker.
--
Jesse Barnes, Intel Open Source Technol
Save/restore of state like this won't work on recent chips anyway, and
we'll clobber all this when mode setting, so don't bother with it.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_suspend.c | 464 ---
1 files changed, 0 insertions(+), 464 deletion
Save/restore of state like this won't work on recent chips anyway, and
we'll clobber all this when mode setting, so don't bother with it.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_suspend.c | 464 ---
1 files changed, 0 insertions(+), 464 deletion
Chris, those interest:
Here is a remote set up for review. The commits will definitely need to
be rebased later.
http://cgit.freedesktop.org/~bwidawsk/i915-context-support/
git://anongit.freedesktop.org/~bwidawsk/i915-context-support
This weekend I addressed some of the locking issues, although
On Fri, 4 Feb 2011 13:57:30 -0800, Jesse Barnes
wrote:
> The PCH can drive several reference clocks simultaneously, and needs to
> with multiple display configurations. So we can't just clobber the
> existing state everytime we set a mode, we need to take into account
> what the other CRTCs are
On Wed, 2 Feb 2011 12:28:02 -0800, Jesse Barnes
wrote:
> These bits have a different meaning on ILK+, where planes are hardwired
> to pipes. Fixing this avoid some spurious assertion failures.
Both applied to -next.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, 2 Feb 2011 12:08:07 -0800, Eric Anholt wrote:
> The specs say to do so.
Thanks Eric, applied to -next where we can give it some testing before it
hits Linus.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing li
Hello, Chris and list,
I continue working under my problem with two LVDS monitors connected
to SDVO-B and SDVO-C. I finally managed to make one monitor work again
using generic kernel version 2.6.36 and xf86-video-intel drivers
version 2.12.0. Unfortunately, either with the latest unstable
version
