| Age | Commit message (Collapse) | Author |
|---|
|
i915, nouveau (ever since merged to upstream) and radeon all lack ums
support in upstream. No point keeping the ums vgaarb support around.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-12-daniel.vetter@ffwll.ch
|
|
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I read a lot
of docs ...
v2: Review from Gustavo.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-6-daniel.vetter@ffwll.ch
|
|
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i
Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-apply these changes!
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-6-git-send-email-daniel.vetter@ffwll.ch
|
|
Spotted while auditing our ioctl table. Also nuke the
not-really-kerneldoc comments, we don't document internals and
definitely don't want to mislead people with the old dragons.
I think with this all the legacy ioctls now have proper drm_legacy_
prefixes.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-2-daniel.vetter@ffwll.ch
|
|
Only remaining use was in amdgpu, and trivial to convert over to
drm_crtc_vblank_* variants.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161114090255.31595-5-daniel.vetter@ffwll.ch
|
|
No one outside of drm_irq.c should ever need this. The correct way to
implement get_vblank_count for hw lacking a vblank counter is
drm_vblank_no_hw_counter. Fix this up in mtk, which is the only
offender left over.
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161114090255.31595-4-daniel.vetter@ffwll.ch
|
|
Now that all drivers are switched over to drm_crtc_vblank_on/off we
can relegate pre/post_modeset to the purely drm_irq.c internal role of
supporting old ums userspace.
As usual switch to the drm_legacy_ prefix to make it clear this is
for old drivers only.
v2: Rebase on top of Thierry's s/int crtc/unsigned int pipe/ changes.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
gcc warns about the timestamp in drm_wait_vblank being possibly
used without an initialization:
drivers/gpu/drm/drm_irq.c: In function 'drm_crtc_send_vblank_event':
drivers/gpu/drm/drm_irq.c:992:24: error: 'now.tv_usec' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpu/drm/drm_irq.c:1069:17: note: 'now.tv_usec' was declared here
drivers/gpu/drm/drm_irq.c:991:23: error: 'now.tv_sec' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This can happen if drm_vblank_count_and_time() returns 0 in its
error path. To sanitize the error case, I'm changing that function
to return a zero timestamp when it fails.
Fixes: e6ae8687a87b ("drm: idiot-proof vblank")
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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/20161017221355.1861551-6-arnd@arndb.de
|
|
It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.
Try to remedy this by documenting everything better.
v2: Type fixes Alex spotted.
v3: More typos Alex spotted.
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475229896-6047-1-git-send-email-daniel.vetter@ffwll.ch
|
|
These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...
Cc: Markus Heiser <markus.heiser@darmarit.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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.
...
|
|
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
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
Nouveau wanted this to avoid some worse conflicts when I merge that.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
