On Fri, Feb 22, 2013 at 10:58:16AM +0800, Daniel J Blueman wrote:
With linux 3.8, I experienced a SNB GPU lockup an hour into a gnome-3 session.
If interested, I've put the captured state at:
http://quora.org/i915_error_state
and
http://quora.org/Xorg.0.log
See
Hi Chris,
On 22 February 2013 16:21, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, Feb 22, 2013 at 10:58:16AM +0800, Daniel J Blueman wrote:
With linux 3.8, I experienced a SNB GPU lockup an hour into a gnome-3
session.
If interested, I've put the captured state at:
On Fri, Feb 22, 2013 at 12:53:04AM +0100, Daniel Vetter wrote:
This reverts
commit 8ec22b214d76773c9d89f4040505ce10f677ed9a
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Fri May 11 18:01:34 2012 +0100
drm/i915/hdmi: Query the live connector status bit for G4x
and
commit
Currently only containing the requested and the adjusted mode. And
only crtc callbacks are converted somewhat to it, encoders will be
done on a as-needed basis (simply too much churn in one patch
otherwise).
Future patches will add tons more useful stuff to this struct,
starting with the very
On Fri, Feb 22, 2013 at 08:36:57AM +, Chris Wilson wrote:
On Fri, Feb 22, 2013 at 12:53:04AM +0100, Daniel Vetter wrote:
This reverts
commit 8ec22b214d76773c9d89f4040505ce10f677ed9a
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Fri May 11 18:01:34 2012 +0100
We've had our fair share of woes already which showed that we can't
rely on the bpc limits in the EDID for eDP panels without risking
black screens. So now we limit the depth by what the BIOS recommends
in the VBT:
commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145
Author: Jani Nikula
Hi Dave,
I'll be Snowboarding next week, so I've figured I'll push out my pending
fixes queue. Only two patches, both fix regressions.
Cheers, Daniel
The following changes since commit 210561ffd72d00eccf12c0131b8024d5436bae95:
intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
From: Ville Syrjälä ville.syrj...@linux.intel.com
Point crtc-fb the the new framebuffer only after we know that the flip
was succesfully queued.
While at it, move the intel_fb and obj assignments a bit close to where
they're used.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
The pointer passed to copy_from_user() was cast to the wrong type. This
doesn't cause any issues, but it confuses the reader. Just cast to
void * like we do for the other execbuffer kernel-user copies.
Signed-off-by: Ville Syrjälä
ville.syrj...@linux.intel.com writes:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Point crtc-fb the the new framebuffer only after we know that the flip
was succesfully queued.
While at it, move the intel_fb and obj assignments a bit close to where
they're used.
Cc:
On Fri, Feb 22, 2013 at 03:42:22PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The pointer passed to copy_from_user() was cast to the wrong type. This
doesn't cause any issues, but it confuses the reader. Just cast to
void * like we do for
On Fri, Feb 22, 2013 at 12:56:47AM +0100, Daniel Vetter wrote:
Only used by the lvds encoder. Note that we shouldn't do the same
simple conversion with the FORCE_6BPC flag, since that's much better
handled by moving all the pipe_bpc computation around.
Signed-off-by: Daniel Vetter
From: Ville Syrjälä ville.syrj...@linux.intel.com
to_user_ptr() simply casts a pointer passed as u64 from user space
to void __user * correctly. Using this lets us get rid of all the
tiresome casts.
The idea came from Chris Wilson ch...@chris-wilson.co.uk.
Signed-off-by: Ville Syrjälä
On Fri, Feb 22, 2013 at 04:12:51PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
to_user_ptr() simply casts a pointer passed as u64 from user space
to void __user * correctly. Using this lets us get rid of all the
tiresome casts.
The idea
On Fri, Feb 22, 2013 at 01:31:35PM +, Chris Wilson wrote:
On Fri, Feb 22, 2013 at 02:17:24PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Point crtc-fb the the new framebuffer only after we know that the flip
was succesfully queued.
On Fri, Feb 22, 2013 at 04:36:38PM +0200, Ville Syrjälä wrote:
On Fri, Feb 22, 2013 at 01:31:35PM +, Chris Wilson wrote:
On Fri, Feb 22, 2013 at 02:17:24PM +0200, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Point crtc-fb the the new
From: Ville Syrjälä ville.syrj...@linux.intel.com
Restore crtc-fb to the old framebuffer if queue_flip fails.
While at it, kill the pointless intel_fb temp variable.
v2: Update crtc-fb before queue_flip and restore it back
after a failure.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville
On Fri, Feb 22, 2013 at 04:53:38PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Restore crtc-fb to the old framebuffer if queue_flip fails.
While at it, kill the pointless intel_fb temp variable.
v2: Update crtc-fb before queue_flip and
On Thu, 21 Feb 2013 22:05:33 -0800
Ben Widawsky b...@bwidawsk.net wrote:
With the introduction of the forcewake dance:
commit cac8f8b52621f246a7cff412f340a7db28cb1b99
Author: Ben Widawsky b...@bwidawsk.net
Date: Thu Jul 28 13:40:19 2011 -0700
forcewake: Add mmio code to do proper
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
Here's a new series that tries to report FIFO underruns. The new implementation
is completely different from the old one, due to the reviews I received. Now we
don't just ignore the FIFO underrun interrupts when we receive them, we
effectively
From: Paulo Zanoni paulo.r.zan...@intel.com
From the docs:
IIR can queue up to two interrupt events. When the IIR is cleared,
it will set itself again after one clock if a second event was
stored.
Only the rising edge of the PCH Display interrupt will cause the
North Display IIR
From: Paulo Zanoni paulo.r.zan...@intel.com
In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
- after we receive one of these errors, we mask the interrupt, so
we won't get an interrupt storm and we also won't flood dmesg;
-
From: Paulo Zanoni paulo.r.zan...@intel.com
This is bad news and shouldn't be happening.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 14 --
drivers/gpu/drm/i915/i915_reg.h |2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
From: Paulo Zanoni paulo.r.zan...@intel.com
- It's a static function
- I just added a few more users to it
- Its sister ironlake_enable_display_irq is not marked as inline
- The compiler will still inline if it thinks it should do
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
The driver is not functional at this depth, so tell the user as much and
bail out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31375
---
src/intel_driver.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel_driver.c b/src/intel_driver.c
index
Carl Worth cwo...@cworth.org writes:
The driver is not functional at this depth, so tell the user as much and
bail out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31375
Yeah, we shouldn't be supporting 8bpp.
Reviewed-by: Eric Anholt e...@anholt.net
pgpX1BLFGjTWh.pgp
26 matches
Mail list logo