summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_irq.c
AgeCommit message (Collapse)AuthorFilesLines
2016-08-08drm: Make sure drm_vblank_no_hw_counter isn't abusedDaniel Vetter1-0/+1
Shouldn't be possible since everyone kzallocs this, but better safe than sorry. Random drive-by-idea really. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rdorigo.vivi@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1470673493-14304-1-git-send-email-daniel.vetter@ffwll.ch
2016-08-08drm: Used DRM_LEGACY for all legacy functionsDaniel Vetter1-5/+5
Except for nouveau, only legacy drivers need this really. And nouveau is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special case. I've tried to be careful to leave everything related to modeset still using the DRIVER_MODESET flag. Otherwise it's a direct replacement of !DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability since fewer negative checks overall. Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch
2016-08-08drm: Avoid printing negative values for unsigned variables.Rodrigo Vivi1-5/+5
It was really strange to see negative vblank seqs on debug messages. It is rare to have that big number, but when it happens it is confusing and misleading. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470243226-2750-1-git-send-email-rodrigo.vivi@intel.com
2016-07-19drm: Extract&Document drm_irq.hDaniel Vetter1-1/+0
The drm_irq docs want one function from drmP.h, but that one is a serious mess. Extract it, and while at it improve the docs a bit. There's a bit a header loop issue since core data structures like drm_device and drm_driver aren't in their own headers yet, which means the drm_irq.h include in drmP.h needs to be in just the right spot :( Also noticed that drm_vblank_crtc->last_wait is entirely unused, remove it. v2: git add drm_irq.h ... Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-07-12drm: make drm_vblank_count_and_time() staticGustavo Padovan1-5/+2
As they are not used anywhere outside drm_irq.c make them static. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1467677092-5089-1-git-send-email-gustavo@padovan.org
2016-07-12drm: Only handle _DRM_VBLANK_NEXTONMISS onceMichel Dänzer1-11/+5
Consolidate the _DRM_VBLANK_NEXTONMISS handling between drm_wait_vblank and drm_queue_vblank_event. This is a cleanup spotted while working on other changes. (The way it was previously handled could also theoretically result in drm_queue_vblank_event unnecessarily bumping vblwait->request.sequence, if the vblank counter happened to increment between the drm_vblank_count(_and_time) calls in each function, but that's unlikely) Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466755187-29418-1-git-send-email-michel@daenzer.net
2016-06-27drm: fix some spelling mistakesFrank Binns1-2/+2
Signed-off-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466763337-27428-1-git-send-email-frank.binns@imgtec.com
2016-06-20drm: fix send_vblank_event use-after-free errorMatthew Auld1-2/+2
The drm_pending_event can be freed by drm_send_event_locked, as a result we should call trace_drm_vblank_event_delivered before this to avoid hitting a user-after-free error when accessing the pid member: [ 378.438497] BUG: KASAN: use-after-free in send_vblank_event+0xf0/0x310 [drm] at addr ffff8801ac7e50a0 [ 378.438500] Read of size 4 by task Xorg/1562 [ 378.438501] ============================================================================= [ 378.438504] BUG kmalloc-128 (Tainted: G B ): kasan: bad access detected [ 378.438506] ----------------------------------------------------------------------------- [ 378.438509] INFO: Freed in 0x10001309c age=18446737369265680575 cpu=0 pid=0 [ 378.438541] drm_send_event_locked+0x207/0x2f0 [drm] [ 378.438544] __slab_free+0x24c/0x650 [ 378.438546] kfree+0x3a2/0x760 [ 378.438578] drm_send_event_locked+0x207/0x2f0 [drm] [ 378.438610] send_vblank_event+0xb7/0x310 [drm] [ 378.438643] drm_crtc_send_vblank_event+0x130/0x1f0 [drm] [ 378.438722] intel_atomic_commit_tail+0x23b5/0x53f0 [i915] [ 378.438802] intel_atomic_commit+0xbae/0x12f0 [i915] [ 378.438839] drm_atomic_commit+0xb0/0x120 [drm] [ 378.438855] drm_atomic_helper_connector_dpms+0x339/0x5d0 [drm_kms_helper] [ 378.438891] drm_mode_obj_set_property_ioctl+0x8f1/0xcc0 [drm] [ 378.438927] drm_mode_connector_property_set_ioctl+0xf3/0x170 [drm] [ 378.438959] drm_ioctl+0x2d7/0xae0 [drm] [ 378.438962] do_vfs_ioctl+0x1c9/0x1280 [ 378.438964] SyS_ioctl+0x79/0x90 [ 378.438967] entry_SYSCALL_64_fastpath+0x1a/0xa4 Cc: dri-devel@lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466440966-5410-1-git-send-email-matthew.auld@intel.com
2016-06-13drm: make drm_vblank_{get,put}() staticGustavo Padovan1-8/+2
As they are not used anywhere outside drm_irq.c make them static. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-4-git-send-email-gustavo@padovan.org
2016-06-13drm: remove legacy drm_arm_vblank_event()Gustavo Padovan1-31/+8
We don't have any user of this function anymore, let's remove it. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-3-git-send-email-gustavo@padovan.org
2016-06-13drm: remove legacy drm_send_vblank_event()Gustavo Padovan1-25/+6
We don't have any user of this function anymore, let's remove it. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-2-git-send-email-gustavo@padovan.org
2016-06-03drm/doc: Drop kerneldoc for static functions in drm_irq.cDaniel Vetter1-10/+2
At least in drm core we only document the driver interfaces using kerneldoc. For internals an unstructured comment is good enough. Fixes a warning from kernel-doc, too. Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464729075-22243-5-git-send-email-daniel.vetter@ffwll.ch
2016-06-02Merge branch 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel ↵Dave Airlie1-0/+31
into drm-next drm-intel-next-2016-05-22: - cmd-parser support for direct reg->reg loads (Ken Graunke) - better handle DP++ smart dongles (Ville) - bxt guc fw loading support (Nick Hoathe) - remove a bunch of struct typedefs from dpll code (Ander) - tons of small work all over to avoid casting between drm_device and the i915 dev struct (Tvrtko&Chris) - untangle request retiring from other operations, also fixes reset stat corner cases (Chris) - skl atomic watermark support from Matt Roper, yay! - various wm handling bugfixes from Ville - big pile of cdclck rework for bxt/skl (Ville) - CABC (Content Adaptive Brigthness Control) for dsi panels (Jani&Deepak M) - nonblocking atomic commits for plane-only updates (Maarten Lankhorst) - bunch of PSR fixes&improvements - untangle our map/pin/sg_iter code a bit (Dave Gordon) drm-intel-next-2016-05-08: - refactor stolen quirks to share code between early quirks and i915 (Joonas) - refactor gem BO/vma funcstion (Tvrtko&Dave) - backlight over DPCD support (Yetunde Abedisi) - more dsi panel sequence support (Jani) - lots of refactoring around handling iomaps, vma, ring access and related topics culmulating in removing the duplicated request tracking in the execlist code (Chris & Tvrtko) includes a small patch for core iomapping code - hw state readout for bxt dsi (Ramalingam C) - cdclk cleanups (Ville) - dedupe chv pll code a bit (Ander) - enable semaphores on gen8+ for legacy submission, to be able to have a direct comparison against execlist on the same platform (Chris) Not meant to be used for anything else but performance tuning - lvds border bit hw state checker fix (Jani) - rpm vs. shrinker/oom-notifier fixes (Praveen Paneri) - l3 tuning (Imre) - revert mst dp audio, it's totally non-functional and crash-y (Lyude) - first official dmc for kbl (Rodrigo) - and tons of small things all over as usual * 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel: (194 commits) drm/i915: Revert async unpin and nonblocking atomic commit drm/i915: Update DRIVER_DATE to 20160522 drm/i915: Inline sg_next() for the optimised SGL iterator drm/i915: Introduce & use new lightweight SGL iterators drm/i915: optimise i915_gem_object_map() for small objects drm/i915: refactor i915_gem_object_pin_map() drm/i915/psr: Implement PSR2 w/a for gen9 drm/i915/psr: Use ->get_aux_send_ctl functions drm/i915/psr: Order DP aux transactions correctly drm/i915/psr: Make idle_frames sensible again drm/i915/psr: Try to program link training times correctly drm/i915/userptr: Convert to drm_i915_private drm/i915: Allow nonblocking update of pageflips. drm/i915: Check for unpin correctness. Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" drm/i915: Make unpin async. drm/i915: Prepare connectors for nonblocking checks. drm/i915: Pass atomic states to fbc update functions. drm/i915: Remove reset_counter from intel_crtc. drm/i915: Remove queue_flip pointer. ...
2016-05-24drm: use seqlock for vblank time/countMatthew Auld1-78/+12
This patch aims to replace the roll-your-own seqlock implementation with full-blown seqlock'. We also remove the timestamp ring-buffer in favour of single timestamp/count pair protected by a seqlock. In turn this means we can now increment the vblank freely without the need for clamping. v2: - reduce the scope of the seqlock, keeping vblank_time_lock - make the seqlock per vblank_crtc, so multiple readers aren't blocked by the writer Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462890088-18194-1-git-send-email-matthew.auld@intel.com
2016-05-21drm: Nuke ->vblank_disable_allowedDaniel Vetter1-6/+0
This was added in commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Sep 30 12:14:26 2008 -0700 drm: Rework vblank-wait handling to allow interrupt reduction. to stay backwards-compatible with old UMS code that didn't even tell the kernel when it did a modeset, so that the kernel could save/restore vblank counters. At worst this means vblanks will be somewhat funky on a setup that very likely no one still runs. So let's just nuke it. Plan B would be to set it unconditionally in drm_vblank_init for kms drivers, instead of in each driver separately. So if this patch breaks anything please only restore the hunks in drmP.h and drm_irq.c, plus add a check for DRIVER_MODESET in drm_vblank_init. Stumbled over this in a discussion on irc with Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-19drm/core: Add drm_accurate_vblank_count, v5.Maarten Lankhorst1-0/+31
This function is useful for gen2 intel devices which have no frame counter, but need a way to determine the current vblank count without racing with the vblank interrupt handler. intel_pipe_update_start checks if no vblank interrupt will occur during vblank evasion, but cannot check whether the vblank handler has run to completion. This function uses the timestamps to determine when the last vblank has happened, and interpolates from there. Changes since v1: - Take vblank_time_lock and don't use drm_vblank_count_and_time. Changes since v2: - Don't return time of last vblank. Changes since v3: - Change pipe to unsigned int. (Ville) - Remove unused documentation for tv_ret. (kbuild) Changes since v4: - Add warning to docs when the function is useful. - Add a WARN_ON when get_vblank_timestamp is unavailable. - Use drm_vblank_count. Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v4 Acked-by: David Airlie <airlied@linux.ie> #irc, v4 Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-2-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
2016-04-06Merge tag 'topic/drm-misc-2016-04-01' of ↵Dave Airlie1-4/+1
git://anongit.freedesktop.org/drm-intel into drm-next * tag 'topic/drm-misc-2016-04-01' of git://anongit.freedesktop.org/drm-intel: drm: Add new DCS commands in the enum list drm: Make uapi headers C89 pendantic compliant drm/atomic: export drm_atomic_helper_wait_for_fences() drm: Untangle __KERNEL__ guards drm: Move DRM_MODE_OBJECT_* to uapi headers drm: align #include directives with libdrm in uapi headers drm: Make drm.h uapi header safe for C++ vgacon: dummy implementation for vgacon_text_force drm/sysfs: Nuke TV/DVI property files drm/ttm: Remove TTM_HAS_AGP drm: bridge/dw-hdmi: Remove pre_enable/post_disable dummy funcs Revert "drm: Don't pass negative delta to ktime_sub_ns()" drm/atmel: Fixup drm_connector_/unplug/unregister/_all drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all() drm: bridge: Make (pre/post) enable/disable callbacks optional
2016-03-30Revert "drm: Don't pass negative delta to ktime_sub_ns()"Daniel Vetter1-4/+1
This reverts commit e91abf80a0998f326107874c88d549f94839f13c. Since commit 24e4a8c3e8868874835b0f1ad6dd417341e99822 Author: John Stultz <john.stultz@linaro.org> Date: Wed Jul 16 21:03:53 2014 +0000 ktime: Kill non-scalar ktime_t implementation for 2038 there is no longer a 32bit version that's unsigned, and we don't have to jump through ridiculous hoops to make the calculations correct. I didn't look whether there's more of this pattern in the kernel. Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459249942-21589-1-git-send-email-daniel.vetter@ffwll.ch
2016-03-14Merge drm-fixes into drm-next.Dave Airlie1-3/+70
Nouveau wanted this to avoid some worse conflicts when I merge that.
2016-02-17drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)Mario Kleiner1-2/+1
drm_vblank_offdelay can have three different types of values: < 0 is to be always treated the same as dev->vblank_disable_immediate = 0 is to be treated as "never disable vblanks" > 0 is to be treated as disable immediate if kms driver wants it that way via dev->vblank_disable_immediate. Otherwise it is a disable timeout in msecs. This got broken in Linux 3.18+ for the implementation of drm_vblank_on. If the user specified a value of zero which should always reenable vblank irqs in this function, a kms driver could override the users choice by setting vblank_disable_immediate to true. This patch fixes the regression and keeps the user in control. v2: Only reenable vblank if there are clients left or the user requested to "never disable vblanks" via offdelay 0. Enabling vblanks even in the "delayed disable" case (offdelay > 0) was specifically added by Ville in commit cd19e52aee922 ("drm: Kick start vblank interrupts at drm_vblank_on()"), but after discussion it turns out that this was done by accident. Citing Ville: "I think it just ended up as a mess due to changing some of the semantics of offdelay<0 vs. offdelay==0 vs. disable_immediate during the review of the series. So yeah, given how drm_vblank_put() works now, I'd just make this check for offdelay==0." Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 3.18+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4Mario Kleiner1-0/+16
Changes to drm_update_vblank_count() in Linux 4.4 broke the behaviour of the pre/post modeset functions as the new update code doesn't deal with hw vblank counter resets inbetween calls to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it should. This causes mistreatment of such hw counter resets as counter wraparound, and thereby large forward jumps of the software vblank counter which in turn cause vblank event dispatching and vblank waits to fail/hang --> userspace clients hang. This symptom was reported on radeon-kms to cause a infinite hang of KDE Plasma 5 shell's login procedure, preventing users from logging in. Fix this by detecting when drm_update_vblank_count() is called inside a pre->post modeset interval. If so, clamp valid vblank increments to the safe values 0 and 1, pretty much restoring the update behavior of the old update code of Linux 4.3 and earlier. Also reset the last recorded hw vblank count at call to drm_vblank_post_modeset() to be safe against hw that after modesetting, dpms on etc. only fires its first vblank irq after drm_vblank_post_modeset() was already called. Reported-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2)Mario Kleiner1-0/+43
This fixes a regression introduced by the new drm_update_vblank_count() implementation in Linux 4.4: Restrict the bump of the software vblank counter in drm_update_vblank_count() to a safe maximum value of +1 whenever there is the possibility that concurrent readers of vblank timestamps could be active at the moment, as the current implementation of the timestamp caching and updating is not safe against concurrent readers for calls to store_vblank() with a bump of anything but +1. A bump != 1 would very likely return corrupted timestamps to userspace, because the same slot in the cache could be concurrently written by store_vblank() and read by one of those readers in a non-atomic fashion and without the read-retry logic detecting this collision. Concurrent readers can exist while drm_update_vblank_count() is called from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank- irq callers. However, all those calls are happening with the vbl_lock locked thereby preventing a drm_vblank_get(), so the vblank refcount can't increase while drm_update_vblank_count() is executing. Therefore a zero vblank refcount during execution of that function signals that is safe for arbitrary counter bumps if called from outside vblank irq, whereas a non-zero count is not safe. Whenever the function is called from vblank irq, we have to assume concurrent readers could show up any time during its execution, even if the refcount is currently zero, as vblank irqs are usually only enabled due to the presence of readers, and because when it is called from vblank irq it can't hold the vbl_lock to protect it from sudden bumps in vblank refcount. Therefore also restrict bumps to +1 when the function is called from vblank irq. Such bumps of more than +1 can happen at other times than reenabling vblank irqs, e.g., when regular vblank interrupts get delayed by more than 1 frame due to long held locks, long irq off periods, realtime preemption on RT kernels, or system management interrupts. A better solution would be to rewrite the timestamp caching to use full seqlocks to allow concurrent writes and reads for arbitrary vblank counter increments. v2: Add code comment that this is essentially a hack and should be replaced by a full seqlock implementation for caching of timestamps. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17drm: No-Op redundant calls to drm_vblank_off() (v2)Mario Kleiner1-1/+10
Otherwise if a kms driver calls into drm_vblank_off() more than once before calling drm_vblank_on() again, the redundant calls to vblank_disable_and_save() will call drm_update_vblank_count() while hw vblank counters and vblank timestamping are in a undefined state during modesets, dpms off etc. At least with the legacy drm helpers it is not unusual to get multiple calls to drm_vblank_off and drm_vblank_on, e.g., half a dozen calls to drm_vblank_off and two calls to drm_vblank_on were observed on radeon-kms during dpms-off -> dpms-on transition. We don't no-op calls from atomic modesetting drivers, as they should do a proper job of tracking hw state. Fixes large jumps of the software maintained vblank counter due to the hardware vblank counter resetting to zero during dpms off or modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on instead of drm_vblank_pre/post_modeset(). This fixes a regression caused by the changes made to drm_update_vblank_count() in Linux 4.4. v2: Don't no-op on atomic modesetting drivers, per suggestion of Daniel Vetter. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-08drm/vblank: Use drm_event_reserve_initDaniel Vetter1-7/+4
Well we can't use that directly since that code must hold dev->event_lock already. Extract an _unlocked version. Embarrassingly I've totally forgotten about this patch and any kind of event-based vblank wait totally blew up, killing the kernel. v2: Pick the right base struct, someone didn't noticed that gcc was unhappy. No bug since the addresses at least matched (Daniel Stone) Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453978864-1513-1-git-send-email-daniel.vetter@ffwll.ch
2016-01-25drm: Create drm_send_event helpersDaniel Vetter1-5/+2
Use them in the core vblank code and exynos/vmwgfx drivers. Note that the difference between wake_up_all and _interruptible in vmwgfx doesn't matter since the only waiter is the core code in drm_fops.c. And that is interruptible. v2: Adjust existing kerneldoc too. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Acked-by: Daniel Stone <daniels@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Inki Dae <inki.dae@samsung.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452548477-15905-6-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [danvet: Squash in compile fixup, spotted by 0-day.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-01-08drm: move MODULE_PARM_DESC to other fileDan Carpenter1-0/+3
We moved the module options from drm_drv.c to drm_irq.c in 18882995713d ('drm: Move vblank related module options into drm_irq.c'). Let's move the MODULE_PARM_DESC()s as well so they're together. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160108110045.GF32195@mwanda Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-04drm/nouveau: Fix pre-nv50 pageflip events (v4)Daniel Vetter1-1/+53
Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 Author: Mario Kleiner <mario.kleiner.de@gmail.com> Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. Unfortunately that hack got uprooted in commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb Author: Thierry Reding <treding@nvidia.com> Date: Wed Aug 12 17:00:31 2015 +0200 drm/irq: Make pipe unsigned and name consistent Triggering a warning when trying to sample the vblank timestamp for a non-existing pipe. There's a few ways to fix this: - Open-code the old behaviour, which just enshrines this slight breakage of the userspace ABI. - Revert Mario's commit and again inflict broken timestamps, again not pretty. - Fix this for real by delaying the pageflip TS until the next vblank interrupt, thereby making it accurate. This patch implements the third option. Since having a page flip interrupt that happens when the pageflip gets armed and not when it completes in the next vblank seems to be fairly common (older i915 hw works very similarly) create a new helper to arm vblank events for such drivers. v2 (Mario Kleiner): - Fix function prototypes in drmP.h - Add missing vblank_put() for pageflip completion without pageflip event. - Initialize sequence number for queued pageflip event to avoid trouble in drm_handle_vblank_events(). - Remove dead code and spelling fix. v3 (Mario Kleiner): - Add a signed-off-by and cc stable tag per Ilja's advice. v4 (Thierry Reding): - Fix kerneldoc typo, discovered by Michel Dänzer - Rearrange tags and changelog Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431 Cc: Thierry Reding <treding@nvidia.com> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # v4.3 Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-13drm: Don't oops in drm_calc_timestamping_constants() if drm_vblank_init() ↵Ville Syrjälä1-1/+9
wasn't called Seems the crtc helpers call drm_calc_timestamping_constants() unconditionally even if the driver didn't initialize vblank support by calling drm_vblank_init(). That used to be OK since the constants were stored under drm_crtc. However I broke this with commit eba1f35dfe14 ("drm: Move timestamping constants into drm_vblank_crtc") when I moved the constants to live inside the drm_vblank_crtc struct instead. If drm_vblank_init() isn't called, we don't allocate these structures, and so drm_calc_timestamping_constants() will oops. Fix it by adding a check into drm_calc_timestamping_constants() to see if vblank support was initialized at all. And to keep in line with other such checks, also toss in a check and warn for the case where vblank support was initialized, but the wrong number of crtcs was specified. Fixes the following sort of oops: BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 IP: [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm] PGD 0 Oops: 0002 [#1] SMP Modules linked in: sr_mod cdrom mgag200(+) i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt libahci fb_sys_fops bnx2x ttm tg3(+) mdio drm ptp sd_mod libata i2c_core pps_core libcrc32c hpsa dm_mirror dm_region_hash dm_log dm_mod CPU: 0 PID: 418 Comm: kworker/0:2 Not tainted 4.3.0+ #1 Hardware name: HP ProLiant DL380 Gen9, BIOS P89 06/09/2015 Workqueue: events work_for_cpu_fn task: ffff88046ca95500 ti: ffff88007830c000 task.ti: ffff88007830c000 RIP: 0010:[<ffffffffa014b266>] [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm] RSP: 0018:ffff88007830f4e8 EFLAGS: 00010246 RAX: 0000000000fe4c00 RBX: ffff88006a849160 RCX: 0000000000000540 RDX: 0000000000000000 RSI: 000000000000fde8 RDI: ffff88006a849000 RBP: ffff88007830f518 R08: ffff88007830c000 R09: 00000001b87e3712 R10: 00000000000050c4 R11: 0000000000000000 R12: 0000000000fe4c00 R13: ffff88006a849000 R14: 0000000000000000 R15: 000000000000fde8 FS: 0000000000000000(0000) GS:ffff88046f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 00000000019d6000 CR4: 00000000001406f0 Stack: ffff88007830f518 ffff88006a849000 ffff880c69b90340 ffff880c69b90000 ffff880c69b90348 ffff880c69b90340 ffff88007830f748 ffffffffa042f7e7 ffff88006a849090 0000000000000000 ffff88006a849160 0000000000000000 Call Trace: [<ffffffffa042f7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0 [drm_kms_helper] [<ffffffffa04307d4>] drm_crtc_helper_set_config+0x8d4/0xb10 [drm_kms_helper] [<ffffffffa01548d4>] drm_mode_set_config_internal+0x64/0x100 [drm] [<ffffffffa043c342>] drm_fb_helper_pan_display+0xa2/0x280 [drm_kms_helper] [<ffffffff81392c7b>] fb_pan_display+0xbb/0x170 [<ffffffff8138cf70>] bit_update_start+0x20/0x50 [<ffffffff8138b81b>] fbcon_switch+0x39b/0x590 [<ffffffff8140a3d0>] redraw_screen+0x1a0/0x240 [<ffffffff8140b30e>] do_bind_con_driver+0x2ee/0x310 [<ffffffff8140b651>] do_take_over_console+0x141/0x1b0 [<ffffffff81387377>] do_fbcon_takeover+0x57/0xb0 [<ffffffff8138c98b>] fbcon_event_notify+0x60b/0x750 [<ffffffff810a5599>] notifier_call_chain+0x49/0x70 [<ffffffff810a58dd>] __blocking_notifier_call_chain+0x4d/0x70 [<ffffffff810a5916>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff8139282b>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff81394881>] register_framebuffer+0x1f1/0x330 [<ffffffffa043d9aa>] drm_fb_helper_initial_config+0x27a/0x3d0 [drm_kms_helper] [<ffffffffa0469b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200] [<ffffffffa0468586>] mgag200_modeset_init+0x176/0x1e0 [mgag200] [<ffffffffa0464659>] mgag200_driver_load+0x3f9/0x580 [mgag200] [<ffffffffa014e067>] drm_dev_register+0xa7/0xb0 [drm] [<ffffffffa015054f>] drm_get_pci_dev+0x8f/0x1e0 [drm] [<ffffffffa046937b>] mga_pci_probe+0x9b/0xc0 [mgag200] [<ffffffff813662d5>] local_pci_probe+0x45/0xa0 [<ffffffff8109afe4>] work_for_cpu_fn+0x14/0x20 [<ffffffff8109e13c>] process_one_work+0x14c/0x3c0 [<ffffffff8109eaa4>] worker_thread+0x244/0x470 [<ffffffff8168bfba>] ? __schedule+0x2aa/0x760 [<ffffffff8109e860>] ? rescuer_thread+0x310/0x310 [<ffffffff810a4438>] kthread+0xd8/0xf0 [<ffffffff810a4360>] ? kthread_park+0x60/0x60 [<ffffffff8169030f>] ret_from_fork+0x3f/0x70 [<ffffffff810a4360>] ? kthread_park+0x60/0x60 Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69 c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 9a 6f 03 00 01 <45> 89 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b RIP [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm] RSP <ffff88007830f4e8> CR2: 00000000000000b0 Cc: Jeff Moyer <jmoyer@redhat.com> Reported-by: Jeff Moyer <jmoyer@redhat.com> References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html Fixes: eba1f35dfe14 ("drm: Move timestamping constants into drm_vblank_crtc") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-16drm: Add DRM_DEBUG_VBL()Ville Syrjälä1-11/+11
Add a new debug class for _verbose_ debug message from the vblank code. That is message we spew out potentially for every vblank interrupt. Thierry already got annoyed at the spew, and now I managed to lock up my box with these debug prints (seems serial console + a few debug prints every vblank aren't a good combination). Or should I maybe call it DRM_DEBUG_IRQ? Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-16drm: Don't use '\' for string literal concatenationVille Syrjälä1-2/+2
String literals get concatenated just fine on their own, no need to use '\'. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-07drm: Stop using drm_vblank_count() as the hw frame counterVille Syrjälä1-0/+17
drm_vblank_count() returns the software counter. We should not pretend it's the hw counter since we use the hw counter to figuere out what the software counter value should be. So instead provide a new function drm_vblank_no_hw_counter() for drivers that don't have a real hw counter. The new function simply returns 0, which is about the only thing it can do. Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vincent Abriou <vincent.abriou@st.com> [danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface change.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-06drm/irq: Use unsigned int pipe in public APIThierry Reding1-1/+1
This continues the pattern started in commit cc1ef118fc09 ("drm/irq: Make pipe unsigned and name consistent"). This is applied to the public APIs and driver callbacks, so pretty much all drivers need to be updated to match the new prototypes. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Inki Dae <inki.dae@samsung.com> Cc: Jianwei Wang <jianwei.wang.chn@gmail.com> Cc: Alison Wang <alison.wang@freescale.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-01drm: Don't zero vblank timestamps from the irq handlerVille Syrjälä1-3/+4
If we couldn't get a high precisions vblank timestamp, we currently store a zeroed timestamp instead and assume the next vblank irq to get us something better. This makes sense when trying to update the timestamp from eg. vblank enable. But if we do this from the vblank irq we will never get a vblank timestamp unless we high precision timestamps are available and succeeded. This break weston for instance on drivers lacking high precision timestamps. To fix this, zero the timestamp only when not called from vbl irq. When called from the irq, we still want the timestamp, even if not perfect. This fixes a regression from 4dfd64862ff852df drm: Use vblank timestamps to guesstimate how many vblanks were missed Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Reported-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm/irq: Add drm_crtc_vblank_count_and_time()Thierry Reding1-0/+23
This function is the KMS native variant of drm_vblank_count_and_time(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm/irq: Rename drm_crtc -> crtcThierry Reding1-4/+4
Since the original crtc parameter was renamed to pipe, there is no longer a need to artificially prefix the CRTC parameter. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Use vblank timestamps to guesstimate how many vblanks were missedVille Syrjälä1-115/+91
When lacking am accurate hardware frame counter, we can fall back to using the vblank timestamps to guesstimagte how many vblanks have elapsed since the last time the vblank counter was updated. Take the oppostunity to unify the vblank_disable_and_save() and drm_handle_vblank_events() to call the same function (drm_update_vblank_count()) to perform the vblank updates. If the hardware/driver has an accurate frame counter use it instead of the timestamp based guesstimate. If the hardware/driver has neither a frame counter nor acurate vblank timestamps, we fall back to assuming that each drm_handle_vblank_events() should increment the vblank count by one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: store_vblank() is never called with NULL timestampVille Syrjälä1-7/+5
Remove the NULL 't_vblank' checks from store_vblank() since that will never happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Clean up drm_calc_vbltimestamp_from_scanoutpos() vbl_statusVille Syrjälä1-11/+8
Avoid confusion and don't use 'vbl_status' as both the .get_scanout_position() return value and the return value from drm_calc_vbltimestamp_from_scanoutpos(). While at it make 'vbl_status' unsigned and print it as hex in the debug prints since it's a bitmask. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Limit the number of .get_vblank_counter() retriesVille Syrjälä1-2/+4
Pontential infinite loops in the vblank code are a bad idea. Add some limits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Pass flags to drm_update_vblank_count()Ville Syrjälä1-4/+5
We'll soon have use for the 'flags' in drm_update_vblank_count() so pass it in. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Kill pixeldur_nsVille Syrjälä1-8/+5
pixeldur_ns is now unsued, so kill it from drm_vblank_crtc. framedur_ns is also currently unused but we will have use for it in the near future so leave it be. linedur_ns is still used by nouveau for some internal delays. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Stop using linedur_ns and pixeldur_ns for vblank timestampsVille Syrjälä1-11/+8
linedur_ns, and especially pixeldur_ns are becoming rather inaccurate to be used for the vblank timestamp correction. With 4k@60 the pixel duration is already below 2ns, so the amount of error due to the truncation to nanoseconds is introducing quite a bit of error. We can avoid such problems if we instead calculate the timestamp delta_ns directly from the dislay timings, avoiding the use of these intermediate truncated values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in fixup from Thierry Reding for amdgpu.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Move timestamping constants into drm_vblank_crtcVille Syrjälä1-8/+8
Collect the timestamping constants alongside the rest of the relevant stuff under drm_vblank_crtc. We can now get rid of the 'refcrtc' parameter to drm_calc_vbltimestamp_from_scanoutpos(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: s/int crtc/unsigned int pipe/ stragglesVille Syrjälä1-8/+8
Finish the recent replacement of 'int pipe' with 'unsigned int pipe' Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-17Merge tag 'v4.2-rc7' into drm-nextDave Airlie1-1/+1
Linux 4.2-rc7 Backmerge master for i915 fixes
2015-08-12drm/irq: Document return values more consistentlyThierry Reding1-2/+5
Some of the functions are documented inconsistently. Add Returns: sections where missing and use consistent style to describe the return value. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12drm/irq: Make pipe unsigned and name consistentThierry Reding1-157/+159
Name all references to the pipe number (CRTC index) consistently to make it easier to distinguish which is a pipe number and which is a pointer to struct drm_crtc. While at it also make all references to the pipe number unsigned because there is no longer any reason why it should ever be negative. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12drm/irq: Check for valid VBLANK before dereferenceThierry Reding1-2/+9
When accessing the array of per-CRTC VBLANK structures we must always check that the index into the array is valid before dereferencing to avoid crashing. Signed-off-by: Thierry Reding <treding@nvidia.com> [danvet: Squash in my own whitespace ocd fixup in drm_vblank_count.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12drm/irq: Remove negative CRTC index special-caseThierry Reding1-1/+1
The drm_send_vblank_event() function treats negative CRTC indices as meaning that a driver doesn't have proper VBLANK handling. This is the only place where DRM needs negative CRTC indices, so in order to enable subsequent cleanup, remove this special case and replace it by the more obvious check for whether or not VBLANK support was initialized. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-07drm/vblank: Use u32 consistently for vblank countersDaniel Vetter1-1/+1
In commit 99264a61dfcda41d86d0960cf2d4c0fc2758a773 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 15 19:34:43 2015 +0200 drm/vblank: Fixup and document timestamp update/read barriers I've switched vblank->count from atomic_t to unsigned long and accidentally created an integer comparison bug in drm_vblank_count_and_time since vblanke->count might overflow the u32 local copy and hence the retry loop never succeed. Fix this by consistently using u32. Cc: Michel Dänzer <michel@daenzer.net> Reported-by: Michel Dänzer <michel@daenzer.net> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-16 13:27:47 +0000