Summary
We finished a new round of kernel testing. Generally, in this circle, No new
bug filed, 13 bugs are still opened,1 bugs are closed.
Test Environment
Kernel: (drm-intel-testing)4d8bd4f511f00cd7396736e3ebb9c1ffd939d341
Some additional commit info:
Merge: b343cd9 4a8dece
Author: Danie
On Thu, 15 Nov 2012 21:05:04 +0100
Daniel Vetter wrote:
> On Thu, Nov 15, 2012 at 7:24 PM, Jesse Barnes
> wrote:
> > This is needed for SNB at least after disabling CSunit clock gating, and
> > shouldn't hurt on other platforms either.
> >
> > This fixes an issue on James's machine where RC6 wo
On Thu, Nov 15, 2012 at 6:03 PM, Takashi Iwai wrote:
> Some IVB machines seem to need non-MT forcewake. Using MT forcewake
> on such machines result in broken or blank screens.
>
> Signed-off-by: Takashi Iwai
> ---
> The commit 36ec8f877481449bdfa072e6adf2060869e2b970 triggered a
> regression on
drivers/gpu/drm/i915/i915_drv.h:1545:2: warning: '__f' is static but
declared in inline function 'i915_gem_chipset_flush' which is not static
Reported-by: kbuild test robot
dri-devel-Reference: <50a4d41c.586vhmwghpukzbkb%fengguang...@intel.com>
Signed-off-by: Ben Widawsky
---
drivers/gpu/dr
On Thu, 2012-11-15 at 12:30 +0100, Daniel Vetter wrote:
> On Wed, Nov 14, 2012 at 12:46:38PM +0800, Xiang, Haihao wrote:
> > From: Zhao Yakui
> >
> > Signed-off-by: Zhao Yakui
>
> Fyi the best way is to simply run
>
> $ make headers_install
>
> in the latest kernel tree and copy the resultin
Begin forwarded message:
Date: Thu, 15 Nov 2012 12:06:09 -0800
From: Ben Widawsky
To: intel-gfx@lists.freedesktop.org, dri-de...@lists.freedesktop.org
Cc: Ben Widawsky
Subject: [PATCH] drm/i915: Fix warning in i915_gem_chipset_flush
drivers/gpu/drm/i915/i915_drv.h:1545:2: warning: '__f' is
At Thu, 15 Nov 2012 21:07:33 +0100,
Daniel Vetter wrote:
>
> On Thu, Nov 15, 2012 at 6:03 PM, Takashi Iwai wrote:
> > Some IVB machines seem to need non-MT forcewake. Using MT forcewake
> > on such machines result in broken or blank screens.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > The c
On Thu, Nov 15, 2012 at 7:24 PM, Jesse Barnes wrote:
> This is needed for SNB at least after disabling CSunit clock gating, and
> shouldn't hurt on other platforms either.
>
> This fixes an issue on James's machine where RC6 wouldn't always get
> enabled.
>
> Tested-by: James Kukunas
> Signed-off
On Wed, 14 Nov 2012, Jesse Barnes wrote:
> + unsigned long bad_ranges[] = {
> + 0x2005,
> + 0x2011,
> + 0x2013,
> + 0x20138000,
> + 0x40004000,
Yikes. Can this be fixed thro
This is needed for SNB at least after disabling CSunit clock gating, and
shouldn't hurt on other platforms either.
This fixes an issue on James's machine where RC6 wouldn't always get
enabled.
Tested-by: James Kukunas
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |1
On Wed, 14 Nov 2012 11:06:42 -0800
Ben Widawsky wrote:
> On Wed, 14 Nov 2012 09:15:14 +
> Chris Wilson wrote:
>
> > The bspec was recently updated to remove the ability to update the
> > semaphore using the MI_SEMAPHORE_BOX command, the ability to wait upon
> > the semaphore value remained.
Some IVB machines seem to need non-MT forcewake. Using MT forcewake
on such machines result in broken or blank screens.
Signed-off-by: Takashi Iwai
---
The commit 36ec8f877481449bdfa072e6adf2060869e2b970 triggered a
regression on my test IVY laptops. Instead of reverting the commit,
I cooked a
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we
We have two important transitions of the wedged state in the current
code:
- 0 -> 1: This means a hang has been detected, and signals to everyone
that they please get of any locks, so that the reset work item can
do its job.
- 1 -> 0: The reset handler has completed.
Now the last transition
On Thu, 15 Nov 2012 10:47:11 -0200
Henrique de Moraes Holschuh wrote:
> On Wed, 14 Nov 2012, Jesse Barnes wrote:
> > + unsigned long bad_ranges[] = {
> > + 0x2005,
> > + 0x2011,
> > + 0x2013,
> > + 0x201
On Thu, 15 Nov 2012 10:47:11 -0200
Henrique de Moraes Holschuh wrote:
> On Wed, 14 Nov 2012, Jesse Barnes wrote:
> > + unsigned long bad_ranges[] = {
> > + 0x2005,
> > + 0x2011,
> > + 0x2013,
> > + 0x201
On Thu, 15 Nov 2012 16:53:58 +0100, Daniel Vetter
wrote:
> Since we drop dev->struct_mutex when going through the slowpath, the
> object might have been moved out of the cpu domain. Hence we need to
> clflush the entire object to ensure that after the ioctl returns,
> everything is coherent again
Since we drop dev->struct_mutex when going through the slowpath, the
object might have been moved out of the cpu domain. Hence we need to
clflush the entire object to ensure that after the ioctl returns,
everything is coherent again (interwoven writes are ill-defined
anyway).
But we only need to d
On Thu, 15 Nov 2012 16:20:49 +0100, Daniel Vetter
wrote:
> Since we drop dev->struct_mutex when going through the slowpath, the
> object might have been moved out of the cpu domain. Hence we need to
> clflush the entire object to ensure that after the ioctl returns,
> everything is coherent again
Since we drop dev->struct_mutex when going through the slowpath, the
object might have been moved out of the cpu domain. Hence we need to
clflush the entire object to ensure that after the ioctl returns,
everything is coherent again (interwoven writes are ill-defined
anyway).
But we only need to d
On Thu, 15 Nov 2012 15:40:06 +0100, Daniel Vetter
wrote:
> Since we drop dev->struct_mutex when going through the slowpath, the
> object might have been moved out of the cpu domain. Hence we need to
> clflush the entire object to ensure that after the ioctl returns,
> everything is coherent again
On Thu, 15 Nov 2012 15:40:06 +0100, Daniel Vetter
wrote:
> Since we drop dev->struct_mutex when going through the slowpath, the
> object might have been moved out of the cpu domain. Hence we need to
> clflush the entire object to ensure that after the ioctl returns,
> everything is coherent again
On Thu, Nov 15, 2012 at 12:33:59PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/11/1 Daniel Vetter :
> > On Thu, Nov 1, 2012 at 4:52 PM, Paulo Zanoni wrote:
> >> The only problem is: we're not doing anything here for the
> >> HAS_PCH_SPLIT platforms. Shouldn't we be doing something? We do have
> >> e
Since we drop dev->struct_mutex when going through the slowpath, the
object might have been moved out of the cpu domain. Hence we need to
clflush the entire object to ensure that after the ioctl returns,
everything is coherent again (interwoven writes are ill-defined
anyway).
But we only need to d
The shmem paths for pwrite/pread used a clever trick to hold onto a
single page when dropping the big dev->struct_mutex for the slowpath.
But this ran the risk of reinstating (or not completely purging) the
backing storage when dropping purgeable objects.
Hence the code needed to keep track of whe
Hi
2012/11/1 Daniel Vetter :
> On Thu, Nov 1, 2012 at 4:52 PM, Paulo Zanoni wrote:
>> The only problem is: we're not doing anything here for the
>> HAS_PCH_SPLIT platforms. Shouldn't we be doing something? We do have
>> eDP code to set the PCH_PP registers, but not LVDS code for this.
>> Also, ea
On Thu, Nov 15, 2012 at 10:42:02AM +, Chris Wilson wrote:
> On Wed, 14 Nov 2012 17:47:39 +0100, Daniel Vetter
> wrote:
> > Jani Nikula noticed that the parentheses are wrong and we & the bit
> > with the register address instead of the read-back value. He sent a
> > patch to correct that.
> >
The routine to query the base of stolen memory was using the wrong
registers and the wrong encodings on virtually every platform.
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 registe
To be used later by i915 to preallocate exact blocks of space from the
range manager.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c | 50 ++
include/drm/drm_mm.h |4
2 files
As yet we do not do any preallocation (chicken-and-egg problem), but we
may like to preserve anything already allocated by the BIOS or grub and
reuse for own purposes after initialising the driver.
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Reviewed-by: Ben Widawsky
---
drivers/gpu/
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 allocation of the FBC chunk until we actually
require it. This inc
Stolen objects also share the property that they have no backing shmemfs
filp, but they can be used with pwrite/pread/gtt-mapping.
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Reviewed-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/i915_gem.c |
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_create_stolen() as static, as noticed by Jesse
Barnes.
Signed-off-by: C
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Acked-by: Ben Widawsky
---
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 7b30b5c..b7773e5 100644
--- a/driver
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Acked-by: Ben Widawsky
---
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 221c2a5..
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, w
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Acked-by: Ben Widawsky
---
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 4956259..8877b9c
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 hit hardest.
Indeed as we do frequent the generic kmalloc caches
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 159 ---
1 file changed, 100 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a6a2893..9e66e29 100644
--- a/drivers/gpu/drm/i9
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 175 ++-
1 file changed, 116 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9e66e29..db87ce4 100644
--- a/drivers/gpu/drm/i9
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Reviewed-by: Ben Widawsky
---
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
index 2604867..205413f 100644
--- a/drivers/gpu/dr
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
This will be used i915 in forthcoming patches in order to measure the
largest contiguous chunk of memory available for enabling chipset
features.
v2: Try to make the macro marginally safer and more readable by not
depending upon the drm_mm_hole_node_end() being non-zero. Note that we
need to open
So nearly everything has been reviewed, thanks mostly to Ben and Jesse.
Both Ben and Paulo have tested the patches, and a smattering of bug
reporters have also unbeknownst to them also provided testing feedback.
It has been running on all of my machines for several months. The
stolen handling is a
On Wed, Nov 14, 2012 at 12:46:38PM +0800, Xiang, Haihao wrote:
> From: Zhao Yakui
>
> Signed-off-by: Zhao Yakui
Fyi the best way is to simply run
$ make headers_install
in the latest kernel tree and copy the resulting userspace header from
usr/include/drm/i915_drm.h to libdrm. Otherwise thing
On Wed, 14 Nov 2012 17:47:39 +0100, Daniel Vetter
wrote:
> Jani Nikula noticed that the parentheses are wrong and we & the bit
> with the register address instead of the read-back value. He sent a
> patch to correct that.
>
> On second look, we write the same register in the previous line, and
>
Hi Dave,
Just a few small things to fix regressions, somehow all patches from Jani:
- Fix dpms confusion about which platforms support intermediate modes on
vga.
- Revert the "ignore vbt for eDP bpc" patch, it breaks machines. This will
annoy mbp retina owners again, but windows machines seem
From: "Xiang, Haihao"
The code is surround by a #ifdef...#endif to avoid to break compiling against
the current libdrm release
Signed-off-by: Xiang, Haihao
---
tests/gem_ring_sync_loop.c | 12
1 file changed, 12 insertions(+)
diff --git a/tests/gem_ring_sync_loop.c b/tests/gem_
On Wed, 2012-11-14 at 08:23 +, Chris Wilson wrote:
> On Wed, 14 Nov 2012 12:55:54 +0800, "Xiang, Haihao"
> wrote:
> > From: "Xiang, Haihao"
> >
> > Xiang, Haihao (2):
> > tests: storedw on VEBOX
> > Update gem_ring_sync_loop to support VEBOX ring (the 4th ring) on
> > Haswell
>
>
From: "Xiang, Haihao"
Signed-off-by: Xiang, Haihao
---
tests/gem_ring_sync_loop.c | 37 ++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/tests/gem_ring_sync_loop.c b/tests/gem_ring_sync_loop.c
index b689bcd..2875cf3 100644
--- a/tests/gem_ri
50 matches
Mail list logo
