Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 27 3月, 2012 3 次提交
  3. 21 3月, 2012 1 次提交
  5. 19 3月, 2012 3 次提交
  7. 17 2月, 2012 1 次提交
    • D
      drm: move pci bus master enable into driver. · 466e69b8
      由 Dave Airlie 提交于 
      The current enabling of bus mastering in the drm midlayer allows a large
race condition under kexec. When a kexec'ed kernel re-enables bus mastering
for the GPU, previously setup dma blocks may cause writes to random pieces
of memory. On radeon the writeback mechanism can cause these sorts of issues.

This patch doesn't fix the problem, but it moves the bus master enable under
the individual drivers control so they can move enabling it until later in
their load cycle and close the race.

Fix for radeon kms driver will be in a follow-up patch.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      466e69b8
  9. 13 2月, 2012 1 次提交
  11. 10 2月, 2012 2 次提交
  13. 09 2月, 2012 1 次提交
    • D
      drm/i915: swizzling support for snb/ivb · f691e2f4
      由 Daniel Vetter 提交于 
      We have to do this manually. Somebody had a Great Idea.

I've measured speed-ups just a few percent above the noise level
(below 5% for the best case), but no slowdows. Chris Wilson measured
quite a bit more (10-20% above the usual snb variance) on a more
recent and better tuned version of sna, but also recorded a few
slow-downs on benchmarks know for uglier amounts of snb-induced
variance.

v2: Incorporate Ben Widawsky's preliminary review comments and
elaborate a bit about the performance impact in the changelog.

v3: Add a comment as to why we don't need to check the 3rd memory
channel.

v4: Fixup whitespace.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f691e2f4
  15. 26 1月, 2012 1 次提交
  17. 20 1月, 2012 1 次提交
    • D
      drm/i915: protect force_wake_(get|put) with the gt_lock · 9f1f46a4
      由 Daniel Vetter 提交于 
      The problem this patch solves is that the forcewake accounting
necessary for register reads is protected by dev->struct_mutex. But the
hangcheck and error_capture code need to access registers without
grabbing this mutex because we hold it while waiting for the gpu.
So a new lock is required. Because currently the error_state capture
is called from the error irq handler and the hangcheck code runs from
a timer, it needs to be an irqsafe spinlock (note that the registers
used by the irq handler (neglecting the error handling part) only uses
registers that don't need the forcewake dance).

We could tune this down to a normal spinlock when we rework the
error_state capture and hangcheck code to run from a workqueue.  But
we don't have any read in a fastpath that needs forcewake, so I've
decided to not care much about overhead.

This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
snb on recent kernels - something must have slightly changed the
timings. On previous kernels it only trigger a WARN about the broken
locking.

v2: Drop the previous patch for the register writes.

v3: Improve the commit message per Chris Wilson's suggestions.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      9f1f46a4
  19. 18 1月, 2012 2 次提交
  21. 04 1月, 2012 2 次提交
    • E
      drm/i915: Add support for resetting the SO write pointers on gen7. · ae662d31
      由 Eric Anholt 提交于 
      These registers are automatically incremented by the hardware during
transform feedback to track where the next streamed vertex output
should go.  Unlike the previous generation, which had a packet for
setting the corresponding registers to a defined value, gen7 only has
MI_LOAD_REGISTER_IMM to do so.  That's a secure packet (since it loads
an arbitrary register), so we need to do it from the kernel, and it
needs to be settable atomically with the batchbuffer execution so that
two clients doing transform feedback don't stomp on each others'
state.

Instead of building a more complicated interface involcing setting the
registers to a specific value, just set them to 0 when asked and
userland can tweak its pointers accordingly.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      ae662d31
    • J
      drm/i915: add color key support v4 · 8ea30864
      由 Jesse Barnes 提交于 
      Add new ioctls for getting and setting the current destination color
key.  This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.

v2: remove unnecessary mutex acquire/release around reg accesses
v3: add support for full color key management
v4: fix copy & paste bug in snb_get_colorkey
    don't bother checking min/max values against docs as the docs are likely
    wrong (how could we handle 10bpc surface formats?)
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      8ea30864
  23. 17 12月, 2011 1 次提交
  25. 01 11月, 2011 1 次提交
  27. 21 10月, 2011 1 次提交
  29. 20 9月, 2011 1 次提交
  31. 23 7月, 2011 1 次提交
    • K
      drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri · f3234706
      由 Keith Packard 提交于 
      Physically-addressed hardware status pages are initialized early in
the driver load process by i915_init_phys_hws. For UMS environments,
the ring structure is not initialized until the X server starts. At
that point, the entire ring structure is re-initialized with all new
values. Any values set in the ring structure (including
ring->status_page.page_addr) will be lost when the ring is
re-initialized.

This patch moves the initialization of the status_page.page_addr value
to intel_render_ring_init_dri.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Cc: stable@kernel.org
      f3234706
  33. 12 7月, 2011 1 次提交
    • K
      drm/i915: Clean up i915_driver_load failure path · a7b85d2a
      由 Keith Packard 提交于 
      i915_driver_load adds a write-combining MTRR region for the GTT
aperture to improve memory speeds through the aperture. If
i915_driver_load fails after this, it would not have cleaned up the
MTRR. This shouldn't cause any problems, except for consuming an MTRR
register. Still, it's best to clean up completely in the failure path,
which is easily done by calling mtrr_del if the mtrr was successfully
allocated.

i915_driver_load calls i915_gem_load which register
i915_gem_inactive_shrink. If i915_driver_load fails after calling
i915_gem_load, the shrinker will be left registered. When called, it
will access freed memory and crash. The fix is to unregister the shrinker in the
failure path using code duplicated from i915_driver_unload.

i915_driver_load also has some incorrect gotos in the error cleanup
paths:

 * After failing to initialize the GTT (which cannot happen, btw,
   intel_gtt_get returns a fixed (non-NULL) value), it tries to
   free the uninitialized WC IO mapping. Fixed this by changing the
   target from out_iomapfree to out_rmmap
Signed-off-by: NKeith Packard <keithp@keithp.com>
Tested-by: NLin Ming <ming.m.lin@intel.com>
      a7b85d2a
  35. 09 7月, 2011 1 次提交
  37. 30 6月, 2011 1 次提交
  39. 28 6月, 2011 2 次提交
  41. 14 5月, 2011 3 次提交
  43. 11 5月, 2011 3 次提交
  45. 27 4月, 2011 1 次提交
  47. 13 4月, 2011 1 次提交
  49. 09 4月, 2011 1 次提交
  51. 02 3月, 2011 3 次提交