- 08 8月, 2016 1 次提交
-
-
由 Rodrigo Vivi 提交于
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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470243226-2750-1-git-send-email-rodrigo.vivi@intel.com
-
- 19 7月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 12 7月, 2016 2 次提交
-
-
由 Gustavo Padovan 提交于
As they are not used anywhere outside drm_irq.c make them static. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1467677092-5089-1-git-send-email-gustavo@padovan.org
-
由 Michel Dänzer 提交于
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: NMichel Dänzer <michel.daenzer@amd.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466755187-29418-1-git-send-email-michel@daenzer.net
-
- 27 6月, 2016 1 次提交
-
-
由 Frank Binns 提交于
Signed-off-by: NFrank Binns <frank.binns@imgtec.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466763337-27428-1-git-send-email-frank.binns@imgtec.com
-
- 21 6月, 2016 1 次提交
-
-
由 Matthew Auld 提交于
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: NMatthew Auld <matthew.auld@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466440966-5410-1-git-send-email-matthew.auld@intel.com
-
- 14 6月, 2016 3 次提交
-
-
由 Gustavo Padovan 提交于
As they are not used anywhere outside drm_irq.c make them static. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-4-git-send-email-gustavo@padovan.org
-
由 Gustavo Padovan 提交于
We don't have any user of this function anymore, let's remove it. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-3-git-send-email-gustavo@padovan.org
-
由 Gustavo Padovan 提交于
We don't have any user of this function anymore, let's remove it. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-2-git-send-email-gustavo@padovan.org
-
- 04 6月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
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: NLiviu Dudau <Liviu.Dudau@arm.com> Acked-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464729075-22243-5-git-send-email-daniel.vetter@ffwll.ch
-
- 25 5月, 2016 1 次提交
-
-
由 Matthew Auld 提交于
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: NMatthew Auld <matthew.auld@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462890088-18194-1-git-send-email-matthew.auld@intel.com
-
- 21 5月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
This was added in commit 0a3e67a4 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: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 5月, 2016 1 次提交
-
-
由 Maarten Lankhorst 提交于
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: NMaarten 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.comReviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
-
- 30 3月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
This reverts commit e91abf80. Since commit 24e4a8c3 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: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459249942-21589-1-git-send-email-daniel.vetter@ffwll.ch
-
- 17 2月, 2016 4 次提交
-
-
由 Mario Kleiner 提交于
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 cd19e52a ("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: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NDaniel 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: NDave Airlie <airlied@redhat.com>
-
由 Mario Kleiner 提交于
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: NVlastimil Babka <vbabka@suse.cz> Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Tested-by: NVlastimil 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: NDave Airlie <airlied@redhat.com>
-
由 Mario Kleiner 提交于
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: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NDaniel 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: NDave Airlie <airlied@redhat.com>
-
由 Mario Kleiner 提交于
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: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NDaniel 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: NDave Airlie <airlied@redhat.com>
-
- 08 2月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
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: NDaniel Stone <daniels@collabora.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453978864-1513-1-git-send-email-daniel.vetter@ffwll.ch
-
- 26 1月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
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: NDaniel 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.chReviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> [danvet: Squash in compile fixup, spotted by 0-day.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 1月, 2016 1 次提交
-
-
由 Dan Carpenter 提交于
We moved the module options from drm_drv.c to drm_irq.c in 18882995 ('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: NDan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160108110045.GF32195@mwandaSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 12月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e4 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 cc1ef118 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: NBen Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # v4.3 Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 11月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
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 eba1f35d ("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: NJeff Moyer <jmoyer@redhat.com> References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html Fixes: eba1f35d ("drm: Move timestamping constants into drm_vblank_crtc") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 10 11月, 2015 1 次提交
-
-
由 Andrew Morton 提交于
Switch everything to the new and more capable implementation of abs(). Mainly to give the new abs() a bit of a workout. Cc: Michal Nazarewicz <mina86@mina86.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 16 10月, 2015 2 次提交
-
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
String literals get concatenated just fine on their own, no need to use '\'. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 10月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NVincent Abriou <vincent.abriou@st.com> [danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface change.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 10月, 2015 1 次提交
-
-
由 Thierry Reding 提交于
This continues the pattern started in commit cc1ef118 ("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: NThierry Reding <treding@nvidia.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 10月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
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 4dfd6486 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: NThierry Reding <thierry.reding@gmail.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 25 9月, 2015 11 次提交
-
-
由 Thierry Reding 提交于
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: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thierry Reding 提交于
Since the original crtc parameter was renamed to pipe, there is no longer a need to artificially prefix the CRTC parameter. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Remove the NULL 't_vblank' checks from store_vblank() since that will never happen. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Pontential infinite loops in the vblank code are a bad idea. Add some limits. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
We'll soon have use for the 'flags' in drm_update_vblank_count() so pass it in. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in fixup from Thierry Reding for amdgpu.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Finish the recent replacement of 'int pipe' with 'unsigned int pipe' Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-