Incrementing the reference count on all objects walked when searching
for space in the aperture is a non-neglible amount of overhead. In fact,
we only need to hold on to a reference for objects that we will evict,
so we can therefore delay the referencing until we find a suitable hole
and only add those objects that fall inside.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When setting overlay position with x<0, it will divide 0 and make drm
driver crash.
Signed-off-by: Hai Lan <hai.lan@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Manually resolve the conflict between the new enum drm property
helpers in drm-next and the new "force-dvi" option that the "audio" output
property gained in drm-intel-next.
While resolving this conflict, switch the new drm_prop_enum_list to
use the newly introduced enum defines instead of magic values.
Conflicts:
drivers/gpu/drm/i915/intel_modes.c
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If accel is not working many subsystem such as the ib pool might not be
initialized properly that can lead to segfault inside kernel when cs
ioctl is call with non working acceleration. To avoid this make sure
the accel working flag is false when an error in GPU startup happen and
return EBUSY from cs ioctl if accel is not working.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel:
drm/i915: do not enable RC6p on Sandy Bridge
drm/i915: gen7: Disable the RHWO optimization as it can cause GPU hangs.
drm/i915: gen7: work around a system hang on IVB
drm/i915: gen7: Implement an L3 caching workaround.
drm/i915: gen7: implement rczunit workaround
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: Dave Airlie <airlied@redhat.com>
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: Dave Airlie <airlied@redhat.com>
with vblank_refcount = 1, there was the case that drm_vblank_put
is called by specific page flip function so this patch fixes the
issue.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
if one process is terminated by ctrl-c while two processes are
using pageflip feature then for last pageflip event,
user can't get poll from kernel side so this patch fixes the problem.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyoungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With base on latest findings, RC6p seems to be respondible for RC6-related
issues on Sandy Bridge platform. To work-around those issues, the previous
solution was to completely disable RC6 on Sandy Bridge for the past few
releases, even if plain RC6 was not giving any issues.
What this patch does is preventing RC6p from being enabled on Sandy Bridge
even if users enable RC6 via a kernel parameter. So it won't change the
defaults in any way, but will ensure that if users do enable RC6 manually
it won't break their machines by enabling this extra state.
Proper fix for this (enabling specific RC6 states according to the GPU
generation) were proposed for the -next kernel, but we are too late in the
release process now to pick such changes.
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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: Daniel Woff <wolff.daniel@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43171
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So that we can tally the request against the command sequence in the
ringbuffer, or merely jump to the interesting locations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Chris 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: Daniel Vetter <daniel.vetter@ffwll.ch>
with vblank_refcount = 1, there was the case that drm_vblank_put
is called by specific page flip function so this patch fixes the
issue.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
if one process is terminated by ctrl-c while two processes are
using pageflip feature then for last pageflip event,
user can't get poll from kernel side so this patch fixes the problem.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyoungmin Park <kyungmin.park@samsung.com>
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel: (29 commits)
drm/i915: Handle unmappable buffers during error state capture
drm/i915: rewrite shmem_pread_slow to use copy_to_user
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
drm/i915: fall through pwrite_gtt_slow to the shmem slow path
drm/i915: add debugfs file for swizzling information
drm/i915: fix swizzle detection for gen3
drm/i915: Remove the upper limit on the bo size for mapping into the CPU domain
drm/i915: add per-ring fault reg to error_state
drm/i915: reject GTT domain in relocations
drm/i915: remove the i915_batchbuffer_info debugfs file
drm/i915: capture error_state also for stuck rings
drm/i915: refactor debugfs create functions
drm/i915: refactor debugfs open function
drm/i915: don't trash the gtt when running out of fences
drm/i915: Separate fence pin counting from normal bind pin counting
drm/i915/ringbuffer: kill snb blt workaround
drm/i915: collect more per ring error state
drm/i915: refactor ring error state capture to use arrays
drm/i915: switch ring->id to be a real id
drm/i915: set AUD_CONFIG N_value_index for DisplayPort
...
- Add missing DFP6 connection state handling
- crtc routing bits not used on DCE4+
Noticed by sylware on phoronix.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
GMBUS has several ports and each has it's own corresponding
I2C adpater. When multiple I2C adapters call gmbus_xfer() at
the same time there is a race condition in using the underlying
GMBUS controller. Fixing this by adding a mutex lock when calling
gmbus_xfer().
v2: Moved gmbus_mutex below intel_gmbus and added comments.
Rebased to drm-intel-next-queued.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
[danvet: Shortened the gmbus_mutex comment a bit and add the patch
revision comment to the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When HDMI-DVI converter is used, it's not only necessary to turn off
audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
the DVI mode is mainly tied to audio functionality from end user POV,
add a new "force-dvi" audio mode:
xrandr --output HDMI1 --set audio force-dvi
Note that most users won't need to set this and happily rely on the EDID
based DVI auto detection.
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch replaces the locking from the downclock routines with an assert
to ensure the registers are indeed unlocked. Without this patch, pre-SNB
devices would lock the registers when downclocking which would cause a
WARNING on suspend/resume with downclocking enabled.
Note: To hit this bug, you need to have lvds downclocking enabled.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
