ILK+ have this register on the PCH. This check was triggering unclaimed
writes.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula noticed that the parentheses are wrong and we & the bit
with the register address instead of the read-back value. He sent a
patch to correct that.
On second look, we write the same register in the previous line, and
the w/a seems to be to set FDI_RX_PHASE_SYNC_POINTER_OVR to enable the
logic, then keep always set FDI_RX_PHASE_SYNC_POINTER_OVR and toggle
FDI_RX_PHASE_SYNC_POINTER_EN before/after enabling the pc transcoder.
So the right things seems to be to simply kill the 2nd write.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Dropped a bogus ~ from the commit message that somehow crept
in.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The bspec was recently updated to remove the ability to update the
semaphore using the MI_SEMAPHORE_BOX command, the ability to wait upon
the semaphore value remained. Instead the advice is to update the
register using the MI_LOAD_REGISTER_IMM command. In cursory testing,
semaphores continue to function - the question is whether this fixes
some of the deadlocks where the semaphore registers contained stale
values?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends. This optimization rips 32 bytes of
binary code on x86_64.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This also fixes a bug where the fence manager was left without irq
enabled when waiting for fences, causing various errors at module
load time
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Hiding SVGA seems to trigger a VGA screen clear, and with no
traces dirty it doesn't seem to repaint
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is similar to other platforms that don't allow command submission
to buffers locked on the cpu.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.
Note that thit commit may be obsoleted by the cross-device reservation work.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
v2: Don't touch include/linux/kref.h
v3: Adapt to kref_get_unless_zero return value change
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.
v2: Formatting fixes.
v3: Invert the return value.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vmwgfx was its only user and always sets it to the same..
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-By: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's always hardcoded to the same value.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-By: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When trying to obtain an accurate timestamp for the last vsync interrupt
in vblank_disable_and_save() we loop until the vsync counter after reading
the time stamp is identical to the one before.
In the case where no hardware timestamp can be obtained there is probably
no point in trying to make sure we remain within the same vsync during
the time we obtain the counter.
Furthermore we should make sure there's an 'emergency exit' so that we
don't end up in an endless loop when the driver get_vblank_timestamp()
function doesn't manage to return within the same vsync.
This may happen when this function prints out debugging information over
a slow (ie serial) line.
Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... by properly checking connector->polled. This doesn't matter too
much because the polling work itself gets this slightly more right and
doesn't set repoll if there's nothing to do. But we can do better.
v2: Chris Wilson noticed that I broke polling, since repoll will never
ever be set true. Fix this up, and simplify the logic a bit while at
it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix a memory leak by deallocating the memory we got from
alloc_apertures().
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check for alloc_apertures() memory allocation failure, and propagate an
error code in case the allocation failed.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
alloc_apertures() already does the assignment for us, so assigning the
count member after the alloc_apertures() call is not needed.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix a memory leak by deallocating the memory we got from
alloc_apertures().
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check for alloc_apertures() memory allocation failure, and propagate an
error code in case the allocation failed.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check for alloc_apertures() memory allocation failure, and propagate an
error code in case the allocation failed.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's unused.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's unused.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All drivers set it to 0 and nothing uses it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use hweight32 instead of counting for each bit
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use memchr_inv() to check the specified memory region is filled with zero.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Jumps in the vblank and page flip event timestamps cause trouble for
clients, so we should avoid them. The timestamp we get currently with
gettimeofday can jump, so use instead monotonic timestamps.
For backward compatibility use a module flag to revert back to using
gettimeofday timestamps. Add also a DRM_CAP_TIMESTAMP_MONOTONIC flag
that is simply a read only version of the module flag, so that clients
can query this without depending on sysfs.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For measuring duration we want to avoid that our start/end timestamps
jump, so use monotonic instead of real time for that.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: mario.kleiner
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise if the detect callback reports a different state than what
the user forced (rather likely), we continously annoy userspace about
a hotplug uevent.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Actually there's a reason this stuff is there, and it's called
commit e58f637bb9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Aug 20 09:13:36 2010 +0100
drm/kms: Add a module parameter to disable polling
The idea has been that users can enable/disable polling at runtime. So
the quick hack has been to just re-enable the output polling if xrandr
asks for the latest state of the connectors.
The problem with that hack is that when we force connectors to another
state than what would be detected, we nicely ping-pong:
- Userspace calls probe, gets the forced state, but polling starts
again.
- Polling notices that the state is actually different, wakes up
userspace.
- Repeat.
As that commit already explains, the right fix would be to make the
locking more fine-grained, so that hotplug detection on one output
does not interfere with cursor updates on another crtc.
But that is way too much work. So let's just safe this gross hack by
caching the last-seen state of drm_kms_helper_poll for that driver,
and only fire up the poll engine again if it changed from off to on.
v2: Fixup the edge detection of drm_kms_helper_poll.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49907
Tested-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This can help drivers to make somewhat intelligent decisions in their
->detect callback: If the connector is hpd capable and in the unknown
state, the driver needs to force a full detect cycle. Otherwise it
could just (if it chooses so) to update the connector state from it's
hpd handler directly, and always return that in the ->detect callback.
Atm only drm/i915 calls drm_mode_config_reset at resume time, so other
drivers would need to add that call first before using this facility.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
All drivers already have a work item to run the hpd code, so we don't
need to launch a new one in the helper code. Dave Airlie mentioned
that the cancel+re-queue might paper over DP related hpd ping-pongs,
hence why this is split out.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of reusing the polling code for hpd handling, split them up.
This has a few consequences:
- Don't touch HPD capable connectors in the poll loop.
- Only touch HPD capable connectors in drm_helper_hpd_irq_event.
- We could run the HPD handling directly (because all callers already
use their own work item), but for easier bisect that happens in it's
own patch.
The ultimate goal is that drivers grow some smarts about which
connectors have received a hotplug event and only call the detect code
of that connector. But that's a second step.
v2: s/hdp/hpd/, noticed by Adam Jackson. I can't type.
v3: Split out the work item removal as requested by Dave Airlie. This
results in a temporary mode_config.hpd_irq_work item to keep things
the same.
v4: In the hpd_irq_event handler don't bail out if other bits than HPD
are set. This is useful where e.g. hpd is unreliably, but mostly
works. Drivers can then set both HPD and POLL flags, and users get the
best of both worlds: Quick hotplug feedback if the hpd works, but
still reliable detection with the polling. The poll loop already works
the same, and doesn't bail if HPD is set.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Useful if drivers want to be slightly more clever about hotplug
handling.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A helper that drivers can use to send vblank event after a pageflip.
If the driver doesn't support proper vblank irq based time/seqn then
just pass -1 for the pipe # to get do_gettimestamp() behavior (since
there are a lot of drivers that don't use drm_vblank_count_and_time())
Also an internal send_vblank_event() helper for the various other code
paths within drm_irq that also need to send vblank events.
v1: original
v2: add back 'vblwait->reply.sequence = seq' which should not have
been deleted
v3: add WARN_ON() in case lock is not held and comments
v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK
as pointed out by Marcin Slusarz
v5: update docbook
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit adds support for the HDMI output on the Tegra20 SoC. Only
one such output is available, but it can be driven by either of the two
display controllers.
A lot of work on this patch has been contributed by NVIDIA's Mark Zhang
<markz@nvidia.com> and many other people at NVIDIA were very helpful in
getting the HDMI support and surrounding infrastructure to work.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Zhang <markz@nvidia.com>
Reviewed-by: Mark Zhang <markz@nvidia.com>
Tested-by: Mark Zhang <markz@nvidia.com>
Tested-and-acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Terje Bergstrom <tbergstrom@nvidia.com>
Tested-by: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit adds a KMS driver for the Tegra20 SoC. This includes basic
support for host1x and the two display controllers found on the Tegra20
SoC. Each display controller can drive a separate RGB/LVDS output.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Zhang <markz@nvidia.com>
Reviewed-by: Mark Zhang <markz@nvidia.com>
Tested-by: Mark Zhang <markz@nvidia.com>
Tested-and-acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Terje Bergstrom <tbergstrom@nvidia.com>
Tested-by: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes the following sparse warnings:
drivers/gpu/drm/udl/udl_connector.c:80:20: warning:
symbol 'udl_best_single_encoder' was not declared. Should it be static?
drivers/gpu/drm/udl/udl_connector.c:93:5: warning:
symbol 'udl_connector_set_property' was not declared. Should it be static?
drivers/gpu/drm/udl/udl_connector.c:106:35: warning:
symbol 'udl_connector_helper_funcs' was not declared. Should it be static?
drivers/gpu/drm/udl/udl_connector.c:112:28: warning:
symbol 'udl_connector_funcs' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
kfree on a null argument is a no-op.
Silences the following smatch warning:
drivers/gpu/drm/drm_stub.c:496 drm_put_dev() info:
redundant null check on dev->devname calling kfree()
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_property_create_blob() could return NULL in which case NULL pointer
dereference error (on connector->edid_blob_ptr) is possible. Return if
connector->edid_blob_ptr is NULL.
Fixes the following smatch error:
drivers/gpu/drm/drm_crtc.c:3186 drm_mode_connector_update_edid_property()
error: potential null dereference 'connector->edid_blob_ptr'.
(drm_property_create_blob returns null)
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
kfree() on a NULL input is a no-op. Hence remove the check.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
