Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 5月, 2009 1 次提交
  3. 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
  5. 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
  7. 23 5月, 2009 5 次提交
  9. 21 5月, 2009 1 次提交
  11. 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
  13. 16 5月, 2009 1 次提交
  15. 15 5月, 2009 9 次提交
  17. 13 5月, 2009 1 次提交
  19. 06 5月, 2009 1 次提交
  21. 01 5月, 2009 2 次提交
  23. 24 4月, 2009 7 次提交
  25. 22 4月, 2009 3 次提交
  27. 20 4月, 2009 3 次提交