On Thu, Oct 7, 2010 at 1:09 AM, Chris Wilson wrote:
> To fix the first:
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi
> and we hope to have a complete patch shortly. (Zhenyu did you get a chance
> to update the patches?)
Cool. I'll rebuild the kernel tomorr
Hi, Alexander:
I think you are right that GEN3 hardware CXSR requires enabling low
power render writes.
This patch is OK for me, but DRM_DEBUG_KMS is better than printk.
Acked-by : Li Peng
On Mon, 2010-10-04 at 19:31 -0400, Alexander Lam wrote:
> Using 2.6.35.7 (this patch is against drm-int
On Fri, 8 Oct 2010 14:19:47 +0800, Yuanhan Liu wrote:
> Make sure hotplug is enabled, or the hotplug interrupt will not be
> invoked. And, for sandybridge, the bit definition for hotplug on
> SDE is changed. So, update the code to new definition.
I split this into the two patches for the two sep
On Thu, 7 Oct 2010 17:05:46 -0700, Bryan Freed wrote:
> The time between start of the pixel clock and backlight enable is a basic
> panel timing constraint. If the Panel Power On/Off registers are found
> to be 0, assume we are booting without VBIOS initialization and set these
> registers to som
On 10/07/2010 07:01 PM, Jesse Barnes wrote:
Here's the set of PCH eDP fixes I came up with once I received my Sony
Vaio. I found a few, non-PCH issues in the process, and took the
opportunity to enhance our eDP support to avoid most of the DP training
if the VBIOS gives us good data.
This patch
On Thu, 7 Oct 2010 16:01:05 -0700, Jesse Barnes
wrote:
> Here's the set of PCH eDP fixes I came up with once I received my Sony
> Vaio. I found a few, non-PCH issues in the process, and took the
> opportunity to enhance our eDP support to avoid most of the DP training
> if the VBIOS gives us go
On Fri, 08 Oct 2010 16:05:34 +0800, Li Peng wrote:
> Hi, Alexander:
>
> I think you are right that GEN3 hardware CXSR requires enabling low
> power render writes.
>
> This patch is OK for me, but DRM_DEBUG_KMS is better than printk.
Alexander, if you don't mind respinning your patch to fixup t
On Fri, 8 Oct 2010 10:26:04 +1000, Dave Airlie wrote:
> On my 965 on unload of driver.
Confirmed with my 965GM and -next.
Thanks Dave,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
On Fri, 08 Oct 2010 11:48:06 +0100, Chris Wilson
wrote:
> On Fri, 8 Oct 2010 10:26:04 +1000, Dave Airlie wrote:
> > On my 965 on unload of driver.
>
> Confirmed with my 965GM and -next.
I take that back, fedora had swapped their kernel for mine!
This is the leak Keith fixed for -next.
-Chris
The i915 driver has quite a few module unload bugs, the known ones at
least have fixes that are targeting 2.6.37. However, in order to
maintain a stable kernel, we should prevent this known random memory
corruption following driver unload. This should have very low impact on
normal users who are un
Hi Linus, early in this cycle Daniel Vetter supplied a number of fixes
for memory corruption bugs following module unload of i915.ko. We
postponed these to the next cycle. However, as Thomas Gleixner pointed
out, we should have not left the known memory corruption bugs lie in the
kernel and should
From: Stefan Dirsch
Signed-off-by: Matthias Hopf
---
src/common.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/common.h b/src/common.h
index 6f23cdd..800e17f 100644
--- a/src/common.h
+++ b/src/common.h
@@ -172,6 +172,11 @@ static inline void memcpy_volatile(
On Fri, 08 Oct 2010 11:00:11 +0100
Chris Wilson wrote:
> On Thu, 7 Oct 2010 16:01:05 -0700, Jesse Barnes
> wrote:
> > Here's the set of PCH eDP fixes I came up with once I received my Sony
> > Vaio. I found a few, non-PCH issues in the process, and took the
> > opportunity to enhance our eDP
Since the PLL may still be on, and the training pattern may not be
correct. Fixes suspend/resume on my PCH eDP test system.
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8e019c8..2449192 100644
--- a/drivers/gpu/drm/i915/int
I took a look at several panel datasheets I found around here, and the one
issue some of them mentioned is that these timings (particularly T2 on
powerup and T3 on powerdown) are used to prevent latch-up.
That makes sense. We do not want to drive pixels to a device that has 0V on
VDD. This chang
On 10/08/2010 02:35 PM, Bryan Freed wrote:
I took a look at several panel datasheets I found around here, and the one
issue some of them mentioned is that these timings (particularly T2 on
powerup and T3 on powerdown) are used to prevent latch-up.
That makes sense. We do not want to drive pixel
On Fri, 08 Oct 2010 10:58:40 +0100, Chris Wilson
wrote:
> Does any one have a strong "this will damage my hardware" objection? Are
> the values safe enough for *any* device?
Or perhaps a better question is: does anyone else feel confident enough
in these defaults to ack them? ;-) Reviewed-by and
On Fri, 08 Oct 2010 21:28:01 +0100
Chris Wilson wrote:
> On Fri, 08 Oct 2010 10:58:40 +0100, Chris Wilson
> wrote:
> > Does any one have a strong "this will damage my hardware" objection? Are
> > the values safe enough for *any* device?
>
> Or perhaps a better question is: does anyone else fee
All,
I'm trying to find an option (xrandr or boot time, either way) to
disable the load detection on the intel 965M and force external VGA
output. It sounds like ATI has an xrandr option for this (--set
load_detection 1) and am hoping for a matching ability. Does anyone
know of such an option? I
I will accept a redirect to another list if this is the wrong one.
When I run a loop of "xset dpms force off; sleep 1; xset dpms force on;
sleep 1" to repeatedly turn on and off the panel (connected through i915
LVDS), it does not come back on after a while. The backlight comes on, but
the frameb
On Thu, Oct 7, 2010 at 1:09 AM, Chris Wilson wrote:
> Seems like you've been bitten by two separate bugs. The first is that we
> always enable audio over HDMI even through a dongle and to a device that
> is not audio capable. That has the effect of making the output green/pink
> or even preventing
21 matches
Mail list logo
