On Sat, Aug 7, 2010 at 3:03 PM, Chris Wilson wrote:
> On Sat, 7 Aug 2010 09:31:10 -0600, Brian Hall wrote:
> > Is this a known problem with Intel KMS, or the xf86-video-intel driver?
> Just
> > trying to figure out if I need to file a bug report against the kernel or
> > xorg.
>
> No, that sounds
On Sat, 7 Aug 2010 09:31:10 -0600, Brian Hall wrote:
> Is this a known problem with Intel KMS, or the xf86-video-intel driver? Just
> trying to figure out if I need to file a bug report against the kernel or
> xorg.
No, that sounds very much like a bug. Worth checking to see if we can
power down
In order to reduce the penalty of fallbacks under memory pressure and to
avoid a potential immediate ping-pong of evicting a mmaped buffer, we
move the object to the tail of the inactive list when a page is freshly
faulted or the object is moved into the CPU domain.
We choose not to protect the CP
On Sat, Aug 07, 2010 at 11:01:25AM +0100, Chris Wilson wrote:
> In order to reduce the penalty of fallbacks under memory pressure and to
> avoid a potential immediate ping-pong of evicting a mmaped buffer, we
> move the object to the tail of the inactive list when a page is freshly
> faulted or the
Hi,
when I use kernel 2.6.35 my screen (connected via DVI) is not turned on.
Everything else works fine so I can ssh into the machine and safely shut it
down. This did not happen with 2.6.34. However I know that the issue is caused
by that commit
http://git.kernel.org/?p=linux/kernel/git/torva
I have a nice little Atom motherboard, the D510MO, with the integrated
Pineview graphics (GMA 3150). Everything works fine, but my LCD monitor
never turns off. "xset dpms force suspend" turns off the screen image, but
the monitor stays in "on mode", and after a few seconds the monitor says
"Cable n
If our watchdog fires and we see that the GPU is idle, but that we
are still waiting on an interrupt, forcibly wake-up the waiter.
i915_do_wait_request() should not be racy, yet there are persistent
reports that 945GM hangs whilst the GPU is idle. This implies that the
hardware is not quite as coh
If our watchdog fires and we see that the GPU is idle, but that we
are still waiting on an interrupt, forcibly wake-up the waiter.
i915_do_wait_request() should not be racy, yet there are persistent
reports that 945GM hangs whilst the GPU is idle. This implies that the
hardware is not quite as coh
On Fri, Aug 06, 2010 at 11:36:41PM +0100, Chris Wilson wrote:
> This looks like an interesting regression where KMS is unable to find the
> modes for the panel. Hmm, is it a panel, or another external display?
A panel (primary display) and an optional external display.
> You have a bug, please c
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
---
drivers/gpu/drm/i915/i915_gem.c | 11 -
From: Daniel Vetter
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 scan stuff we need to evic
Based in a large part upon Daniel Vetter's implementation and adapted
for handling multiple rings in a single pass.
This should lead to better gtt usage and fixes the page-fault-of-doom
triggered. The fairness is provided by scanning through the GTT space
amalgamating space in rendering order. As
Signed-off-by: Chris Wilson
---
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 1e31724..69cf724 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/
v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP.
Signed-off-by: Chris Wilson
Reviewed-by: Zhenyu Wang
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_display.c | 16 ++---
drivers/gpu/drm/i915/intel_dp.c
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
---
drivers/gpu/drm/i915/intel_display.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/dri
shmfs doesn't actually implement i_ops->truncate() so we were not
immedatiately releasing the backing purges when shrinking the gfx cache
under OOM. Instead use a combination of truncate_inode_pages() and
i_ops->truncate_range() as is used by shmem_delete_inode().
Signed-off-by: Chris Wilson
---
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 874ae30..07f1996 100644
--- a/drivers/gpu/drm/i915/intel_display.c
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.
v2: Upgrade failure messages to
Signed-off-by: Chris Wilson
---
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 0bf683d..2a32a7b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b
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
Acked-by: Matthew Garrett
---
drivers/gpu/drm/i915/i915_opregion.c | 10 +++---
1 fi
The i845 and i865 have a peculiarlity in that CURBASE is not the trigger
for the vsync update of the cursor registers but instead the
modification of that register is prohibited whilst the cursor is
enabled. Reorder the write sequence for CURPOS, CURCNTR and CURBASE on
i845 to i865 to match.
v2: R
i830 requires 32bpp cursors to be aligned to 16KB, so we have to expose
the alignment parameter to i915_gem_attach_phys_object().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |4 +++-
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
drivers/gpu/drm/i915/intel_
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
---
drivers/gpu/drm/i915/intel_display.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --gi
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
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +--
1 files changed, 1
Previously, we only remembered to update the watermarks for i9xx, and
incorrectly assumed that the crtc->enabled flag was valid at that point
in the dpms cycle.
Note that on my x201s this makes a SR bug on pipe 1 much easier to hit.
(Since before this patch when disabling pipe 0, we either didn't
In order to reduce the penalty of fallbacks under memory pressure and to
avoid a potential immediate ping-pong of evicting a mmaped buffer, we
move the object to the tail of the inactive list when a page is freshly
faulted or the object is moved into the CPU domain.
We choose not to protect the CP
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
---
drivers/gpu/drm/i915/i91
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
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_drv.h |6 +
drivers/gpu/drm/i915/i915_ge
This will be used by the eviction logic to maintain fairness between the
rings.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |3 +-
drivers/gpu/drm/i915/i915_gem.c |2 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 46 +-
driv
My outstanding patchset rebased upon Eric's drm-intel-next.
The first 5 implement LRU eviction. Daniel may want to paint it a
different colour, but is happy enough to do so later. :)
(7) improves reliability of error-state, but I still need to work on
improving i965+ error capture and make it a s
Hallo all,
i have some times on my primer desktop with Intel DG45ID board some sort
of flickering, it schort (1 second) and only half of the display. Same
sort of flickering i had with Bug 24314 - [945GME FBC] underruns
followed by freeze after resume with FBC enabled. The difference is - it
will
31 matches
Mail list logo
