On stock 3.6.5 at boot+403586.244s, I hit this:
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
At boot+403596.318s, I see in Xorg.0.log:
[mi] Increasing EQ size to 512 to prevent droppe
After the rework, intel_set_mode() became a little better behaved in
restoring the current mode if we failed to apply the requested modeline.
However, the failure path for load-detect would clobber the existing
state, leading to an oops during BIOS takeover on older machines.
Signed-off-by: Chris
With the stricter checks introduced in
commit ac911edae5960d7dccd9883f5fa5d25b591520de
Author: Ville Syrjälä
Date: Wed Oct 31 17:50:19 2012 +0200
drm/i915: Check the framebuffer offset
(and friends), it became especially prudent to make sure that the
additional fields inside the mode were
On Mon, 5 Nov 2012 17:49:35 +, Ben Widawsky wrote:
> On Fri, 19 Oct 2012 18:03:23 +0100
> Chris Wilson wrote:
>
> > The primary purpose of this was to debug some use-after-free memory
> > corruption that was causing an OOPS inside drm/i915. As it turned out
> > the corruption was being cause
On Mon, 5 Nov 2012 18:07:53 +
Ben Widawsky wrote:
> On Fri, 19 Oct 2012 18:03:23 +0100
> Chris Wilson wrote:
>
> > The primary purpose of this was to debug some use-after-free memory
> > corruption that was causing an OOPS inside drm/i915. As it turned out
> > the corruption was being cause
On Fri, 19 Oct 2012 18:03:23 +0100
Chris Wilson wrote:
> The primary purpose of this was to debug some use-after-free memory
> corruption that was causing an OOPS inside drm/i915. As it turned out
> the corruption was being caused elsewhere and i915.ko as a major user of
> many objects was being
On Fri, 19 Oct 2012 18:03:23 +0100
Chris Wilson wrote:
> The primary purpose of this was to debug some use-after-free memory
> corruption that was causing an OOPS inside drm/i915. As it turned out
> the corruption was being caused elsewhere and i915.ko as a major user of
> many objects was being
On Fri, 19 Oct 2012 18:03:22 +0100
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Reviewed-by: Jesse Barnes
14-16 are:
Acked-by: Ben Widawsky
I think it's a nice way to prove the existing code works, but am a
little scared of putting something like the ringbuffer in stolen memory.
--
On Mon, 05 Nov 2012 16:59:44 +
Chris Wilson wrote:
> On Mon, 5 Nov 2012 16:32:26 +, Ben Widawsky wrote:
> > On Fri, 19 Oct 2012 18:03:19 +0100
> > Chris Wilson wrote:
> >
> > > Allow for the creation of GEM objects backed by stolen memory. As these
> > > are not backed by ordinary page
On Mon, 5 Nov 2012 16:32:26 +, Ben Widawsky wrote:
> On Fri, 19 Oct 2012 18:03:19 +0100
> Chris Wilson wrote:
>
> > Allow for the creation of GEM objects backed by stolen memory. As these
> > are not backed by ordinary pages, we create a fake dma mapping and store
> > the address in the scat
On Fri, 19 Oct 2012 18:03:19 +0100
Chris Wilson wrote:
> Allow for the creation of GEM objects backed by stolen memory. As these
> are not backed by ordinary pages, we create a fake dma mapping and store
> the address in the scatterlist rather than obj->pages.
>
> v2: Mark _i915_gem_object_creat
On Fri, 19 Oct 2012 18:03:16 +0100
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Reviewed-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_irq.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> inde
On Mon, 5 Nov 2012 15:20:53 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_pipe_set_base() never actually waited for any pending page flips
> on the CRTC. It looks like it tried to, by calling intel_finish_fb() on
> the current front buffer. But the pending flips w
On Mon, 05 Nov 2012 15:28:42 +
Chris Wilson wrote:
> On Mon, 5 Nov 2012 15:00:36 +, Ben Widawsky wrote:
> > On Fri, 19 Oct 2012 18:03:13 +0100
> > Chris Wilson wrote:
> >
> > > As FBC is commonly disabled due to limitations of the chipset upon
> > > output configurations, on many syste
On Mon, 5 Nov 2012 15:00:36 +, Ben Widawsky wrote:
> On Fri, 19 Oct 2012 18:03:13 +0100
> Chris Wilson wrote:
>
> > As FBC is commonly disabled due to limitations of the chipset upon
> > output configurations, on many systems FBC is never enabled. For those
> > systems, it is advantageous to
On Mon, 5 Nov 2012 13:44:13 +, Ben Widawsky wrote:
> > -static void i915_setup_compression(struct drm_device *dev, int size)
> > +static int i915_setup_compression(struct drm_device *dev, int size)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct drm_mm_node
On Mon, 5 Nov 2012 13:41:06 +, Ben Widawsky wrote:
> On Fri, 19 Oct 2012 18:03:11 +0100
> Chris Wilson wrote:
> > - BUG_ON(drm_mm_hole_node_start(node)
> > - != drm_mm_hole_node_end(node));
> > + BUG_ON(node->start + node->size !=
> > +
On Fri, 19 Oct 2012 18:03:13 +0100
Chris Wilson wrote:
> As FBC is commonly disabled due to limitations of the chipset upon
> output configurations, on many systems FBC is never enabled. For those
> systems, it is advantageous to make use of the stolen memory for other
> objects and so we defer a
On Fri, 02 Nov 2012 08:54:39 +
Chris Wilson wrote:
> On Thu, 1 Nov 2012 17:08:20 -0700, Ben Widawsky wrote:
> > On Sun, 28 Oct 2012 09:48:35 +
> > Chris Wilson wrote:
> >
> > > On Fri, 26 Oct 2012 14:58:45 -0700, Ben Widawsky
> > > wrote:
> > > > On Fri, 19 Oct 2012 18:03:09 +0100
>
On Fri, 19 Oct 2012 18:03:12 +0100
Chris Wilson wrote:
> As we may wish to wrap regions preallocated by the BIOS, we need to do
> that before carving out contiguous chunks of stolen space for FBC.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Jesse Barnes
More nitckicks:
Reviewed-by: Ben Wid
On Fri, 19 Oct 2012 18:03:11 +0100
Chris Wilson wrote:
> This will be used i915 in forthcoming patches in order to measure the
> largest contiguous chunk of memory available for enabling chipset
> features.
>
> Signed-off-by: Chris Wilson
> Cc: Dave Airlie
nitpicks below
Reviewed-by: Ben Wida
From: Ville Syrjälä
intel_pipe_set_base() never actually waited for any pending page flips
on the CRTC. It looks like it tried to, by calling intel_finish_fb() on
the current front buffer. But the pending flips were actually tracked
in the BO of the previous front buffer, so the call to intel_fin
I like abstraction and vfuncs, but only if they actually abstract anything.
In this case here they just obfuscate, so let's rip this stuff out.
Aside: We really should move all the haswell stuff into it's own file ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
We don't use these on haswell, since haswell as per-pipe watermarks
and nothing global any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
We already update watermarks at all the right places in the
crtc_enable/disable callbacks. And since ->mode_set doesn't change the
active state, nothing will have changed ...
v2: Rebase on top of latest haswell copy&pasta.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |
Both the dp and fdi code use the exact same computations (ignore minor
differences in conversion between bits and bytes).
This makes it even more apparent that we have a _massive_ mess between
cpu transcoder/fdi link/pch transcoder and pch link settings. And also
that we have hilarious amounts of
This has originally been added in
commit 8db9d77b1b14fd730561f64beea8c00e4478d7c5
Author: Zhenyu Wang
Date: Wed Apr 7 16:15:54 2010 +0800
drm/i915: Support for Cougarpoint PCH display pipeline
probably to combat issues with hw state left behind by the BIOS. And
indeed, I've checked out th
This could have happened with the old crtc helper based modeset code,
but can't happen any longer with the new code.
Hence put in a WARN and adjust the comment. If no one hits this, we
can eventually remove it (like a few other such cases across our
code).
Signed-off-by: Daniel Vetter
---
drive
17 ms is eerily close to 60 Hz ^-1
Unfortunately this goes back to the original DP enabling for ilk, and
unfortunately does not come with a reason for it's existance attached.
Some closer inspection of the code and DP specs shows that we set the
idle link pattern before we disable the port. And i
While reading docs I've noticed that this special workaround to select
the 1.6 GHz DP clock only applies to pre-production ilk machines.
Since the registers we're touching here are rather undocumented and
might be harmful on later chips, rip it out.
For the Bspec reference of this w/a look in "vol
Now that we enable the cpu edp pll in intel_dp->pre_enable and no
longer in crtc_mode_set, we can also move the modeset part to the
intel_dp->mode_set callback. Previously this was not possible because
the encoder ->mode_set callbacks are called after the crtc mode set
callback.
v2: Rebase on top
Hi all,
Mostly just moves the dp code to saner places, but I've also thrown 3 patches on
top to remove some bloat around the watermark handling.
Right the next patch in my modeset-rework branch after this pile is the
introduction of the intel_crtc_config to precompute the pipe config. I'm not yet
Especially getting rid of all things lvds is ... great!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 114 +--
1 file changed, 1 insertion(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/int
Only two things needed adjustment:
- pipe select for PCH_CPT
- There's no dithering bit on ilk+ in the lvds ctl reg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 40
drivers/gpu/drm/i915/intel_lvds.c| 24 ++
2
A few things needed to change:
- HAS_PCH_SPLIT since ilk+ is not yet converted to this.
- s/LVDS/intel_lvds->reg/ to prep for ilk conversion
- replace the clock.p2 == 7 check with a is_dual_link check
- s/adjusted_mode/intel_lvds->fixed_mode
v2: Rebase on top of Jani Nikula's panel rework. I'm won
To ditch at least some of the PCH_SPLIT ? PCH_LVDS : LVDS code ...
v2: Rebase on top of Jani Nikula's panel rework.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 48 ---
1 file changed, 20 insertions(+), 28 deletions(-)
diff --git a/dr
Yeah, all users (both the clock selection special cases and the lvds
pin pair stuff) are still in common code, but this will change.
v2: Rebase on top of Jani Nikula's panel rework.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 43 +++
Just a prep patch to make this a property of intel_lvds. Makes more
sense, removes clutter from intel_display.c and eventually I want to
move all the encoder special cases wrt clock handling to encoders
anyway.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 60 +++---
... with is_dual_link_lvds introduced in
commit b03543857fd75876b96e10d4320b775e95041bb7
Author: Takashi Iwai
Date: Tue Mar 20 13:07:05 2012 +0100
drm/i915: Check VBIOS value for determining LVDS dual channel mode, too
All these checks predate this commit and have simply been overlooked.
Currently we have two encoder specific bits in the common mode_set
functions:
- lvds pin pair enabling
- dp m/n setting and computation
Both need to happen before we enable the pll. Since that is done in
the crtc_mode_set functions, we need to add a new callback to be able
to move them to the enco
Hi all,
This is the first cleanup from my next stab at reworking the modeset code, with
the ultimate goal that we can compute the entire configuration (fdi config, pll
config, sharing of global resources) up-front, before touching the hw at all.
Together with some neat hw state readout this should
PCH platforms and VLV should map DPMS standby and suspend modes to off, but
due to a buggy reversed comparison this is done on pre-PCH platforms
instead.
Reported-by: Loïc Yhuel
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56754
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/inte
On Thursday 1 November 2012 09:58:51 Jesse Barnes wrote:
> On Thu, 01 Nov 2012 16:52:05 +
> Tvrtko Ursulin wrote:
>
> > On Thursday 01 November 2012 16:20:03 Chris Wilson wrote:
> > > On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes
> > >
> > wrote:
> > > > On Thu, 01 Nov 2012 15:52:23 +000
43 matches
Mail list logo
