Re: [Intel-gfx] backtrace with 3.9.0-rc4 on MBP retina

On Mon, Mar 25, 2013 at 3:49 AM, Dave Airlie wrote: > Just stuck 3.9.0-rc4 on my MBP today, got this throwing up. Is the bad stuff just the WARN (bad locking in our init code, surprise!) or did i915.ko kill your eDP panel? Or is the non-responsive panel just the usual apple gpu switching fail we

Re: [Intel-gfx] backtrace with 3.9.0-rc4 on MBP retina

On Mon, Mar 25, 2013 at 8:02 PM, Daniel Vetter wrote: > On Mon, Mar 25, 2013 at 3:49 AM, Dave Airlie wrote: >> Just stuck 3.9.0-rc4 on my MBP today, got this throwing up. > > Is the bad stuff just the WARN (bad locking in our init code, > surprise!) or did i915.ko kill your eDP panel? Or is the >

[Intel-gfx] [PATCH] drm/i915: duct-tape locking when eDP init fails

Thanks to apple gpu mux fail we detect an eDP output, but can't read anything over dp aux. In the resulting failure path we then hit a paranoid WARN about potential locking. Since the WARN is pretty useful for normal operation just paper over it in the failure case by grabbing the demanded (but fo

Re: [Intel-gfx] [PATCH 1/2] drm/i915: keep backlight_level and backlight device brightness in sync

Any comments on these two patches? BR, Jani. On Tue, 12 Mar 2013, Jani Nikula wrote: > A single point of truth would be better than two, but achieving that would > require more abstractions for CONFIG_BACKLIGHT_CLASS_DEVICE=n with not a > whole lot of real benefits. Take the short route and ju

Re: [Intel-gfx] [PATCH] drm/i915: Don't overclock on Haswell

On Sat, 23 Mar 2013 17:46:31 -0700 Ben Widawsky wrote: > HSW doesn't overclock the same way as IVB or SNB. I do not know about > VLV, so I've kept that off as well. I'm still working on getting the doc > updates to explain how we overclock on Haswell. > > Cc: Jesse Barnes > Signed-off-by: Ben W

[Intel-gfx] [PATCH v2] drm/i915: Warn if a pipe is enabled with a bogus port

If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect port, we are currently trying to read PORT_CLK_SEL(port) with an uninitialized value. Handle that case by returning PORT_CLK_SEL_NONE and warning about it. v2: Move the warning inside intel_ddi_get_crtc_pll (Paulo Zanoni) Signed

Re: [Intel-gfx] [PATCH] drm/i915: Don't overclock on Haswell

On Mon, Mar 25, 2013 at 07:36:51AM -0700, Jesse Barnes wrote: > On Sat, 23 Mar 2013 17:46:31 -0700 > Ben Widawsky wrote: > > > HSW doesn't overclock the same way as IVB or SNB. I do not know about > > VLV, so I've kept that off as well. I'm still working on getting the doc > > updates to explain

[Intel-gfx] [PATCH] drm/i915: duct-tape locking when eDP init fails

Thanks to apple gpu mux fail we detect an eDP output, but can't read anything over dp aux. In the resulting failure path we then hit a paranoid WARN about potential locking. Since the WARN is pretty useful for normal operation just paper over it in the failure case by grabbing the demanded (but fo

Re: [Intel-gfx] [PATCH v2] drm/i915: Warn if a pipe is enabled with a bogus port

Hi 2013/3/25 Damien Lespiau : > If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect > port, we are currently trying to read PORT_CLK_SEL(port) with an > uninitialized value. > > Handle that case by returning PORT_CLK_SEL_NONE and warning about it. > > v2: Move the warning inside in

Re: [Intel-gfx] [PATCH] drm/i915: duct-tape locking when eDP init fails

On Mon, Mar 25, 2013 at 5:56 PM, Daniel Vetter wrote: > Thanks to apple gpu mux fail we detect an eDP output, but can't read > anything over dp aux. In the resulting failure path we then hit a > paranoid WARN about potential locking. > > Since the WARN is pretty useful for normal operation just pa

Re: [Intel-gfx] [PATCH v2] drm/i915: Warn if a pipe is enabled with a bogus port

