Signed-off-by: Ben Widawsky
---
tests/Makefile.am |1 +
tests/dpf_test|9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index c7f4f73..3eec64f 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -70,6 +70,7 @@ TESTS
Signed-off-by: Ben Widawsky
---
tests/dpf_test |8 +++
tools/Makefile.am |3 +-
tools/intel_l3_parity.c | 159 +++
3 files changed, 169 insertions(+), 1 deletion(-)
create mode 100755 tests/dpf_test
create mode 100644 tools/int
Dumb binary interfaces which allow root-only updates of the cache
remapping registers. As mentioned in a previous patch, software using
this interface needs to know about HW limits, and other programming
considerations as the kernel interface does no checking for these things
on the root-only inter
If any l3 rows have been previously remapped, we must remap them after
GPU reset/resume too.
v2: Just return (no warn) on remapping init if not IVB (Jesse)
Move the check of schizo userspace to i915_gem_l3_remap (Jesse)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
On IVB hardware we are given an interrupt whenever a L3 parity error
occurs in the L3 cache. The L3 cache is used by internal GPU clients
only. This is a very rare occurrence (in fact to test this I need to
use specially instrumented silicon).
When a row in the L3 cache detects a parity error the
The previous patch put all the code, and handlers in place. It should
now be safe to enable the parity error interrupt. The parity error must
be unmasked in both the GTIMR, and the CS IMR. Unfortunately, the docs
aren't clear about this; nevertheless it's the truth.
Reviewed-by: Jesse Barnes
Sign
On Fri, 25 May 2012 10:51:19 -0700
Jesse Barnes wrote:
> On Fri, 27 Apr 2012 17:40:21 -0700
> Ben Widawsky wrote:
>
> > Dumb binary interfaces which allow root-only updates of the cache
> > remapping registers. As mentioned in a previous patch, software using
> > this interface needs to know ab
On Thu, 24 May 2012 20:51:40 +0100
Chris Wilson wrote:
> On Thu, 24 May 2012 09:22:23 -0700, Jesse Barnes
> wrote:
> > This makes for easier benchmarking and testing. One can set a fixed
> > frequency by setting min and max to the same value.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> >
This makes for easier benchmarking and testing. One can set a fixed
frequency by setting min and max to the same value.
v2: fix whitespace & comment (Eugeni)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c | 66 +++
1 files changed, 66 inse
Prevents a possible hang: WaDisableL3Bank2xClockGate.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50245
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |3 +++
drivers/gpu/drm/i915/intel_pm.c |4
2 files changed, 7 insertions(+), 0 deletions(-)
diff --g
According to the bspec for MBCTL:
Driver must set bit in the following scenarios:
- to realod teh h/w boot context every time it gets loaded through OS
- after an FLR clears the register (BIOS won't run afterwards)
References: https://bugs.freedesktop.org/show_bug.cgi?id=50237
Signed-off-by:
Another required workaround for a potential hang:
WaDisableTDLUnitClockGating.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50245
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c |2 ++
2 files changed, 3 insertions(+), 0 d
The RCBP workaround still applies on these chips, and we need VDS as well.
v2: remove MB boot fetch that snuck in (Daniel)
add workaround tags to comments for easier internal tracking (Daniel)
References: https://bugs.freedesktop.org/show_bug.cgi?id=50251
Signed-off-by: Jesse Barnes
---
dri
On Fri, 25 May 2012 10:39:57 -0700
Jesse Barnes wrote:
> On Fri, 27 Apr 2012 17:40:20 -0700
> Ben Widawsky wrote:
>
> > If any l3 rows have been previously remapped, we must remap them after
> > GPU reset/resume too.
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/i915_d
On Fri, 25 May 2012 10:34:58 -0700
Jesse Barnes wrote:
> On Fri, 27 Apr 2012 17:40:18 -0700
> Ben Widawsky wrote:
> > +
> > +/**
> > + * ivybridge_parity_work - Workqueue called when a parity error interrupt
> > + * occurred.
> > + *
> > + * Doesn't actually do anything except notify userspace s
On Fri, 25 May 2012 10:34:58 -0700
Jesse Barnes wrote:
> > + misccpctl = I915_READ(GEN7_MISCCPCTL);
> > + I915_WRITE(GEN7_MISCCPCTL, misccpctl & ~GEN7_DOP_CLOCK_GATE_ENABLE);
>
> DOP clock gating should be unconditionally disabled, you can move this
> to the clock gating routine.
Ok I dug in
On Fri, 27 Apr 2012 17:40:21 -0700
Ben Widawsky wrote:
> Dumb binary interfaces which allow root-only updates of the cache
> remapping registers. As mentioned in a previous patch, software using
> this interface needs to know about HW limits, and other programming
> considerations as the kernel i
On Fri, 27 Apr 2012 17:40:20 -0700
Ben Widawsky wrote:
> If any l3 rows have been previously remapped, we must remap them after
> GPU reset/resume too.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.h |3 +++
> drivers/gpu/drm/i915/i915_gem.c | 26 +
On Fri, 27 Apr 2012 17:40:19 -0700
Ben Widawsky wrote:
> The previous patch put all the code, and handlers in place. It should
> now be safe to enable the parity error interrupt. The parity error must
> be unmasked in both the GTIMR, and the CS IMR. Unfortunately, the docs
> aren't clear about th
On Fri, 27 Apr 2012 17:40:18 -0700
Ben Widawsky wrote:
> +
> +/**
> + * ivybridge_parity_work - Workqueue called when a parity error interrupt
> + * occurred.
> + *
> + * Doesn't actually do anything except notify userspace so that userspace may
> + * disable things later on.
kdoc style comment b
On 5/24/12 3:26 PM, Daniel Vetter wrote:
Instead of reusing the polling code for hdp handling, split them up.
This has a few consequences:
- Don't touch HDP capable connectors in the poll loop.
- Only touch HDP capable connectors in drm_helper_hpd_irq_event.
- Run the HDP handling directly instea
On Fri, 25 May 2012 13:33:07 +0100
Chris Wilson wrote:
> From: Jesse Barnes
>
> In set_config we currently try to reset the CRTC if both the requested
> CRTC and the currently bound one are the same. The reason for this
> appears to be lost to history (it pre-dates KMS support upstream at
> le
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f4b2281..6eca39e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/g
When dealing with a working set larger than the GATT, or even the
mappable aperture when touching through the GTT, we end up with evicting
objects only to rebind them at a new offset again later. Moving an
object into and out of the GTT requires clflushing the pages, thus
causing a double-clflush p
From: Jesse Barnes
And make sure we register the BIOS config framebuffer if needed.
---
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_fb.c | 12 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/
Given the persistence of an offset for the lifetime of an object, itis
easy to contemplate how the mmap space becomes badly fragmented to the
point that further allocations fail with ENOSPC. Our only recourse at
this point is to try to purge the objects to release some space and
reattempt the alloc
Avoid stalling and waiting for the GPU by checking to see if there is
sufficient inactive space in the aperture for us to bind the buffer
prior to writing through the GTT. If there is inadequate space we will
have to stall waiting for the GPU, and incur overheads moving objects
about. Instead, only
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 597a1ff..aa01e44 100644
--- a/drivers/gpu/drm/i915
It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then
A few of the earlier registers where enlarged and so the Base Data of
Stolem Memory Register (BDSM) was pushed to 0xb0.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_stolen.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_
If we have created a scatterlist for the physical mapping of the object,
simply use it. This facilitates the later insertion of stolen objects
into the GATT which are not backed by struct page.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 19 ---
1 file
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
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem_stolen.c | 114 +--
As we wish to create specialised object constructions in the near
future that share the same basic GEM object struct, export the default
initializer.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 32 +++-
In order to accommodate objects that are not backed by struct pages, but
instead point into a contiguous region of stolen space, we need to make
various changes to avoid dereferencing obj->pages or obj->base.filp.
First introduce a marker for the stolen object, that specifies its
offset into the s
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 44 ++-
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d46e1dd..7576937 100644
--- a/drivers/gpu/drm/i91
From: Jesse Barnes
To better optimize mode sets that occur at boot time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_lvds.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 9de
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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|3 +
drivers/gpu/drm
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 0f4149e..64a0ea0 100644
--- a/drivers/gpu/drm/i915/intel_rin
This will be shared with wrapping the BIOS framebuffer into the fbdev
later. In the meantime, we can tidy the code slightly and improve the
error path handling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fb.c | 125 +--
1 file changed, 69 inse
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c
From: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 391fc41..3c7b876 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1242,1
From: Jesse Barnes
In set_config we currently try to reset the CRTC if both the requested
CRTC and the currently bound one are the same. The reason for this
appears to be lost to history (it pre-dates KMS support upstream at
least).
Remove this restriction to allow existing configs to be simple
From: Jesse Barnes
Rather than building a config which may or may not work, let the driver
build an initial fb config. This allows the driver to use the BIOS boot
configuration for example, displaying kernel messages and the initial fb
console on the same outputs the BIOS lit up at boot time. I
From: Jesse Barnes
This allows subsequent mode sets to do less work if possible, reducing
flicker and speeding up boot time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c | 11 ++--
drivers/gpu/drm/i915/intel_display.c | 101 +-
drivers
From: Jesse Barnes
Makes debugging new configs easier.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fb.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 12a0c14..5550de7 100644
---
From: Jesse Barnes
We want to avoid these as much as possible.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_lvds.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 0248391..83204b6 100644
--- a/d
From: Jesse Barnes
We were passing a drm_device and drm_crtc. Just get the drm_device from
the drm_crtc structure.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |6 +++---
drivers/gpu/drm/i915/intel_drv.h |3 +--
drivers/gpu/drm/i915/intel_dvo.c |2 +
From: Jesse Barnes
This is roughly 1920x1080 with reduced blanking. Hack it for now until
we read out the real clock from HW or from the panel's native mode.
---
drivers/gpu/drm/i915/intel_display.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/d
To be used later by i915 to preallocate exact blocks of space from the
range manager.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_mm.c | 49 ++
include/drm/drm_mm.h |4
2 files changed, 53 insertions(+)
diff --g
From: Jesse Barnes
If the BIOS was in VGA mode, the planes may have been disabled, so we
need to enable them when the first update_plane call comes in.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i9
From: Jesse Barnes
Read the sync polarity from the output configuration when assigning the
initial mode to the current configuration. This allows a later
set_config call to match the current mode and use a flip instead.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_crt.c |
From: Jesse Barnes
Just use crtc->dev instead of passing the dev..
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
We need to turn off any CRTCs that may have been left on by the BIOS but
that we are not wrapping for KMS.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fb.c | 75 +--
1 file changed, 72 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
From: Jesse Barnes
If the BIOS hands us a multi-pipe configuration, try to allocate an fb
large enough for the largest screen and preserve the mode.
Still need to fix the other initial_config function in case one or more
of the pipes was rejected due to an incompatibility with the others.
Signe
From: Jesse Barnes
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fb.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 5550de7..74bd22e 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b
From: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6afe082..4ff412a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/in
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c |4 ++
drivers/gpu/drm/i915/intel_display.c |3 -
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_fb.c | 118 --
4 files changed, 119 insertions(+), 7 delet
Wrap a preallocated region of stolen memory within an ordinary GEM
object, for example the BIOS framebuffer.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|5 +++
drivers/gpu/drm/i915/i915_gem_stolen.c | 58
2 files changed, 63 inse
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_overlay.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index a1ae18a..3d520cf 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fb.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index bf86907..d7ebf6c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i91
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 46 ++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ec4ddeb..d46e1dd 100644
--- a/drivers/gpu/drm/i91
Check to see if we've reached the end before dereferencing to get the
next scatterlist. This helps when creating scatterlists by hand.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/dr
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ---
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3e00b27..5c9f542 100644
--- a/drivers/gpu/drm/i915/i915_d
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 44 ++-
1 file changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 578b38a..597a1ff 100644
--- a/drivers/gpu/drm/i91
Here's the current state of the fastboot work by Jesse. The goal is to
preserve the framebuffer as setup by the BIOS or grub for fbcon and so
avoid any flicker right up until X. X is likely to replace everything
and so incur a modechange, but ultimately even it may be satisfied and
we may contrive
On Fri, May 25, 2012 at 09:25:35AM -0300, Paulo Zanoni wrote:
> 2012/5/25 Chris Wilson :
> > Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the
> > separate HDMI registers where introduced with the first PCH) and so
> > g4x_hdmi_connected() never selected the right bit and always
2012/5/25 Chris Wilson :
> Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the
> separate HDMI registers where introduced with the first PCH) and so
> g4x_hdmi_connected() never selected the right bit and always returned
> disconnected.
>
> Regression in
>
> commit 8ec22b214d76773c
On Thu, May 24, 2012 at 03:03:11PM -0700, Ben Widawsky wrote:
> Wait request is poorly named IMO. After working with these functions for
> some time, I feel it's much clearer to name the functions more
> appropriately.
>
> Of course we must update the callers to use the new name as well.
>
> This
Useful for ->detect functions that have different behaviour if force
is set. This way probe_single_connector can avoid to do the expensive
edid dance on connectors where this is not needed.
I've checked through all drivers and set this flag everywhere where
the connector->detect function has diffe
On Thu, May 24, 2012 at 05:56:24PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> A set of fixes for 3.5:
> - Fixes for regressions in 3.5: fix spurious gmbus NAK, fix module unload,
> fix pch pll asserts.
> - Fix up eDP panel power sequencing - turns out we need to keep vdd on
> while switching e
Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the
separate HDMI registers where introduced with the first PCH) and so
g4x_hdmi_connected() never selected the right bit and always returned
disconnected.
Regression in
commit 8ec22b214d76773c9d89f4040505ce10f677ed9a
Author: Chris
On Thu, May 24, 2012 at 07:11:20PM +0100, Chris Wilson wrote:
> This is now used intentionally to prevent proliferation of is-pinned
> checks upon the inactive list following:
>
> commit 1b50247a8ddde4af5aaa0e6bc125615372ce6c16
> Author: Chris Wilson
> Date: Tue Apr 24 15:47:30 2012 +0100
>
>
On Thu, May 24, 2012 at 08:48:12PM +0100, Chris Wilson wrote:
> Broadwater and Crestline share a limitation that prevent it from
> relocating general surface state above 4GiB. The only recourse we have
> since any buffer object may be used as a relocation target is then to
> limit all object alloca
74 matches
Mail list logo
