Carl Worth 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
pgpX1BLFGjTWh.pgp
Description: PGP signature
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 7807106..
From: Paulo Zanoni
- 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
---
drivers/gpu/drm/i915/i915_irq.c |2 +-
1 file ch
From: Paulo Zanoni
This is bad news and shouldn't be happening.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 14 --
drivers/gpu/drm/i915/i915_reg.h |2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/dr
From: Paulo Zanoni
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;
- at each mode set we en
From: Paulo Zanoni
>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 (DEIIR) PCH Display Interr
From: Paulo Zanoni
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 disable the interrupts (the
On Thu, 21 Feb 2013 22:05:33 -0800
Ben Widawsky wrote:
> With the introduction of the forcewake dance:
>
> commit cac8f8b52621f246a7cff412f340a7db28cb1b99
> Author: Ben Widawsky
> Date: Thu Jul 28 13:40:19 2011 -0700
>
> forcewake: Add mmio code to do proper forcewake stuff for gen6
>
>
On Fri, Feb 22, 2013 at 04:53:38PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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
> a
From: Ville Syrjälä
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 Syrjälä
---
drivers/gpu/drm/
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ä
> > >
> > > Point crtc->fb the the new framebuffer only
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ä
> >
> > Point crtc->fb the the new framebuffer only after we know that the flip
> > was succesfully queued.
> >
> > While at it,
On Fri, Feb 22, 2013 at 04:12:51PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 .
From: Ville Syrjälä
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 .
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h| 5 +
dr
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
> ---
On Fri, Feb 22, 2013 at 03:42:22PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> 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
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/i915_gem_execbuf
On Fri, Feb 22, 2013 at 02:17:24PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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.
>
From: Ville Syrjälä
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ä
---
It looks like Mika hit this rath
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 (201
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
Date: Mon No
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
> > Date: Fri May 11 18:01:34 2012 +0100
> >
> > drm/i915/hdmi: Q
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 simp
On Fri, Feb 22, 2013 at 12:56:45AM +0100, Daniel Vetter wrote:
> 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
On Fri, Feb 22, 2013 at 12:53:04AM +0100, Daniel Vetter wrote:
> This reverts
>
> commit 8ec22b214d76773c9d89f4040505ce10f677ed9a
> Author: Chris Wilson
> Date: Fri May 11 18:01:34 2012 +0100
>
> drm/i915/hdmi: Query the live connector status bit for G4x
>
> and
>
> commit b0ea7d37a8f63e
Hi Chris,
On 22 February 2013 16:21, Chris Wilson 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:
>> http://quora.org/i915_error_st
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 https://bygs.freedeskto
28 matches
Mail list logo