| Age | Commit message (Collapse) | Author |
|---|
|
In i915_gem_object_wait_rendering, if the object write domain is being
written by the GPU, the appropriate flushing commands are written to the
device and an additional request queued to mark that flush. Finally, the
function blocks on that new request.
The bug was that the write_domain in the object was cleared before the
function blocked.
If the wait is interrupted by a signal, the flushing commands may still be
pending. With the current write_domain information lost, the restarted
syscall will drop right through the write_domain test as that value was
lost, and so the function will not block at all. Oops.
Fixed by simply moving the write_domain clear until after the wait_request
succeeds. Note that the restarted system call will generate an additional
flush sequence and request, but that should be 'harmless', aside from a
slight performance impact.
Someday we'll track flushing more accurately and clear write_domains more
efficiently, but for now, this should suffice.
This bug was discovered in the 2d gem development by running x11perf
-copypixwin500 and noticing that the window got cleared accidentally.
|
|
|
|
This reverts commit 3ad8db2071d30c198403e605f2726fc5c3e46bfd.
We ended up not needing that namespace, and I'd rather not have the churn
for producing diffs.
|
|
|
|
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
Main fix is an oops that was triggered by the gtt pwrite path when we don't
have the gtt initialized. Also, settle on -EBADF for "bad object handle",
and -EINVAL for "reading/writing beyond object boundary".
|
|
This is around 3x or so speedup, since we would read wide rows at a time, and
clflush each tile 8 times as a result. We'll want code related to this anyway
when we do fault-based per-page clflushing for sw fallbacks.
|
|
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=16799 .
|
|
this lets us debug the X server through xkb startup.
Not sure what the correct answer is, probably X needs to drop
the lock when execing stuff, with input hotplug it can get
xkb stuff at any time I believe.
|
|
Fixes an oops in fbotexture from walking off the end of the page list.
|
|
This increases overhead for the large-readpixels case due to the repeated
page cache accessing, but greatly reduces overhead for the small-readpixels
case.
|
|
These will be covered by the fence, while pread/pwrite are supposed to be
CPU-perspective writes, with manual detiling done by the client.
|
|
|
|
This is in pci.h in the fixed patch to the kernel.
|
|
This requires an updated 2D driver to not try to set it up as well.
|
|
I incorrectly thought it was obsolete.
|
|
The driver code that caused this is no longer necessary and has been dropped.
|
|
Remove some dead/obsolete code and make drm_update_vblank_count() static.
|
|
Caused drm_update_vblank_count() not to do its thing when called from
drm_modeset_ctl() -> drm_vblank_get().
The vblank functionality no longer needs to be suspended during a modeset, so
rename the field to vblank_inmodeset.
|
|
In my last push I forgot to convert users of drm_update_vblank_count
over to drm_vblank_get/put, since that's where any interrupt off->on
update accounting is done now. Since the modeset ioctl did something
similar (an open coded update of the counter) convert it over to using
get/put too, which saves us from having to deal with every combination
of interrupt off & on between calls.
|
|
On some distros missing prototypes cause kernel builds to fail. These
are hack to make the code build.
|
|
|
|
The current code uses the hw vblank counter exclusively, which can lead
to wakeups during the active period rather than during the vblank period
if the hw counter counts displayed frames rather than vblank periods.
This change coverts the code over to using the counter while interrupts
are enabled, fixing that issue. It also includes a couple of related
changes: one to not enable the new enable/disable behavior until the
modeset ioctl is called (to preserve old client behavior) and another to
account for lost events due to mode setting with the new counter scheme.
BSD will require similar changes to its drm_irq.c code, but they should
be straightforward.
|
|
modifications to make it work correctly on my test hardware (altered the
backlight write function, made it enable the legacy backlight controller
interrupts on mobile hardware, sorted the interrupt function so we don't
get an excessive number of vblank interrupts). This lets the backlight
keys on my T61 work properly, though there's a 750msec or so delay
between the request and the brightness actually changing - this sounds
awfully like the hardware spinning waiting for a status flag to become
ready, but as far as I can tell they're all set correctly. If anyone can
figure out what's wrong here, it'd be nice to know.
Some of the functions are still stubs and just tell the hardware that
the request was successful. These can be filled in as kernel modesetting
gets integrated. I think it's worth getting this in anyway, since it's
required for backlight control to work properly on some new platforms.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
|
|
|
|
|
|
One of our systems has been returning 0xffffffff from all MCHBAR reads, which
means we'll need to figure out why, or add an alternate detection method.
|
|
Various chips have exciting interactions between the CPU and the GPU's
different ways of accessing interleaved memory, so we need some kernel
assistance in determining how it works.
Only fully tested on GM965 so far.
|
|
|
|
|
|
This reverts commit 727d4f1d1667e43b3558bd5f6ed6dc2cd9c29401, somehow git
deleted the symlink and replaced it with the file.
|
|
When scheduled swaps occur, we need to blit between front & back buffers. If
the buffers are tiled, we need to set the appropriate XY_SRC_COPY tile bit, but
only on 965 chips, since it will cause corruption on pre-965 (e.g. 945).
Bug reported by and fix tested by Tomas Janousek <tomi@nomi.cz>.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
On 9xx chips, bus mastering needs to be enabled at resume time for much of the
chip to function. With this patch, vblank interrupts will work as expected
on resume, along with other chip functions. Fixes kernel bugzilla #10844.
Signed-off-by: Jie Luo <clotho67@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
Leftover dev_priv from the move of the suspend/resume code into shared-core.
|
|
It would be nice if one day the DRM driver was the canonical source for
register definitions and core macros. To that end, this patch cleans things up
quite a bit, removing redundant definitions (some with different names
referring to the same register) and generally tidying up the header file.
|
|
|
|
A mis-spelled config option (was it spelled that way in the past?)
eliminated kmap_atomic_prot_pfn from core DRM.
|
|
Clean up queues, free objects. On the next entervt, unmark the hardware to
let the user try again (presumably after resetting the chip). Someday we'll
automatically recover...
|
|
Pin/copy_from_user/unpin through the GTT to eliminate clflush costs.
Benchmarks say this helps quite a bit.
|
|
|
|
This tracks most of the interrupt-related status, including the
interrupt registers in the chip and the sequence number variables.
|
|
|
|
While waiting for the hardware to idle on leavevt or lastclose, poll
for the sync sequence number instead of waiting for an interrupt. This
allows the code to bail if the hardware hangs for some reason. Also, this
avoids issues with signals as the exisiting wait function is interruptible.
|
|
This adds gem_active, gem_flushing, gem_inactive, gem_request and gem_seqno
entries to monitor gem operation and help debug issues.
|
|
This allows device drivers to add proc files
|
