Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 6月, 2009 8 次提交
  3. 05 6月, 2009 16 次提交
  5. 04 6月, 2009 3 次提交
    • E
      drm/i915: Change GEM throttling to be 20ms like the comment says. · b962442e
      由 Eric Anholt 提交于 
      keithp didn't like the original 20ms plan because a cooperative client could
be starved by an uncooperative client.  There may even have been problems
with cooperative clients versus cooperative clients.  So keithp changed
throttle to just wait for the second to last seqno emitted by that client.
It worked well, until we started getting more round-trips to the server
due to DRI2 -- the server throttles in BlockHandler, and so if you did more
than one round trip after finishing your frame, you'd end up unintentionally
syncing to the swap.

Fix this by keeping track of the client's requests, so the client can wait
when it has an outstanding request over 20ms old.  This should have
non-starving behavior, good behavior in the presence of restarts, and less
waiting.  Improves high-settings openarena performance on my GM45 by 50%.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b962442e
    • E
      drm/i915: Save/restore cursor state on suspend/resume. · 1fd1c624
      由 Eric Anholt 提交于 
      This may fix cursor corruption in X on resume, which would persist until
the cursor was hidden and then shown again.

V2: Also include the cursor control regs.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1fd1c624
    • E
      drm/i915: Remove a bad BUG_ON in the fence management code. · 0e7ddf7e
      由 Eric Anholt 提交于 
      This could be triggered by a gtt mapping fault on 965 that decides to
remove the fence from another object that happens to be active currently.
Since the other object doesn't rely on the fence reg for its execution, we
don't wait for it to finish.  We'll soon be not waiting on 915 most of the
time as well, so just drop the BUG_ON.
Signed-off-by: NEric Anholt <eric@anholt.net>
      0e7ddf7e
  7. 30 5月, 2009 1 次提交
  9. 28 5月, 2009 1 次提交
    • K
      i915: Set object to gtt domain when faulting it back in · 07f4f3e8
      由 Kristian Høgsberg 提交于 
      When a GEM object is evicted from the GTT we set it to the CPU domain,
as it might get swapped in and out or ever mmapped regularly.  If the
object is mmapped through the GTT it can still get evicted in this way
by other objects requiring GTT space.  When the GTT mapping is touched
again we fault it back into the GTT, but fail to set it back to the
GTT domain.  This means we fail to flush any cached CPU writes to the
pages backing the object which will then happen "eventually", typically
after we write to the page through the uncached GTT mapping.

[anholt: Note that userland does do a set_domain(GTT, GTT) when starting
to access the GTT mapping.  That covers getting the existing mapping of the
object synchronized if it's bound to the GTT.  But set_domain(GTT, GTT)
doesn't do anything if the object is currently unbound.  This fix covers the
transition to being bound for GTT mapping.]

Fixes glyph and other pixmap corruption during swapping.  fd.o bug #21790
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
      07f4f3e8
  11. 27 5月, 2009 3 次提交
    • E
      drm/i915: Apply a big hammer to 865 GEM object CPU cache flushing. · cfa16a0d
      由 Eric Anholt 提交于 
      On the 865, but not the 855, the clflush we do appears to not actually make
it out to the hardware all the time.  An easy way to safely reproduce was
X -retro, which would show that some of the blits involved in drawing the
lovely root weave didn't make it out to the hardware.  Those blits are 32
bytes each, and 1-2 would be missing at various points around the screen.
Other experimentation (doing more clflush, doing more AGP chipset flush,
poking at some more device registers to maybe trigger more flushing) didn't
help.  krh came up with the wbinvd as a way to successfully get all those
blits to appear.
Signed-off-by: NEric Anholt <eric@anholt.net>
      cfa16a0d
    • E
      drm/i915: Fix tiling pitch handling on 8xx. · e76a16de
      由 Eric Anholt 提交于 
      The pitch field is an exponent on pre-965, so we were rejecting buffers
on 8xx that we shouldn't have.  915 got lucky in that the largest legal
value happened to match (8KB / 512 = 0x10), but 8xx has a smaller tile width.
Additionally, we programmed that bad value into the register on 8xx, so the
only pitch that would work correctly was 4096 (512-1023 pixels), while others
would probably give bad rendering or hangs.
Signed-off-by: NEric Anholt <eric@anholt.net>

fd.o bug #20473.
      e76a16de
    • M
      drm/i915: Add support for VGA load detection (pre-945). · e4a5d54f
      由 Ma Ling 提交于 
      Two approaches for VGA detections: hot plug detection for 945G onwards
and load pipe detection for Pre-945G.  Load pipe detection will get one free
pipe, set border color as red and blue, then check CRT status by
swf register.  This is a sync-up with the 2D driver.
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
      e4a5d54f
  13. 23 5月, 2009 5 次提交
  15. 21 5月, 2009 1 次提交
  17. 20 5月, 2009 2 次提交
    • B
      drm: Round size of SHM maps to PAGE_SIZE · b6741377
      由 Benjamin Herrenschmidt 提交于 
      Currently, userspace can fail to obtain the SAREA mapping (among other
reasons) if it passes SAREA_MAX to drmAddMap without aligning it to the
page size. This breaks for example on PowerPC with 64K pages and radeon
despite the kernel radeon actually doing the right rouding in the first
place.

The way SAREA_MAX is defined with a bunch of ifdef's and duplicated
between libdrm and the X server is gross, ultimately it should be
retrieved by userspace from the kernel, but in the meantime, we have
plenty of existing userspace built with bad values that need to work.

This patch works around broken userspace by rounding the requested size
in drm_addmap_core() of any SHM map to the page size. Since the backing
memory for SHM maps is also allocated within addmap_core, there is no
danger of adjacent memory being exposed due to the increased map size.
The only side effect is that drivers that previously tried to create or
access SHM maps using a size < PAGE_SIZE and failed (getting -EINVAL),
will now succeed at the cost of a little bit more memory used if that
happens to be when the map is created.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b6741377
    • J
      drm/i915: allocate large pointer arrays with vmalloc · 8e7d2b2c
      由 Jesse Barnes 提交于 
      For awhile now, many of the GEM code paths have allocated page or
object arrays with the slab allocator.  This is nice and fast, but
won't work well if memory is fragmented, since the slab allocator works
with physically contiguous memory (i.e. order > 2 allocations are
likely to fail fairly early after booting and doing some work).

This patch works around the issue by falling back to vmalloc for
>PAGE_SIZE allocations.  This is ugly, but much less work than chaining
a bunch of pages together by hand (suprisingly there's not a bunch of
generic kernel helpers for this yet afaik).  vmalloc space is somewhat
precious on 32 bit kernels, but our allocations shouldn't be big enough
to cause problems, though they're routinely more than a page.

Note that this patch doesn't address the unchecked
alloc-based-on-ioctl-args in GEM; that needs to be fixed in a separate
patch.

Also, I've deliberately ignored the DRM's "area" junk.  I don't think
anyone actually uses it anymore and I'm hoping it gets ripped out soon.

[Updated: removed size arg to new free function.  We could unify the
free functions as well once the DRM mem tracking is ripped out.]

fd.o bug #20152 (part 1/3)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
      8e7d2b2c