Christian König [Thu, 23 Feb 2012 14:18:42 +0000 (15:18 +0100)]
drm/radeon: move ring syncing after bo validation
The function radeon_bo_list_validate can cause a
bo to move, resulting in a different sync_obj
and a dependency to wait for this move to finish.
Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Thu, 23 Feb 2012 22:53:41 +0000 (17:53 -0500)]
drm/radeon/kms: reorganize pm callbacks
tidy up the radeon_asic struct.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Thu, 23 Feb 2012 22:53:40 +0000 (17:53 -0500)]
drm/radeon/kms: reorganize page flip callbacks
tidy up the radeon_asic struct.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Thu, 23 Feb 2012 22:53:39 +0000 (17:53 -0500)]
drm/radeon/kms: reorganize hpd callbacks
tidy up the radeon_asic struct.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Thu, 23 Feb 2012 22:53:38 +0000 (17:53 -0500)]
drm/radeon/kms: add a radeon asic callback for mc idle
Required for future functionality.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Thu, 23 Feb 2012 22:53:37 +0000 (17:53 -0500)]
drm/radeon/kms: add wait_for_vblank asic callback
Required for future functionality.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Thu, 23 Feb 2012 14:11:53 +0000 (14:11 +0000)]
Merge tag 'drm-intel-next-2012-02-16-merge-resolved' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
* tag 'drm-intel-next-2012-02-16-merge-resolved' of git://people.freedesktop.org/~danvet/drm-intel: (45 commits)
Revert "drivers/gpu/drm/i915/intel_overlay.c needs seq_file.h"
drm/i915/lvds: Always use the presence pin for LVDS on PCH
drm/i915: Record the position of the request upon error
drm/i915: Record the in-flight requests at the time of a hang
drm/i915: Record the tail at each request and use it to estimate the head
drm/i915: add missing SDVO bits for interlaced modes on ILK
drm/i915: Fix race condition in accessing GMBUS
drm/i915: add a "force-dvi" HDMI audio mode
drm/i915: Don't lock panel registers when downclocking
drm/i915: fix up locking inconsistency around gem_do_init
drm/i915: enable forcewake voodoo also for gen6
drm/i915: fixup seqno allocation logic for lazy_request
drm/i915: outstanding_lazy_request is a u32
drm/i915: check gtfifodbg after possibly failed writes
drm/i915: catch gtfifo errors on forcewake_put
drm/i915: use gtfifodbg
drm/i915: set interlaced bits for TRANSCONF
drm/i915: fixup overlay checks for interlaced modes
drm/i915: allow interlaced mode output on the HDMI connector
drm/i915: allow interlaced mode output on the SDVO connector
...
Daniel Vetter [Thu, 23 Feb 2012 13:54:20 +0000 (14:54 +0100)]
Merge remote-tracking branch 'airlied/drm-next' into for-airlied
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>
Dave Airlie [Thu, 29 Sep 2011 15:20:42 +0000 (16:20 +0100)]
drm: add some caps for userspace to discover more info for dumb KMS driver (v2)
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.
Dave Airlie [Mon, 19 Dec 2011 11:15:29 +0000 (11:15 +0000)]
drm: move pci bus master enable into driver.
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.
Chris Wilson [Thu, 9 Feb 2012 09:35:53 +0000 (09:35 +0000)]
drm/i915/lvds: Always use the presence pin for LVDS on PCH
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>
Chris Wilson [Wed, 15 Feb 2012 11:25:37 +0000 (11:25 +0000)]
drm/i915: Record the in-flight requests at the time of a hang
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>
Chris Wilson [Wed, 15 Feb 2012 11:25:36 +0000 (11:25 +0000)]
drm/i915: Record the tail at each request and use it to estimate the head
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>
Dave Airlie [Tue, 14 Feb 2012 14:16:00 +0000 (14:16 +0000)]
Merge tag 'drm-intel-next-2012-02-07' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
* 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
...
Yufeng Shen [Mon, 13 Feb 2012 22:36:54 +0000 (17:36 -0500)]
drm/i915: Fix race condition in accessing GMBUS
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>
Wu Fengguang [Tue, 14 Feb 2012 03:45:36 +0000 (11:45 +0800)]
drm/i915: add a "force-dvi" HDMI audio mode
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>
Sean Paul [Mon, 13 Feb 2012 18:14:51 +0000 (13:14 -0500)]
drm/i915: Don't lock panel registers when downclocking
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>
Jerome Glisse [Fri, 16 Dec 2011 22:03:42 +0000 (17:03 -0500)]
drm/radeon: add support for evergreen/ni tiling informations v11
evergreen and northern island gpu needs more informations for 2D tiling
than previous r6xx/r7xx. Add field to tiling ioctl to allow userspace
to provide those.
The v8 cs checking change to track color view on r6xx/r7xx doesn't
affect old userspace as old userspace always emited 0 for this register.
v2 fix r6xx/r7xx 2D tiling computation
v3 fix r6xx/r7xx height align for untiled surface & add support for
tile split on evergreen and newer
v4 improve tiling debugging output
v5 fix tile split code for evergreen and newer
v6 set proper tile split for crtc register
v7 fix tile split limit value
v8 add COLOR_VIEW checking to r6xx/r7xx checker, add evergreen cs
checking, update safe reg for r600, evergreen and cayman.
Evergreen checking need some work around for stencil alignment
issues
v9 fix tile split value range, fix compressed texture handling and
mipmap calculation, allow evergreen check to be silencious in
front of current broken userspace (depth/stencil alignment issue)
v10 fix eg 3d texture and compressed texture, fix r600 depth array,
fix r600 color view computation, add support for evergreen stencil
split
v11 more verbose debugging in some case
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 13 Feb 2012 12:04:11 +0000 (12:04 +0000)]
Merge branch 'drm-vmware-next' into drm-core-next
* drm-vmware-next:
drm/vmwgfx: Bump driver minor
vmwgfx: Move function declaration to correct header
drm/vmwgfx: Treat out-of-range initial width and height as host errors
vmwgfx: Pick up the initial size from the width and height regs
vmwgfx: Add page flip support
vmwgfx: Pipe fence out of screen object dirty functions
vmwgfx: Make it possible to get fence from execbuf
vmwgfx: Clean up pending event references to struct drm_file objects on close
vmwgfx: Rework fence event action
vmwgfx: Move function declaration to correct header
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/vmwgfx: Treat out-of-range initial width and height as host errors
And assign the initial width and height to the minimum in that case.
Strange values (-1) from these registers have been reported by users.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Pick up the initial size from the width and height regs
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Pipe fence out of screen object dirty functions
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Make it possible to get fence from execbuf
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx: Clean up pending event references to struct drm_file objects on close
Pending events may have stale pointer references to struct drm_file objects
after a file has been closed, but before the event is supposed to be
attached to the drm file. Remove such events on file close.
Tested with "modetest".
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Fri, 27 Jan 2012 21:40:51 +0000 (22:40 +0100)]
drm/modes: do not enforce an odd vtotal for interlaced modes
CEA actually specifies an interlaced mode with even vtotal and
supplies a diagram showing how this is supposed to work.
Note that interlaced modes with an even vtotal seem to be a fairly
recent invention. All modelines lore I could dig up with googling says
that vtotal for interlaced modes _needs_ to be odd. But the even
modelines in CEA are not a spec-bug, there's a figure in CEA-861-E
called "Figure 5 Special Interlaced Video Format Timing (Even Vtotal)"
that explains how it's supposed to work. Furthermore intel Bspec
explicitly mentions that both odd and even interlaced vtotal are
supported (VTOTAL register in the south display engine of PCH split
chips).
Acked-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Thu, 26 Jan 2012 10:41:11 +0000 (11:41 +0100)]
drm/i915: fix up locking inconsistency around gem_do_init
The locking in our setup and teardown paths is rather arbitrary, but
generally we try to protect gem stuff with dev->struct_mutex. Further,
the ums/gem ioctl to setup gem _does_ take the look. So fix up this
benign inconsistency.
Notice while reading through code.
v2: Rebased on top of the ppgtt code.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 25 Jan 2012 13:04:00 +0000 (14:04 +0100)]
drm/i915: enable forcewake voodoo also for gen6
We still have reports of missed irqs even on Sandybridge with the
HWSTAM workaround in place. Testing by the bug reporter gets rid of
them with the forcewake voodoo and no HWSTAM writes.
Because I've slightly botched the rebasing I've left out the ACTHD
readback which is also required to get IVB working. Seems to still
work on the tester's machine, so I think we should go with the more
minmal approach on SNB. Especially since I've only found weak evidence
for holding forcewake while waiting for an interrupt to arrive, but
none for the ACTHD readback.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45332 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 25 Jan 2012 15:32:49 +0000 (16:32 +0100)]
drm/i915: fixup seqno allocation logic for lazy_request
Currently we reserve seqnos only when we emit the request to the ring
(by bumping dev_priv->next_seqno), but start using it much earlier for
ring->oustanding_lazy_request. When 2 threads compete for the gpu and
run on two different rings (e.g. ddx on blitter vs. compositor)
hilarity ensued, especially when we get constantly interrupted while
reserving buffers.
This patch fixes up the seqno reservation logic by moving it into
i915_gem_next_request_seqno. The ring->add_request functions now
superflously still return the new seqno through a pointer, that will
be refactored in the next patch.
Note that with this change we now unconditionally allocate a seqno,
even when ->add_request might fail because the rings are full and the
gpu died. But this does not open up a new can of worms because we can
already leave behind an outstanding_request_seqno if e.g. the caller
gets interrupted with a signal while stalling for the gpu in the
eviciton paths. And with the bugfix we only ever have one seqno
allocated per ring (and only that ring), so there are no ordering
issues with multiple outstanding seqnos on the same ring.
v2: Keep i915_gem_get_seqno (but move it to i915_gem.c) to make it
clear that we only have one seqno counter for all rings. Suggested by
Chris Wilson.
v3: As suggested by Chris Wilson use i915_gem_next_request_seqno
instead of ring->oustanding_lazy_request to make the follow-up
refactoring more clearly correct. Also improve the commit message
with issues discussed on irc.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 9 Feb 2012 09:15:20 +0000 (10:15 +0100)]
drm/i915: check gtfifodbg after possibly failed writes
If we don't have a sufficient number of free entries in the FIFO, we
proceed to do a write anyway. With this check we should have a clue if
that write actually failed or not.
After some discussion with Daniel Vetter regarding his original
complaint, we agreed upon this.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 9 Feb 2012 09:15:19 +0000 (10:15 +0100)]
drm/i915: catch gtfifo errors on forcewake_put
This is similar to a patch I wrote several months ago. It's been updated
for the new FORCEWAKE_MT. As recommended by Chris Wilson, use WARN()
instead of DRM_ERROR, so we can get a backtrace.
This shouldn't impact performance too much as the extra register read
can replace the POSTING_READ we had previously.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Thu, 9 Feb 2012 09:15:18 +0000 (10:15 +0100)]
drm/i915: use gtfifodbg
Add register definitions for GTFIFODBG, and clear it during init time to
make sure state is correct.
This register tells us if either a read, or a write occurred while the
fifo was full. It seems like bit 2 is an OR of bit 0 and bit 1, so we
check that as well, but the documents are not quite clear.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by (v1): Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 3 Feb 2012 19:47:15 +0000 (17:47 -0200)]
drm/i915: set interlaced bits for TRANSCONF
I'm not sure why they are needed (I didn't notice any difference in my
tests), but these bits are in our documentation and they are also set by
the Windows driver.
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>
Daniel Vetter [Sat, 28 Jan 2012 22:48:46 +0000 (23:48 +0100)]
drm/i915: fixup overlay checks for interlaced modes
The drm core _really_ likes to frob around with the crtc timings and
put halfed vertical timings (in fields) in there. Which confuses the
overlay code, resulting in it's refusal to display anything at the
lower half of an interlaced pipe.
Tested-by: Christopher Egert <cme3000@gmail.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Peter Ross [Sat, 28 Jan 2012 13:49:26 +0000 (14:49 +0100)]
drm/i915: allow interlaced mode output on the HDMI connector
Signed-off-by: Peter Ross <pross@xvid.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Peter Ross [Sat, 28 Jan 2012 13:49:25 +0000 (14:49 +0100)]
drm/i915: allow interlaced mode output on the SDVO connector
Signed-off-by: Peter Ross <pross@xvid.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:24 +0000 (14:49 +0100)]
drm/i915: correctly program the VSYNCSHIFT register
The hw seems to use this to correctly insert the required delay
before/after an even/odd interlaced field. This might also explain
why we need to substract 1 half-line from vtotal - if the hw just
adds the delay programmend in VSYNCSHIFT the total frame time would be
about that too long.
These registers seems to only exist on gen4 and later. For paranoia
also program it to 0 for progressive modes, but according to
documentation the hw should just ignore it in this case.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:23 +0000 (14:49 +0100)]
drm/i915: don't allow interlaced pipeconf on gen2
gen2 doesn't support it, so be a bit more paranoid and add a check to
ensure that we never ever set an unsupported interlaced bit.
Ensure that userspace can't set an interlaced mode by resetting
interlace_allowed for the crt on gen2. dvo and lvds are the only other
encoders that gen2 supports and these already disallow interlaced
modes.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:22 +0000 (14:49 +0100)]
drm/i915: fixup interlaced support on ilk+
According to Paulo Zanoni, this is what windows does.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:21 +0000 (14:49 +0100)]
drm/i915: fixup interlaced vertical timings confusion, part 2
According to bspec, we need to subtract an additional line from vtotal
for interlaced modes and vblank_end needs to equal vtotal. All other
timing fields do not need this special treatment, so kill it.
Bspec says that this is irrespective of whether the interlaced mode
has an odd or even vtotal, both modes are supported.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:20 +0000 (14:49 +0100)]
drm/i915: fixup interlaced vertical timings confusion, part 1
We have a pretty decent confusion about vertical timings of interlaced
modes. Peter Ross has written a patch that makes interlace modes work
on a lot more platforms/output combinations by doubling the vertical
timings.
The issue with that patch is that core drm _does_ support specifying
whether we want these vertical timings in fields or frames, we just
haven't managed to consistently use this facility. The relavant
function is drm_mode_set_crtcinfo, which fills in the crtc timing
information.
The first thing to note is that the drm core keeps interlaced modes in
frames, but displays modelines in fields. So when the crtc modeset
helper copies over the mode into adjusted_mode it will already contain
vertical timings in half-frames. The result is that the fixup code in
intel_crtc_mode_fixup doesn't actually do anything (in most cases at
least).
Now gen3+ natively supports interlaced modes and wants the vertical
timings in frames. Which is what sdvo already fixes up, at least under
some conditions.
There are a few other place that demand vertical timings in fields
but never actually deal with interlaced modes, so use frame timings
for consistency, too. These are:
- lvds panel,
- dvo encoders - dvo is the only way gen2 could support interlaced
mode, but currently we don't support any encoders that do.
- tv out - despite that the tv dac sends out an interlaced signal it
expects a progressive mode pipe configuration.
All these encoders enforce progressive modes by resetting
interlace_allowed.
Hence we always want crtc vertical timings in frames. Enforce this in
our crtc mode_fixup function and rip out any redudant timing
computations from the encoders' mode_fixup function.
v2-4: Adjust the vertical timings a bit.
v5: Split out the 'subtract-one for interlaced' fixes.
v6: Clarify issues around tv-out and gen2.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sat, 28 Jan 2012 13:49:19 +0000 (14:49 +0100)]
drm/i915: clean up interlaced pipeconf bit definitions
- Clarify which bits are for which chips.
- Note that gen2 can't do interlaced directly (only via dvo tv chips).
- Move the mask to the top to make it clearer how wide this field is.
- Add defintions for all possible values.
This patch doesn't change any code.
v2: Paulo Zanoni pointed out that the pixel doubling modes do no
longer exist on ivb.
Cc: Peter Ross <pross@xvid.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 10 Feb 2012 15:52:55 +0000 (16:52 +0100)]
Merge remote-tracking branch 'airlied/drm-fixes' into drm-intel-next-queued
Back-merge from drm-fixes into drm-intel-next to sort out two things:
- interlaced support: -fixes contains a bugfix to correctly clear
interlaced configuration bits in case the bios sets up an interlaced
mode and we want to set up the progressive mode (current kernels
don't support interlaced). The actual feature work to support
interlaced depends upon (and conflicts with) this bugfix.
- forcewake voodoo to workaround missed IRQ issues: -fixes only enabled
this for ivybridge, but some recent bug reports indicate that we
need this on Sandybridge, too. But in a slightly different flavour
and with other fixes and reworks on top. Additionally there are some
forcewake cleanup patches heading to -next that would conflict with
currrent -fixes.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Fri, 10 Feb 2012 08:35:19 +0000 (08:35 +0000)]
Merge branch 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux into drm-fixes
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux:
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drm/i915: no lvds quirk for AOpen MP45
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT
drm/i915:: Disable FBC on SandyBridge
Daniel Vetter [Thu, 9 Feb 2012 19:53:27 +0000 (20:53 +0100)]
drm/i915: enable ppgtt
We want to unconditionally enable ppgtt for two reasons:
- Windows uses this on snb and later.
- We need the basic hw support to work before we can think about real
per-process address spaces and other cool features we want.
But Chris Wilson was complaining all over irc and intel-gfx that this
will blow up if we don't have a module option to disable it. Hence add
one, to prevent this.
ppgtt support seems to slightly change the timings and make crashy
things slightly more or less crashy. Now in my testing and the testing
this got on troublesome snb machines, it seems to have improved things
only. But on ivb it makes quite a few crashes happen much more often,
see
Luckily Eugeni Dodonov seems to have a set of workarounds that fix
this issue.
v2: Don't try to enable ppgtt on pre-snb.
v3: Pimp commit message and make Chris Wilson less grumpy by adding a
module option.
v4: New try at making Chris Wilson happy.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:49 +0000 (17:15 +0100)]
drm/i915: ppgtt debugfs info
This was pretty usefull for debugging, might be useful for diagnosing
issues.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:48 +0000 (17:15 +0100)]
drm/i915: ppgtt register definitions
Split out for easier cross-checking of the boring pieces with bspec.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:47 +0000 (17:15 +0100)]
drm/i915: ppgtt binding/unbinding support
This adds support to bind/unbind objects and wires it up. Objects are
only put into the ppgtt when necessary, i.e. at execbuf time.
Objects are still unconditionally put into the global gtt.
v2: Kill the quick hack and explicitly pass cache_level to ppgtt_bind
like for the global gtt function. Noticed by Chris Wilson.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:46 +0000 (17:15 +0100)]
drm/i915: initialization/teardown for the aliasing ppgtt
This just adds the setup and teardown code for the ppgtt PDE and the
last-level pagetables, which are fixed for the entire lifetime, at
least for the moment.
v2: Kill the stray debug printk noted by and improve the pte
definitions as suggested by Chris Wilson.
v3: Clean up the aperture stealing code as noted by Ben Widawsky.
v4: Paint the init code in a more pleasing colour as suggest by Chris
Wilson.
v5: Explain the magic numbers noticed by Ben Widawsky.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:45 +0000 (17:15 +0100)]
agp/intel-gtt: export the gtt pagetable iomapping
We need this because ppgtt page directory entries need to be in the
global gtt pagetable.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 9 Feb 2012 16:15:44 +0000 (17:15 +0100)]
agp/intel-gtt: export the scratch page dma address
To implement a PPGTT for drm/i915 that fully aliases the GTT, we also
need to properly alias the scratch page.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 1 Feb 2012 21:26:45 +0000 (22:26 +0100)]
drm/i915: dump even more into the error_state
Chris Wilson and me have again stared at funny error states and it's
been pretty clear from the start that something was seriously amiss.
The seqnos last seen by the cpu were a few hundred behind those that
the gpu could have possibly emitted last before it died ...
Chris now tracked it down (hopefully, definit verdict's still out),
but in hindsight we'd have found the bug by simply dumping the cpu
side tracking of the ring head and tail registers.
Fix this and prevent an identical time-waster in the future.
Because the hangs always involved semaphores in one way or another,
we've tried to dump the mbox registers, but couldn't find any
inconsistencies. Still, dump them too.
Reviewed-and-wanted-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>
Sascha Hauer [Mon, 6 Feb 2012 09:58:19 +0000 (10:58 +0100)]
drm: do not set fb_info->pixmap fields
The drm drivers set the fb_info->pixmap fields without setting
fb_info->pixmap.addr. If this is not set the fb core will overwrite
these all fb_info->pixmap fields anyway, so there is not much point
in setting them in the first place.
[airlied: dropped nvidiafb piece - not mine]
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Tue, 31 Jan 2012 20:08:14 +0000 (21:08 +0100)]
drm/i915: s/DRM_ERROR/DRM_DEBUG in i915_gem_execbuffer.c
These are all user-trigerable, so tune down their loudness a notch.
For some of these we have i-g-t tests (because they prevent
newly-discovered bugs), without this patches running the test suite
leaves behind a dirty dmesg.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 31 Jan 2012 15:47:55 +0000 (16:47 +0100)]
drm/i915: consolidate swizzling control bit frobbing
On gen5 we also need to correctly set up swizzling in the display
scanout engine, but only there. Consolidate this into the same
function.
This has a small effect on ums setups - the kernel now also sets this
bit in addition to userspace setting it. Given that this code only
runs when userspace either can't (resume, gpu reset) or explicitly
won't(gem_init) touch the hw this shouldn't have an adverse effect.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Thu, 2 Feb 2012 08:58:12 +0000 (09:58 +0100)]
drm/i915: swizzling support for snb/ivb
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/intel: Fix initialization if startup happens in interlaced mode [v2]
But that one neglected to fix up the ironlake+ path.
This should fix the issue reported by Alfonso Fiore where booting with
only a HDMI cable connected to his TV failed to display anything. The
issue is that the bios set up things for 1080i and used the pannel
fitter to scale up the lower progressive resolutions. We failed to
clear the interlace bit in the PIPEACONF register, resulting in havoc.
v2: Be more paranoid and just unconditionally clear the field before
setting new values.
Cc: Peter Ross <pross@xvid.org> Cc: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
Daniel Vetter [Wed, 8 Feb 2012 15:42:52 +0000 (16:42 +0100)]
drm/i915: no lvds quirk for AOpen MP45
According to a bug report, it doesn't have one.
Cc: stable@kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
Dave Airlie [Tue, 7 Feb 2012 15:29:04 +0000 (15:29 +0000)]
Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: add a LLC feature flag in device description
drm/i915: kill i915_mem.c
drm/i915: Use kcalloc instead of kzalloc to allocate array
drm/i915/dp: Check for AUXCH error before checking for success
drm/i915/dp: Use auxch precharge value of 5 everywhere
drm/i915/dp: Tweak auxch clock divider for PCH
drm/i915: Remove a comment about PCH from the non-PCH path
drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP)
drm/i915: Implement plane-disabled assertion for PCH too
drivers: i915: Fix BLC PWM register setup
drm/i915: Check that plane/pipe is disabled before removing the fb
drm/i915: fix typo in function name
drm/i915: split out pll divider code
drm/i915: split 9xx refclk & sdvo tv code out
agp/intel: Add pci id for hostbridge from has/qemu
drm/i915: there is no pipe CxSR on ironlake
drm/i915: Only look for matching clocks for LVDS downclock
drm/i915: Silence _DSM errors
Keith Packard [Wed, 25 Jan 2012 16:16:25 +0000 (08:16 -0800)]
drm/i915: Force explicit bpp selection for intel_dp_link_required
It is never correct to use intel_crtc->bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be addressed separately from this bugfix.
intel_dp_link_required is called from intel_dp_mode_valid and
intel_dp_mode_fixup.
* intel_dp_mode_valid is called to list supported modes; in this case,
the current crtc values cannot be relevant as the modes in question
may never be selected. Thus, using intel_crtc->bpp is never right.
* intel_dp_mode_fixup is called during mode setting, but it is run
well before ironlake_crtc_mode_set is called to set intel_crtc->bpp,
so using intel_crtc-bpp in this path can only ever get a stale
value.
Cc: Lubos Kolouch <lubos.kolouch@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881 Tested-by: Dave Airlie <airlied@redhat.com> Tested-by: camalot@picnicpark.org (Dell Latitude 6510) Tested-by: Roland Dreier <roland@digitalvampire.org> Signed-off-by: Keith Packard <keithp@keithp.com>
Sascha Hauer [Wed, 1 Feb 2012 10:38:37 +0000 (11:38 +0100)]
drm exynos: use drm_fb_helper_set_par directly
info->fix.visual already is correctly set from drm_fb_helper_fill_fix.
info->fix.line_length is also set from drm_fb_helper_fill_fix,
so drm_fb_helper_set_par directly instead of a custom
exynos_drm_fbdev_set_par.
Sascha Hauer [Wed, 1 Feb 2012 10:38:23 +0000 (11:38 +0100)]
drm: add proper return value for drm_mode_crtc_set_gamma_size
drm_mode_crtc_set_gamma_size returns boolean true for success
and false for failure. This is not very kernel conform, so
change it to return 0 for success and a propert error code
otherwise. Noone checks the return value, so no users have to
be fixed.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
Julia Lawall [Mon, 30 Jan 2012 11:05:55 +0000 (12:05 +0100)]
drivers/gpu/drm/drm_ioc32.c: initialize all fields
The c32 structure is allocated on the stack and its idx field is not
initialized before copying it to user level. This patch takes the value
from the result of the ioctl, as done for the other fields.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Dave Airlie <airlied@redhat.com>
Eugeni Dodonov [Thu, 5 Jan 2012 11:34:28 +0000 (09:34 -0200)]
drm: give up on edid retries when i2c bus is not responding
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.
This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).
Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s
Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s
Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: Sean Finney <seanius@seanius.net> Tested-by: Soren Hansen <soren@linux2go.dk> Tested-by: Hernando Torque <sirius@sonnenkinder.org> Tested-by: Mike Lothian <mike@fireburn.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059 Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jean Delvare [Sat, 28 Jan 2012 10:08:58 +0000 (11:08 +0100)]
drm/radeon/kms: Use the standard VESA timeout for DDC channels
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jean Delvare [Sat, 28 Jan 2012 10:07:09 +0000 (11:07 +0100)]
drm/kms: Make i2c buses faster
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So set it to 10 in DRM drivers too, this will make EDID block
reads faster. We might even lower the udelay value later if no problem
is reported.
Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ilija Hadzic [Tue, 31 Jan 2012 14:35:25 +0000 (09:35 -0500)]
drm/radeon/kms: remove benchmarks shorter than one page
copy_blit operation works only on integral number of pages
so benchmarks shorter than one page size (4K) do not make sense
v2: use RADEON_GPU_PAGE_SIZE instead of "magic" 1024 number and
sweep sizes between 1 * <page_size> to 16K * <page_size> doubling
the size in each iteration; we get the same coverage, as
in the original benchmark, but guarantee integer multiples
of page size
v3: add whitespace between '*' operator per review received from
zajec5@gmail.com
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm: remove master fd restriction on mode setting getters
Its useful to be able to call the mode setting getter ioctls.
Not requiring master fd, enables writing a simple program which
can query the state of the video system.
Since these ioctls are only "getters" there is no security or
synchronization issues which would require master fd. Opening
an new fd is already protected by the file permissions on the
device file.
Linus Torvalds [Thu, 2 Feb 2012 23:47:33 +0000 (15:47 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
rbd: fix safety of rbd_put_client()
rbd: fix a memory leak in rbd_get_client()
ceph: create a new session lock to avoid lock inversion
ceph: fix length validation in parse_reply_info()
ceph: initialize client debugfs outside of monc->mutex
ceph: change "ceph.layout" xattr to be "ceph.file.layout"
Alex Elder [Sun, 29 Jan 2012 19:57:43 +0000 (13:57 -0600)]
rbd: fix safety of rbd_put_client()
The rbd_client structure uses a kref to arrange for cleaning up and
freeing an instance when its last reference is dropped. The cleanup
routine is rbd_client_release(), and one of the things it does is
delete the rbd_client from rbd_client_list. It acquires node_lock
to do so, but the way it is done is still not safe.
The problem is that when attempting to reuse an existing rbd_client,
the structure found might already be in the process of getting
destroyed and cleaned up.
Here's the scenario, with "CLIENT" representing an existing
rbd_client that's involved in the race:
Thread on CPU A | Thread on CPU B
--------------- | ---------------
rbd_put_client(CLIENT) | rbd_get_client()
kref_put() | (acquires node_lock)
kref->refcount becomes 0 | __rbd_client_find() returns CLIENT
calls rbd_client_release() | kref_get(&CLIENT->kref);
| (releases node_lock)
(acquires node_lock) |
deletes CLIENT from list | ...and starts using CLIENT...
(releases node_lock) |
and frees CLIENT | <-- but CLIENT gets freed here
Fix this by having rbd_put_client() acquire node_lock. The result
could still be improved, but at least it avoids this problem.
Signed-off-by: Alex Elder <elder@dreamhost.com> Signed-off-by: Sage Weil <sage@newdream.net>
This has been updated since I last sent it as the creation of the new
mm_access() function did almost exactly the same thing as parts of the
previous version of this patch did.
In order to use mm_access() even when /proc isn't enabled, we move it to
kernel/fork.c where other related process mm access functions already
are.
Signed-off-by: Chris Yeoh <yeohc@au1.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / karo-tx-linux.git / log