the
max pitch value is 16 for 512 byte wide tiles.
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
. Ainsworth o...@openbsd.org
Minor comment inline.
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 42 ++
1 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers
as it
would on the ioctl being called.
Discussed with danvet and jbarnes.
Signed-Off-By: Owain G. Ainsworth o...@openbsd.org
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing
Or else we may not write back the written pages upon unbind. For
example the contents of a batch buffer written using a simple mmap or
using shmmem pwrite may be discarded if we are forced to evict
everything whilst pinning the objects for execbuffer.
Signed-off-by: Chris Wilson ch...@chris
://bugs.freedesktop.org/show_bug.cgi?id=24369
Bug 15911 - Intermittent X crash (freeze)
https://bugzilla.kernel.org/show_bug.cgi?id=15911
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Tested-by: Christian von Schultz ker...@vonschultz.se
---
drivers/gpu/drm/i915/i915_drv.h | 13
at which we have to mmap
buffers should reduce as well...
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[a0207589] drm_mm_search_free+0x49/0x90 [drm]
RSP 8800699f3af8
CR2:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
On Tue, 18 May 2010 23:11:42 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Hi all,
This patch series implements the fair-lru eviction Chris Wilson already
posted with a twist. It's essentially the same idea algorithm.
Differnences versus his patch:
- Doesn't do any allocations while
a new bug on fd.o bugzilla?
commit 9f54107f866a25cf670f81f7c52b8c108728c6a5
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Tue May 11 14:55:16 2010 +0100
dri2: Handle reference counting across page flipping
1. Instead of swapping bos, swap the entire private structure.
2. If we
Otherwise we indicate success in the event of failure and this will lead
to an eventual OOPS.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
Only report an error if the GPU has actually detected one, otherwise we
are just hung.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_irq.c | 38 --
1 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers
Delay taking the mutex until we need to and ensure that we hold the
spinlock when resetting unpin_work on the error path. Also defer the
debugging print messages until after we have released the spinlock.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar
If the FBC is already disabled, then we do not even attempt to disable
FBC and so there is no point emitting a debug statement at that point,
having already emitted one saying why we are disabling FBC.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c
/show_bug.cgi?id=27070
Bug 15502 - render error detected, EIR: 0x0010
https://bugzilla.kernel.org/show_bug.cgi?id=15502
Bug 13844 - i915 error: render error detected
https://bugzilla.kernel.org/show_bug.cgi?id=13844
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_fb.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 6f53cf7..f8c76e6 100644
--- a/drivers/gpu/drm/i915
If the object is bigger than the entire aperture, reject it early
before evicting everything in a vain attempt to find space.
v2: Use E2BIG as suggested by Owain G. Ainsworth.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
---
drivers/gpu/drm/i915/i915_gem.c |8
The callers expect us to cleanup any partially initialised structures
before reporting the error.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm
Since we now get_user_pages() outside of the mutex prior to performing
the copy, we kmap() the page inside the copy routine and so need to
perform an ordinary memcpy() and not copy_from_user().
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 42
References:
Bug 26691 - Spurious hangcheck whilst executing a long shader over a
large vertex buffer
https://bugs.freedesktop.org/show_bug.cgi?id=26691
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915
We generally issue an error message at the point of failure, and so this
warning with a fairly pointless stacktrace is superfluous and ugly.
Needless to say, the common trigger for this WARN happens to be EIO
where this is pure noise.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
= tiled_pitch * height instead of size = tiled_pitch *
tile_aligned_height.
Hmm, something is fishy after applying the patch. The framebuffer pitch
for the 1920x1080 external display looks to be off by 2.
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
;
intel_reduce_ratio(m_n-gmch_m, m_n-gmch_n);
m_n-link_m = pixel_clock;
This rounds the gmch_m down. Is this correct? And how close to overflow
is pixel_clock today?
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
you to do so.
Hope this helps, and you have a lot of fun programming with the GPU
directly.
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
where we are trying to do a large allocation and our shrinker
would be prevented from running (due to contention on struct_mutex).
I do not know how this causes memory corruption across hibernate and would
appreciate any insights.
--
Chris Wilson, Intel Open Source Technology Centre
high resolution flash videos.
Any idea what the problem could be?
All depends upon the system. Jesse is working on a couple of patches that
address the change in handling of the vblank interrupt in some revisions
of the i945/i965 chipsets. That's the known failure mode...
--
Chris Wilson, Intel
50 89 45
bc 8b 45 a0 8b 52 38 89 55 d0 31 d2 f6 40 20 01 74 0d 8b 55 bc f6 42
69 30 0f 95 c2 0f b6 d2 8b 45 d0 c7 45 d4 00 00 00 00 89
EIP: [c11a4a02] i915_gem_do_execbuffer+0x71f/0xbb6 SS:ESP 0068:f6508dd4
CR2: 0069
---[ end trace 3f1d514b34d39381 ]---
Signed-off-by: Chris Wilson ch
it not be
fbCloseScreen that calls miCloseScreen, since fb has taken over the
management of the mi interface?
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org
From: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Acked-by: Thomas Hellstrom thellst...@vmwgfx.com
---
drivers/gpu/drm/drm_mm.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions
From: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Thomas Hellstrom thellst...@vmwgfx.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/drm_mm.c | 45 -
1 files changed
From: Daniel Vetter daniel.vet...@ffwll.ch
This does two little changes:
- Add an alignment parameter for evict_something. It's not really great to
whack a carefully sized hole into the gtt with the wrong alignment.
Especially since the fallback path is a full evict.
- With the inactive
The eviction code is the gnarly underbelly of memory management, and is
clearer if kept separated from the normal domain management in GEM.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_drv.h |6
the CPU objects from casual eviction,
preferring to keep the GPU active for as long as possible.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
On Fri, 02 Jul 2010 11:54:44 -0400, Keith Packard kei...@keithp.com wrote:
On Fri, 02 Jul 2010 09:24:07 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This looks like the responsibility of miCloseScreen(). Are we failing to
chain up properly?
I don't think miCloseScreen
the impact of this should be slight as on i965 we should be using a
tiled frontbuffer for anything up to a 4096x4096 display.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915
performing asynchronous flips.)
Note the impact of this should be slight as on i965 we should be using a
tiled frontbuffer for anything up to a 4096x4096 display.
v2: compilation fixes and note that the docs do not exclude the G35 from
the extra alignment.
Signed-off-by: Chris Wilson ch...@chris
When trying to keep track of features between the kernel, the 2D driver,
mesa and the specs, it helps to list any other name by which the device
is referred to.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.c | 52
On Mon, 5 Jul 2010 18:01:47 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
When trying to keep track of features between the kernel, the 2D driver,
mesa and the specs, it helps to list any other name by which the device
is referred to.
In adding this list it became apparent that the 2D
If we fail to correctly setup the mapping for an object, make sure that
we nullify the pointer within the object after tearing down. Otherwise,
we may later attempt to reuse the invalid pointer...
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
---
drivers/gpu/drm/i915
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_overlay.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 88a9ee8..5ba3b48 100644
--- a/drivers/gpu/drm
We already checked just a couple of lines above that we have found a
fixed_panel_mode for the LVDS, so remove the surplus check.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lvds.c | 32 +++-
1 files changed, 15 insertions
insertions(+), 194 deletions(-)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_lvds.c | 322 +++--
1 files changed, 128 insertions(+), 194 deletions(-)
diff --git a/drivers/gpu/drm/i915
Reduce the number of variables used and improve readability by scoping.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915
initialize the framebuffer.
Excellent, as you have managed to reproduce this with a minimal kernel,
can you do a bisect between 2.6.33.16 and 2.6.33.6 and see which patch
causes the regression? It should only take a couple of hours. My bet is
one of the Arrandale enabling patches...
--
Chris Wilson
From: Zhao Yakui yakui.z...@intel.com
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
---
drivers/gpu/drm/i915/intel_dp.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_sdvo.c | 34 +++---
1 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index ba50755..a30d751
Reference:
Bug 28634 - missing TV parameter Flicker Filter
https://bugs.freedesktop.org/show_bug.cgi?id=28634
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_sdvo.c | 644 ++--
drivers/gpu/drm/i915/intel_sdvo_regs.h
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_display.c | 16 +++
drivers/gpu/drm/i915/intel_lvds.c| 70 --
3 files changed, 75 insertions(+), 13 deletions(-)
diff
,
but there's no direct rendering (seems to be disabled because DRI is
disabled because it runs only at depths 16 and 24) title bars on
gnome-terminal draw incorrectly.
Hmm, the render paths should work on 10bpc surfaces. Please do file bugs
for the failures.
--
Chris Wilson, Intel Open Source Technology
upon the various lists exposing us to memory
corruption.
I think this is the cause behind the use-after-free, such as
Bug 15664 - Graphics hang and kernel backtrace when starting Azureus
with Compiz enabled
https://bugzilla.kernel.org/show_bug.cgi?id=15664
Signed-off-by: Chris
reminded me that kernel space programming is never easy.
We cannot simply spin to clear the pending signal and so must deferred
the freeing of the object until later.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
---
drivers/gpu/drm/i915/i915_drv.h |8
reminded me that kernel space programming is never easy.
We cannot simply spin to clear the pending signal and so must deferred
the freeing of the object until later.
v3: Run from the top level retire requests.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
---
drivers
-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
Reviewed-by: Daniel Vetter dan...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |8 +
drivers/gpu/drm/i915/i915_gem.c | 57 --
2 files changed, 50 insertions(+), 15 deletions(-)
diff --git
against Eric's for-linus tree.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
Cc: Daniel Vetter dan...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/i915_drv.h | 11 -
drivers/gpu/drm/i915/i915_gem.c | 96
of two evils, since in order to recover from the hung
GPU we need to completely reset it, those pending writes should
never happen.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff
handle reference.
This brings i915_gem_object_create_ioctl() into line with
drm_gem_open_ioctl()
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
dithering. Temporal dithering looks bad and is perceived as a
flicker.
Fixes:
Bug 29248 - [Arrandale] Annoying flicker on internal panel, goes away
after suspend to RAM
https://bugs.freedesktop.org/show_bug.cgi?id=29248
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
From memory, I think this is just a bit of idiocacy in the driver
inappropriately using a GL type, i.e. for a variable unconnected with
any of the GL interfaces.
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx
that it was based on
drm-intel-next and so not ready to be pushed.
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
of this change. :)
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 02 Aug 2010 12:16:16 +0200, Alexey Fisher bug-tr...@fisher-privat.net
wrote:
Hallo all,
i have regression coused by this patch:
commit b9421ae8f30958deea98d71477b4a77a066856b4
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Jul 19 21:46:08 2010 +0100
drm/i915: Warn if we
As we already have appropriate debug and warnings when we activate and
deactivate the self-refresh FIFO, having a further INFO is just annoying.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 files changed, 3 insertions(+), 8
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c |7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index
The fair-eviction patches rebased upon drm-(core|intel)-next.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
This will be used by the eviction logic to maintain fairness between the
rings.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |3 +-
drivers/gpu/drm/i915/i915_gem.c |2 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 46
scan stuff we need to evict more that one object, so
move the unbind call into the helper function that scans for the object
to be evicted, too. And adjust its name.
No functional changes in this patch, just preparation.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Chris
The eviction code is the gnarly underbelly of memory management, and is
clearer if kept separated from the normal domain management in GEM.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_drv.h |6
the CPU objects from casual eviction,
preferring to keep the GPU active for as long as possible.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
This debugging trace was useful for finding the fbcon regression on
i965, and it may prove useful again in future.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm
This patchset touches virtually all of i915/intel*.c simply to subclass
encoders and connectors, then cleans up intel_sdvo in order to add a few
more TV properties.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
This property is slightly unusual in that it is a boolean and so has no
GET_MAX command.
Reference:
Bug 28636 - missing TV parameter Dot Crawl freeze
https://bugs.freedesktop.org/show_bug.cgi?id=28636
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915
Make the code that tiny bit clearer by reducing the pointer dance.
2 files changed, 130 insertions(+), 147 deletions(-)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_drv.h |1 -
drivers/gpu/drm/i915/intel_sdvo.c | 276
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_sdvo.c | 40 +++-
1 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 0e03f40..c668010
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_sdvo.c | 34 +++---
1 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 5cc83e5..0e03f40
This avoids the excess flush and requests on idle rings (and spamming
the debug log ;-)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/i915_gem.c | 26 --
2 files changed, 19 insertions(+), 10
and misleading attempt at protection.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 58 +---
drivers/gpu/drm/i915/i915_drv.h |2 -
drivers/gpu/drm/i915/i915_gem.c | 35 +--
drivers/gpu/drm
-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/drm_gem.c |2 +-
drivers/gpu/drm/i915/i915_gem.c| 26 +-
drivers/gpu/drm/i915/i915_gem_tiling.c |4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.c |8
drivers/gpu/drm
Directly read the GTT mapping for the contents of the batch buffers
rather than relying on possibly stale CPU caches. Also for completeness
scan the flushing/inactive lists for the current buffers - we are
collecting error state after all.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
This is required should we ever attempt to use an io-mapping where
KM_USER0 is verboten, such as inside an IRQ context.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/i915_gem.c|9 +
drivers/gpu/drm/i915
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_sdvo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index ccf6574..234c856 100644
--- a/drivers/gpu/drm/i915
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_display.c | 16 +++
drivers/gpu/drm/i915/intel_lvds.c| 70 --
3 files changed, 75 insertions(+), 13 deletions(-)
diff
The goal here is to simplify the ringbuffer emission so that we can avoid
the function call overhead when writing into the ringbuffer.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
As the function has been reduced to a store plus increment, the body is
now smaller than the call so inline it.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c |8
drivers/gpu/drm/i915/intel_ringbuffer.h | 12 ++--
2 files
Using dev_priv__ avoids sparse complaining about shadowed variables in
the *LP_RING() macros.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915
The tail is quadword aligned, so we can add two MI_NOOP as a time.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu
Writing to the DSPBASE register triggers the double-buffered update to
all the control registers, so always write it last in the update
sequence.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |6 ++
1 files changed, 2 insertions(+), 4
Incorporates a similar patch by Daniel Vetter, the alteration being to
report the current busy state after retiring.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc : Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 40 +-
1
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c |3 +
drivers/gpu/drm/i915/i915_drv.h | 10 +++-
drivers/gpu/drm/i915/i915_irq.c |3 +
drivers/gpu/drm/i915/intel_overlay.c | 85 ++
4 files changed
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4cf2789..f599d77 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
less scary ;)
Hmm, I was aiming for retiring order, I may have missed. But yes, the true
goal is for this to be clear from the code, and here my preference was for
unrolling the loop so that the order was apparent. Obviously I have failed
on one or both accounts.
--
Chris Wilson, Intel Open
v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_display.c | 16
Within i915_opregion.c there are two blocks of semantically identical
ASLE response codes defined. Only one of those matches the ACPI IGD
OpRegion Specification 0.1, use those.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Matthew Garrett mj...@srcf.ucam.org
---
drivers/gpu/drm/i915
The cleanup path for early abort failed to nullify the gem_buffer. The
likely consequence of this is zero, since a failure here should mean
aborting the module load.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 31
and order of eviction through the use
of comments and macros.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter dan...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/i915_gem_evict.c | 276 +
2 files changed
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9814182..5cae58a 100644
--- a/drivers/gpu/drm
Add a new macro, wait_for, to simplify the act of waiting on a register
to change state. wait_for() takes three arguments, the condition to
inspect on every loop, the maximum amount of time to wait and whether to
yield the cpu for a length of time after each check.
Signed-off-by: Chris Wilson ch
The FBC is dependent upon a few details of the framebuffer so it is
required to be updated within set_base(), so remove the redundant call
from mode_set().
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |3 ---
1 files changed, 0 insertions
On Fri, 6 Aug 2010 20:58:30 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Aug 06, 2010 at 12:25:45PM +0100, Chris Wilson wrote:
+ return i915_gem_evict_everything(dev);
I think this should be equivalent to
return -ENOMEM;
Yes, we could return -ENOSPC and then do_execbuffer
In order to properly track bound objects, they need to exist on one of
the inactive/active lists or be pinned. As this is a requirement, do the
work inside i915_gem_bind_to_gtt() rather than dotted around the
callsites.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm
On Fri, 06 Aug 2010 14:21:59 -0700, Eric Anholt e...@anholt.net wrote:
On Tue, 3 Aug 2010 08:12:12 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
At the moment, we have a habit of occasionally performing a double dpms
on. This confuses the FDI link training performed on a dpms
1 - 100 of 40210 matches
Mail list logo