On Mon, Mar 25, 2013 at 02:00:16PM -0300, Paulo Zanoni wrote: > Hi > > 2013/3/25 Damien Lespiau : > > If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect > > port, we are currently trying to read PORT_CLK_SEL(port) with an > > uninitialized value. > > > > Handle that case by return

[Intel-gfx] [PATCH 0/4] HSW PM - RC6 fixes, clean up and split

This series fixes a RC6 bug at HSW that can impact its performance. At my fiurst attempt I noticed more than 1W saved, but I didn't measured this lates series yet. Also there are 2 clean ups patches that removes unecessary registers and bits set for HSW. The latest patch is optional. It splits

[Intel-gfx] [PATCH 1/4] drm/i915: HSW PM Frequency bits fix

According to HSW PM programming guide, frequency bits starts at 24 instead of 25. v2: Paulo Zanoni noticed that only frequency bits can be set at GEN6_RPNSWREQ. All others are read only. CC: Ben Widawsky CC: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm

[Intel-gfx] [PATCH 2/4] drm/i915: HSW PM Cleaning - Removing unecessary register/bits set.

According to HSW PM Programming guide it is not needed touch this registers or setting these values anymore. CC: Zanoni Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_pm.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i

[Intel-gfx] [PATCH] drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)

f40ebd6b properly disabled the hsync/vsync logic at disable time, but neglected to re-enable them at enable time. v2: In the enable hook, restore the connector's expected DPMS level instead of forcing ON. Do this by stashing a back pointer to the connector in the crt (suggested by danvet) since o

[Intel-gfx] [PATCH 3/4] drm/i915: HSW PM - removing pcode read/write

Yet according to pm spec pcode read/write operations aren't necessary for HSW. CC: Paulo Zanoni Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_pm.c | 50 ++--- 1 file changed, 27 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/i915/in

[Intel-gfx] [PATCH 4/4] drm/i915: creating Haswell rc6 function

Power management, in special RC6 enabling, differs across platforms. This patch just split out enabling function for HSW. This is an attempt to make pm code more clean without multiple IS_HASWELL inside enable_rps function. This actually tends to get worse with upcoming platforms. Signed-off-by: R

[Intel-gfx] [PATCH xf86-video-intel] sna: Fix OpenBSD backlight control implementation

From: Mark Kettenis Fix cut'n'paste error such that this actually compiles. Signed-off-by: Mark Kettenis --- src/sna/sna_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c index 7891c8d..6d61650 100644 --- a/src/sna

[Intel-gfx] Installing drivers and needed packages for decoding

I am building a system where I will be encoding and decoding H.264 streams. I have an Ivy Bridge system running Fedora 17 booting the stock kernel on a minimal installation. Here are my questions: 1. I would like this system to be headless, thus I don't want a window manager or anything else

[Intel-gfx] [RFC xf86-video-intel] sna: OpenBSD drm_i915_gem_execbuffer2 support

The OpenBSD version of struct drm_i915_execbuffer2 doesn't include the member for cliprect support. Not entirely sure why. Perhaps when Owain Ainsworth added GEM support, it was already obvious that cliprects were not going to be supported on new hardware and therefore not worth supporting. Unfo

Re: [Intel-gfx] [PATCH 1/4] drm/i915: HSW PM Frequency bits fix

On Mon, Mar 25, 2013 at 05:55:49PM -0300, Rodrigo Vivi wrote: > According to HSW PM programming guide, frequency bits starts at > 24 instead of 25. > > v2: Paulo Zanoni noticed that only frequency bits can be set at > GEN6_RPNSWREQ. All others are read only. > > CC: Ben Widawsky > CC: Paulo Zano

Re: [Intel-gfx] [RFC xf86-video-intel] sna: OpenBSD drm_i915_gem_execbuffer2 support

On Mon, Mar 25, 2013 at 11:08:09PM +0100, Mark Kettenis wrote: > The OpenBSD version of struct drm_i915_execbuffer2 doesn't include the > member for cliprect support. Not entirely sure why. Perhaps when > Owain Ainsworth added GEM support, it was already obvious that > cliprects were not going to