Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 3月, 2012 1 次提交
  3. 19 3月, 2012 7 次提交
  5. 03 3月, 2012 2 次提交
  7. 02 3月, 2012 2 次提交
  9. 01 3月, 2012 8 次提交
  11. 28 2月, 2012 5 次提交
  13. 27 2月, 2012 3 次提交
  15. 17 2月, 2012 2 次提交
    • D
      drm: add some caps for userspace to discover more info for dumb KMS driver (v2) · 019d96cb
      由 Dave Airlie 提交于 
      For the simple KMS driver case we need some more info about what the preferred
depth and if a shadow framebuffer is preferred.

I've only added this for intel/radeon which support the dumb ioctls so far.

If you need something really fancy you should be writing a real X.org driver.

v2: drop cursor information, just return an error from the cursor ioctls
and we can make userspace fallback to sw cursor in that case, cursor
info was getting too messy, best to start smaller.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      019d96cb
    • 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
  17. 16 2月, 2012 2 次提交
  19. 15 2月, 2012 5 次提交
    • C
      drm/i915/lvds: Always use the presence pin for LVDS on PCH · f3cfcba6
      由 Chris Wilson 提交于 
      With the introduction of the PCH, we gained an LVDS presence pin but we
continued to use the existing logic that asserted that LVDS was only
supported on certain mobile chipsets. However, there are desktop
IronLake systems with LVDS attached which we fail to detect. So for PCH,
trust the LVDS presence pin and quirk all the lying manufacturers.
Tested-by: NDaniel Woff <wolff.daniel@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43171Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f3cfcba6
    • C
      drm/i915: Record the position of the request upon error · ee4f42b1
      由 Chris Wilson 提交于 
      So that we can tally the request against the command sequence in the
ringbuffer, or merely jump to the interesting locations.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ee4f42b1
    • C
      drm/i915: Record the in-flight requests at the time of a hang · 52d39a21
      由 Chris Wilson 提交于 
      Being able to tally the list of outstanding requests with the sequence
of commands in the ringbuffer is often useful evidence with respect to
driver corruption.

Note that since this is the umpteenth per-ring data structure to be added
to the error state, I've coallesced the nearby loops (the ringbuffer and
batchbuffer) into a single structure along with the list of requests.  A
later task would be to refactor the ring register state into the same
structure.

v2: Fix pretty printing of requests so that they are parsed correctly by
intel_error_decode and use the 0x%08x format for seqno for consistency
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      52d39a21
    • C
      drm/i915: Record the tail at each request and use it to estimate the head · a71d8d94
      由 Chris Wilson 提交于 
      By recording the location of every request in the ringbuffer, we know
that in order to retire the request the GPU must have finished reading
it and so the GPU head is now beyond the tail of the request. We can
therefore provide a conservative estimate of where the GPU is reading
from in order to avoid having to read back the ring buffer registers
when polling for space upon starting a new write into the ringbuffer.

A secondary effect is that this allows us to convert
intel_ring_buffer_wait() to use i915_wait_request() and so consolidate
upon the single function to handle the complicated task of waiting upon
the GPU. A necessary precaution is that we need to make that wait
uninterruptible to match the existing conditions as all the callers of
intel_ring_begin() have not been audited to handle ERESTARTSYS
correctly.

By using a conservative estimate for the head, and always processing all
outstanding requests first, we prevent a race condition between using
the estimate and direct reads of I915_RING_HEAD which could result in
the value of the head going backwards, and the tail overflowing once
again. We are also careful to mark any request that we skip over in
order to free space in ring as consumed which provides a
self-consistency check.

Given sufficient abuse, such as a set of unthrottled GPU bound
cairo-traces, avoiding the use of I915_RING_HEAD gives a 10-20% boost on
Sandy Bridge (i5-2520m):
  firefox-paintball  18927ms -> 15646ms: 1.21x speedup
  firefox-fishtank   12563ms -> 11278ms: 1.11x speedup
which is a mild consolation for the performance those traces achieved from
exploiting the buggy autoreported head.

v2: Add a few more comments and make request->tail a conservative
estimate as suggested by Daniel Vetter.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: resolve conflicts with retirement defering and the lack of
the autoreport head removal (that will go in through -fixes).]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a71d8d94
    • P
      drm/i915: add missing SDVO bits for interlaced modes on ILK · 7c26e5c6
      由 Paulo Zanoni 提交于 
      This was pointed by Jesse Barnes. The code now seems to follow the
specification but I don't have an SDVO device to really test this.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7c26e5c6
  21. 14 2月, 2012 3 次提交