Re: [Intel-gfx] [libva] GPU hung

Am Mittwoch, den 13.06.2012, 00:09 +0200 schrieb Angela: > >> >For gpu hangs the important thing is the i915_error_state file from > >> >sysfs > >> (the files you've attached are mainly interesting for modeset issues). > >> I guess the best thing would be to file a bug on bugs.freedesktop.org >

Re: [Intel-gfx] [libva] GPU hung

>> >For gpu hangs the important thing is the i915_error_state file from >> >sysfs >> (the files you've attached are mainly interesting for modeset issues). >> I guess the best thing would be to file a bug on bugs.freedesktop.org >> with that. >> >> # cat /sys/kernel/debug/dri/0/i915_error_state

[Intel-gfx] [PATCH 6/7] drm/i915: bind driver to ValleyView chipsets

With the code in place, we can bind the driver, should make bisect possible. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 747dc8d..8bdb000 100644 -

[Intel-gfx] [PATCH 5/7] drm/i915: access VLV regs through read/write switch

Since the offsets have all moved around. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.c | 80 ++- 1 file changed, 78 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 238a521.

[Intel-gfx] [PATCH 7/7] drm/i915: VLV VGA port only handles on & off, like PCH VGA

Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_crt.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 1333a65..ac62f24 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.

[Intel-gfx] [PATCH 4/7] drm/i915: add HDMI and DP port enumeration on ValleyView

ValleyView is similar to IbexPeak here, but with different register offsets. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_display.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH 3/7] drm/i915: add ValleyView specific CRT detect function

Might be able to merge this back in at some point, but we're seeing bugs with ADPA based detection, so keep it separate for now with explicit hotplug trigger usage. v2: drop superfluous debug message v3: comment forced detection, need to debug (Eugeni) Reviewed-by: Eugeni Dodonov Signed-off-by:

[Intel-gfx] [PATCH 2/7] drm/i915: Enable DP panel power sequencing for ValleyView

From: Shobhit Kumar VLV supports two dp panels, there are two set of panel power sequence registers which needed to be programmed based on the configured pipe. This patch add supports for the same Acked-by: Acked-by: Ben Widawsky Signed-off-by: Beeresh G Reviewed-by: Vijay Purushothaman Revie

[Intel-gfx] [PATCH 1/7] drm/i915: ValleyView mode setting limits and PLL functions

Add some VLV limit structures and update the PLL code. v2: resolve conflicts, Vijay to re-post with PLL valid checks and fixed limits v3: re-add dpio write function Signed-off-by: Shobhit Kumar Signed-off-by: Vijay Purushothaman --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/dr

[Intel-gfx] Remaining VLV patches

I've long since forgotten any comments or requests, so these patches may be missing some changes people wanted. However, they've been updated to the latest drm-intel-next branch and work on my system here, so of no one has objections, it would be nice if they could be integrated. Thanks, Jesse _

Re: [Intel-gfx] [libva] GPU hung

On Tue, Jun 12, 2012 at 10:26:19PM +0200, Angela wrote: > >For gpu hangs the important thing is the i915_error_state file from sysfs > (the files you've attached are mainly interesting for modeset issues). I > guess the best thing would be to file a bug on bugs.freedesktop.org with > that. > > Hel

Re: [Intel-gfx] [PATCH] drm/i915: Switch off FBC when disabling the primary plane when obscured

On Tue, 12 Jun 2012 07:28:04 -0700, Jesse Barnes wrote: > Though now we have 3 "active" state variables for the crtc don't we? > active, enabled, and now primary_disabled? Oh and dpms state. I > really wish we could get rid of 2 or 3 of those... That crossed my mind as well. This felt like it

Re: [Intel-gfx] [PATCH] Avoid calling xf86nameCompare() with a NULL pointer.

Chris Wilson (12/06/2012): > Pushed with only a slightly different colour of paint. Thanks, > -Chris Cake? Yummy! Mraw, KiBi. signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedes

Re: [Intel-gfx] [libva] GPU hung

>For gpu hangs the important thing is the i915_error_state file from sysfs (the files you've attached are mainly interesting for modeset issues). I guess the best thing would be to file a bug on bugs.freedesktop.org with that. Hello Daniel I get the following: # cat /sys/kernel/debug/dri/0/i915_

Re: [Intel-gfx] [PATCH 00/12] clear up drm/agp initialization madness

On Tue, Jun 12, 2012 at 03:46:35PM +0300, Jani Nikula wrote: > On Thu, 07 Jun 2012, Daniel Vetter wrote: > > Comments, flames and reviews highly welcome. If possible I'd like to get > > the 3 > > drm patches at the beginning in early for 3.6 so that we can decently test > > it > > (and have some

Re: [Intel-gfx] [PATCH] Avoid calling xf86nameCompare() with a NULL pointer.

On Tue, 12 Jun 2012 20:15:19 +0200, Cyril Brulebois wrote: > Device sections without a Driver property would lead to a server > segfault because of a NULL pointer's being passed as the second > argument of xf86nameCompare(). > > Debian bug #677206 > > Signed-off-b

Re: [Intel-gfx] [libva] GPU hung

For gpu hangs the important thing is the i915_error_state file from sysfs (the files you've attached are mainly interesting for modeset issues). I guess the best thing would be to file a bug on bugs.freedesktop.org with that. -Daniel On Tue, Jun 12, 2012 at 9:13 PM, Angela wrote: > Hello > Playin

[Intel-gfx] [PATCH] i965: Add hardware context support.

With fixes and updates from Ben Widawsky and comments from Paul Berry. This should not be pushed until libdrm 2.4.36 is released with Ben's hardware context support. I haven't hooked up the context destroy function yet as I'm not entirely sure about tear-down, but they will be freed on fd close,

[Intel-gfx] [PATCH] Avoid calling xf86nameCompare() with a NULL pointer.

Device sections without a Driver property would lead to a server segfault because of a NULL pointer's being passed as the second argument of xf86nameCompare(). Debian bug #677206 Signed-off-by: Cyril Brulebois --- src/intel_module.c |2 +- 1 file changed, 1 i

Re: [Intel-gfx] [PATCH 4/4] drm/i915: allow pipe A for lvds on gen4

On Tue, Jun 12, 2012 at 12:35:17PM -0300, Eugeni Dodonov wrote: > On 06/05/2012 05:07 AM, Daniel Vetter wrote: > > Given the havoc the missing backlight pipe select code might have > > caused, let's try to re-enabled pipe A support for lvds on gen4 hw. > > Just to see what all blows up ... > > > >

Re: [Intel-gfx] [PATCH] drm/i915: ensure HDMI port is disabled inside set_infoframes

On Tue, Jun 12, 2012 at 12:43:42PM -0300, Eugeni Dodonov wrote: > On 06/12/2012 11:36 AM, Daniel Vetter wrote: > > This function is supposed to be used at mode set time, so prevent > > against future mistakes by adding a WARN(). > > > > Based on a patch by Paulo Zanoni, with the check extracted in

Re: [Intel-gfx] [PATCH] drm/i915: ensure HDMI port is disabled inside set_infoframes

On 06/12/2012 11:35 AM, Paulo Zanoni wrote: > My crystal ball tells me a check for IS_HASWELL_OR_NEWER would prevent > more changes to this code in the future. I think that a .has_ddi (or similar) flag would be better than checking for post-Haswell variants, as not necessarily all of them could wo

Re: [Intel-gfx] Register "linking"

On Tue, 12 Jun 2012 12:35:37 +0200, Olivier Galibert wrote: > Hi guys, > > I'm playing with my gm45, and trying to understand the inter-shader > register allocation and referencing aspects. From what I see, the vs > and clipper follow the brw_vue_map to know where data is. The > fragment shad

Re: [Intel-gfx] [PATCH] drm/i915: ensure HDMI port is disabled inside set_infoframes

On 06/12/2012 11:36 AM, Daniel Vetter wrote: > This function is supposed to be used at mode set time, so prevent > against future mistakes by adding a WARN(). > > Based on a patch by Paulo Zanoni, with the check extracted into a > little assert_hdmi_port_disabled helper added to make things self >

Re: [Intel-gfx] 1080i content on 1080i shakes

> > > I have the interlaced patch running (kernel 3.3, not updated since > > > February) and is working perfect for up to 720p TV content. > > > However with 1080i TV content the picture shakes almost > > > continuously. The shaking is also viewable when the recording is > > > paused. Only some

Re: [Intel-gfx] [PATCH 4/4] drm/i915: allow pipe A for lvds on gen4

On 06/05/2012 05:07 AM, Daniel Vetter wrote: > Given the havoc the missing backlight pipe select code might have > caused, let's try to re-enabled pipe A support for lvds on gen4 hw. > Just to see what all blows up ... > > Note though that > > commit 4add75c43f39573edc884d46b7c2b7414f01171a > Aut

Re: [Intel-gfx] [PATCH] drm/i915: properly enable the blc controller on the right pipe

On 06/05/2012 07:14 AM, Daniel Vetter wrote: > + /* Note that this can also get called through dpms changes. And > + * we don't track the backlight dpms state, hence check whether > + * we have to do anything first. */ > + if (tmp & BLM_PWM_ENABLE)

Re: [Intel-gfx] [PATCH 2/4] drm/i915: clear up backlight #define confusion on gen4+

On 06/05/2012 05:07 AM, Daniel Vetter wrote: > - Regroup definitions for BLC_PWM_CTL so that they're all together and > and ordered according to the bitfields. > > - Add all missing defintions for BLC_PWM_CTL2. s/defintions/definitions > > - Use the BLM_ (for backlight modulation) prefix cons

Re: [Intel-gfx] [PATCH 1/4] drm/i915: pnv has a backlight polarity control bit, too

On 06/05/2012 05:07 AM, Daniel Vetter wrote: > We already correctly ignore bit0 on gen < 4, now we also now why ;-) s/now/know > I've decided that losing that single bit of precision isn't worth the > trouble to sprinkle IS_PINEVIEW checks all over the backlight control > code - that code is way

Re: [Intel-gfx] [PATCH] drm/i915: ensure HDMI port is disabled inside set_infoframes

Hi 2012/6/12 Daniel Vetter : > This function is supposed to be used at mode set time, so prevent > against future mistakes by adding a WARN(). > > Based on a patch by Paulo Zanoni, with the check extracted into a > little assert_hdmi_port_disabled helper added to make things self > documenting and

Re: [Intel-gfx] [PATCH] drm/i915: Switch off FBC when disabling the primary plane when obscured

On Tue, 12 Jun 2012 12:46:00 +0100 Chris Wilson wrote: > As we switch on/off the primary plane if it is completely obscured by an > overlapping video sprite, we also nee to make sure that we update the > FBC configuration at the same time. > > References: https://bugs.freedesktop.org/show_bug.cg

[Intel-gfx] [PATCH] drm/i915: ensure HDMI port is disabled inside set_infoframes

This function is supposed to be used at mode set time, so prevent against future mistakes by adding a WARN(). Based on a patch by Paulo Zanoni, with the check extracted into a little assert_hdmi_port_disabled helper added to make things self documenting and move the assert stuff out of line. Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Switch off FBC when disabling the primary plane when obscured

On Tue, 12 Jun 2012, Chris Wilson wrote: > As we switch on/off the primary plane if it is completely obscured by an > overlapping video sprite, we also nee to make sure that we update the > FBC configuration at the same time. I had a patch to this effect which I didn't get around to sending yet.

Re: [Intel-gfx] [PATCH] drm: fixup error path after drm_fill_in_dev

On Tue, 12 Jun 2012, Daniel Vetter wrote: > Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in > case of failures. But the callers of drm_fill_in_dev simply don't do > anything. Now from a cursory look drm_lastclose doesn't look like the > best cleanup function in itself, but who

Re: [Intel-gfx] [PATCH 00/12] clear up drm/agp initialization madness

On Thu, 07 Jun 2012, Daniel Vetter wrote: > Comments, flames and reviews highly welcome. If possible I'd like to get the 3 > drm patches at the beginning in early for 3.6 so that we can decently test it > (and have some time to pile more stuff on top of this in drm/i915 land). On the series and t

[Intel-gfx] [PATCH] drm: fixup error path after drm_fill_in_dev

Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in case of failures. But the callers of drm_fill_in_dev simply don't do anything. Now from a cursory look drm_lastclose doesn't look like the best cleanup function in itself, but whom am I to judge the drm error paths. Imo before we

Re: [Intel-gfx] [PATCH 2/2] drm: fixup error path after drm_fill_in_dev

On Fri, 08 Jun 2012, Daniel Vetter wrote: > Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in > case of failures. But the callers of drm_fill_in_dev simply don't do > anything. Now from a cursory look drm_lastclose doesn't look like the > best cleanup function in itself, but who

[Intel-gfx] [PATCH] drm/i915: don't check intel_agp_enabled any more

We won't enabled agp unconditionally. Furthermore we do have the right checks for agp support in place in our ->load function. The only thing this variable still does is enforce the module load order we want (and I'm not even sure whether it succeeds for that). Hence just use it in a harmless plac

[Intel-gfx] [PATCH] drm/i915: only enable drm agp support when required

We need it for all things ums (which essentially only means up to gen5) and to support b0rked XvMC userspace on gen3. v2: Fixup error paths as noticed by Jani Nikula. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_dma.c | 22 +- 1 files changed, 13 insertions(+

Re: [Intel-gfx] [PATCH 07/12] drm/i915: only enable drm agp support when required

On Tue, Jun 12, 2012 at 02:58:25PM +0300, Jani Nikula wrote: > On Thu, 07 Jun 2012, Daniel Vetter wrote: > > We need it for all things ums (which essentially only means up to > > gen5) and to support b0rked XvMC userspace on gen3. > > > > Signed-Off-by: Daniel Vetter > > --- > > drivers/gpu/drm/

Re: [Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

On Tue, Jun 12, 2012 at 12:58:20PM +0100, Chris Wilson wrote: > On Tue, 12 Jun 2012 11:43:50 +, "Singh, Satyeshwar" > wrote: > > Hi, > > I just want to confirm something here. We have a situation where we draw a > > splash screen through our firmware's graphics component (UEFI GOP driver) >

Re: [Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

On Tue, 12 Jun 2012 11:43:50 +, "Singh, Satyeshwar" wrote: > Hi, > I just want to confirm something here. We have a situation where we draw a > splash screen through our firmware's graphics component (UEFI GOP driver) > onto its frame buffer which resides in stolen memory. When we transitio

Re: [Intel-gfx] [PATCH 07/12] drm/i915: only enable drm agp support when required

On Thu, 07 Jun 2012, Daniel Vetter wrote: > We need it for all things ums (which essentially only means up to > gen5) and to support b0rked XvMC userspace on gen3. > > Signed-Off-by: Daniel Vetter > --- > drivers/gpu/drm/i915/i915_dma.c | 21 - > 1 files changed, 12 inserti

[Intel-gfx] [PATCH] drm/i915: Switch off FBC when disabling the primary plane when obscured

As we switch on/off the primary plane if it is completely obscured by an overlapping video sprite, we also nee to make sure that we update the FBC configuration at the same time. References: https://bugs.freedesktop.org/show_bug.cgi?id=50238 Signed-off-by: Chris Wilson Cc: Jesse Barnes --- driv

Re: [Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

Hi, I just want to confirm something here. We have a situation where we draw a splash screen through our firmware's graphics component (UEFI GOP driver) onto its frame buffer which resides in stolen memory. When we transition from firmware to the kernel, we would like to ensure that the same spl

[Intel-gfx] [PATCH] drm/i915: eDP aux needs vdd

The new oui probe has been missing these. This issue has been introduce in commit 0d198328538276c4459ef5de081e68ae60e6c4c2 Author: Adam Jackson Date: Mon May 14 16:05:47 2012 -0400 drm/i915/dp: Probe branch/sink OUIs v2: Do the eDP vdd dance of simply not probing the OUI on eDP panels as

Re: [Intel-gfx] [PATCH] drm/i915: eDP aux needs vdd

On Tue, 12 Jun 2012 13:11:41 +0200, Daniel Vetter wrote: > The new oui probe has been missing these. > > This issue has been introduce in > > commit 0d198328538276c4459ef5de081e68ae60e6c4c2 > Author: Adam Jackson > Date: Mon May 14 16:05:47 2012 -0400 > > drm/i915/dp: Probe branch/sink

[Intel-gfx] [PATCH] drm/i915: eDP aux needs vdd

The new oui probe has been missing these. This issue has been introduce in commit 0d198328538276c4459ef5de081e68ae60e6c4c2 Author: Adam Jackson Date: Mon May 14 16:05:47 2012 -0400 drm/i915/dp: Probe branch/sink OUIs v2: Do the eDP vdd dance of simply not probing the OUI on eDP panels as

[Intel-gfx] Register "linking"

Hi guys, I'm playing with my gm45, and trying to understand the inter-shader register allocation and referencing aspects. From what I see, the vs and clipper follow the brw_vue_map to know where data is. The fragment shader, though, does its own input register allocation in the urb_setup array

Re: [Intel-gfx] [PATCH] drm/i915: don't probe oui for eDP panels

On Tue, 12 Jun 2012 12:02:47 +0200, Daniel Vetter wrote: > At least not in the detect function. We'd need eDP vdd to do so if the > panel is off, but I've figured just disabling it is easier. > > This issue has been introduce in > > commit 0d198328538276c4459ef5de081e68ae60e6c4c2 > Author: Adam

[Intel-gfx] [PATCH] drm/i915: don't probe oui for eDP panels

At least not in the detect function. We'd need eDP vdd to do so if the panel is off, but I've figured just disabling it is easier. This issue has been introduce in commit 0d198328538276c4459ef5de081e68ae60e6c4c2 Author: Adam Jackson Date: Mon May 14 16:05:47 2012 -0400 drm/i915/dp: Probe

[Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do w

Re: [Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

On Mon, 11 Jun 2012 18:28:12 +0200, Daniel Vetter wrote: > Especially vesafb likes to map everything as uc- (yikes), and if that > mapping hangs around still while we try to map the gtt as wc the > kernel will downgrade our request to uc-, resulting in abyssal > performance. > > Unfortunately we

[Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do w

[Intel-gfx] [PULL] first drm-intel-next for 3.6

Hooray for yet again screwing up the recipient list! /me sucks -Daniel - Forwarded message from Daniel Vetter - Date: Tue, 12 Jun 2012 10:37:51 +0200 From: Daniel Vetter To: Intel Graphics Development , "Sun, Yi" Subject: Re: Updated -next Message-ID: <20120612083751.GA5188@phenom.ff

Re: [Intel-gfx] Updated -next

Hi Dave, rc2 is out the door so I've figured I'll annoy you with the first -next pull request for 3.6 already. Highlights: - new wait_rendring_timeout interface (Ben) - l3 cache remapping and error uevent support (Ben) - even more infoframes work from Paulo - gen4 hotplug rework from Chris - prep

[Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do w

Re: [Intel-gfx] [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

On Tue, Jun 12, 2012 at 1:43 AM, Ben Widawsky wrote: > We could probably fix this with a kernel command line too: > video=vesafb:mtrr:3 Well, to add insult to injury the affected system also didn't have a free mtrr :( > On Mon, 11 Jun 2012 18:28:12 +0200 > Daniel Vetter wrote: > >> Especially v

Re: [Intel-gfx] Debian 6 support for Sandy Bridge

See, Anthony Chaur Yih (12/06/2012): > From the 2010Q4 released package which is the earliest package that > support Sandy Bridge platform, the OS requirement look is much more > newer than Debian 6. Is there any way to enable Sandy Bridge with 3D > acceleration on Debin 6? Intel 2010Q4 graphics

Re: [Intel-gfx] Debian 6 (Squeeze) support for Sandy Bridge

Paul, Thanks, I had removed the HTML content. Yes. this is Debian 6 Squeeze. Did I need to upgrade X window version too through Debian backports? Thanks Anthony -Original Message- From: Paul Menzel [mailto:paulepan...@users.sourceforge.net] Sent: Tuesday, June 12, 2012 3:07 PM To: See, A

Re: [Intel-gfx] Debian 6 (Squeeze) support for Sandy Bridge

Dear Anthony, please send just plain text messages to lists and no HTML messages [1]. Am Dienstag, den 12.06.2012, 03:48 + schrieb See, Anthony Chaur Yih: > From the 2010Q4 released package which is the earliest package that > support Sandy Bridge platform, the OS requirement look is much