OpenCloudOS-Kernel/include/drm/drm_vblank.h

210 lines
6.7 KiB
C
Raw Normal View History

/*
* Copyright 2016 Intel Corp.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
#ifndef _DRM_VBLANK_H_
#define _DRM_VBLANK_H_
#include <linux/seqlock.h>
#include <linux/idr.h>
#include <linux/poll.h>
#include <drm/drm_file.h>
#include <drm/drm_modes.h>
#include <uapi/drm/drm.h>
struct drm_device;
struct drm_crtc;
/**
* struct drm_pending_vblank_event - pending vblank event tracking
*/
struct drm_pending_vblank_event {
/**
* @base: Base structure for tracking pending DRM events.
*/
struct drm_pending_event base;
/**
* @pipe: drm_crtc_index() of the &drm_crtc this event is for.
*/
unsigned int pipe;
/**
* @sequence: frame event should be triggered at
*/
u64 sequence;
/**
* @event: Actual event which will be sent to userspace.
*/
union {
/**
* @event.base: DRM event base class.
*/
struct drm_event base;
/**
* @event.vbl:
*
* Event payload for vblank events, requested through
* either the MODE_PAGE_FLIP or MODE_ATOMIC IOCTL. Also
* generated by the legacy WAIT_VBLANK IOCTL, but new userspace
* should use MODE_QUEUE_SEQUENCE and &event.seq instead.
*/
struct drm_event_vblank vbl;
/**
* @event.seq: Event payload for the MODE_QUEUEU_SEQUENCE IOCTL.
*/
drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3] These provide crtc-id based functions instead of pipe-number, while also offering higher resolution time (ns) and wider frame count (64) as required by the Vulkan API. v2: * Check for DRIVER_MODESET in new crtc-based vblank ioctls Failing to check this will oops the driver. * Ensure vblank interupt is running in crtc_get_sequence ioctl The sequence and timing values are not correct while the interrupt is off, so make sure it's running before asking for them. * Short-circuit get_sequence if the counter is enabled and accurate Steal the idea from the code in wait_vblank to avoid the expense of drm_vblank_get/put * Return active state of crtc in crtc_get_sequence ioctl Might be useful for applications that aren't in charge of modesetting? * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls Daniel Vetter prefers these over the old drm_vblank_put/get APIs. * Return s64 ns instead of u64 in new sequence event Suggested-by: Daniel Vetter <daniel@ffwll.ch> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> v3: * Removed FIRST_PIXEL_OUT_FLAG * Document that the timestamp in the query and event are that of the first pixel leaving the display engine for the display (using the same wording as the Vulkan spec). Suggested-by: Michel Dänzer <michel@daenzer.net> Acked-by: Dave Airlie <airlied@redhat.com> [airlied: left->leaves (Michel)] Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-06-30 13:49:31 +08:00
struct drm_event_crtc_sequence seq;
} event;
};
/**
* struct drm_vblank_crtc - vblank tracking for a CRTC
*
* This structure tracks the vblank state for one CRTC.
*
* Note that for historical reasons - the vblank handling code is still shared
* with legacy/non-kms drivers - this is a free-standing structure not directly
* connected to &struct drm_crtc. But all public interface functions are taking
* a &struct drm_crtc to hide this implementation detail.
*/
struct drm_vblank_crtc {
/**
* @dev: Pointer to the &drm_device.
*/
struct drm_device *dev;
/**
* @queue: Wait queue for vblank waiters.
*/
wait_queue_head_t queue;
/**
* @disable_timer: Disable timer for the delayed vblank disabling
* hysteresis logic. Vblank disabling is controlled through the
* drm_vblank_offdelay module option and the setting of the
* &drm_device.max_vblank_count value.
*/
struct timer_list disable_timer;
/**
* @seqlock: Protect vblank count and time.
*/
seqlock_t seqlock;
/**
* @count: Current software vblank counter.
*/
u64 count;
/**
* @time: Vblank timestamp corresponding to @count.
*/
drm: vblank: use ktime_t instead of timeval The drm vblank handling uses 'timeval' to store timestamps in either monotonic or wall-clock time base. In either case, it reads the current time as a ktime_t in get_drm_timestamp() and converts it from there. This is a bit suspicious, as users of 'timeval' often suffer from the time_t overflow in y2038. I have gone through this code and found that it is unlikely to cause problems here: - The user space ABI does not use time_t or timeval, but uses 'u32' and 'long' as the types. This means at least that rebuilding user programs against a new libc with 64-bit time_t does not change the ABI. - As of commit c61eef726a78 ("drm: add support for monotonic vblank timestamps") in linux-3.8, the monotonic timestamp is the default and can only get reverted to wall-clock through a module-parameter. - With the default monotonic timestamps, there is no problem at all. - The drm_wait_vblank_ioctl() interface is alway safe on 64-bit architectures, on 32-bit it might overflow the 'long' timestamps in 2038 with wall-clock timestamps. - The event handling uses 'u32' seconds, which overflow in 2106 on both 32-bit and 64-bit machines, when wall-clock timestamps are used. - The effect of overflowing either of the two is only temporary (during the overflow, and is likely to keep working again afterwards. It is likely the same problem as observing a 'settimeofday()' call, which was the reason for moving to the monotonic timestamps in the first place. Overall, this seems good enough, so my patch removes the use of 'timeval' from the vblank handling altogether and uses ktime_t consistently, except for the part where we copy the data to user space structures in the existing format. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-10-11 23:20:12 +08:00
ktime_t time;
/**
* @refcount: Number of users/waiters of the vblank interrupt. Only when
* this refcount reaches 0 can the hardware interrupt be disabled using
* @disable_timer.
*/
atomic_t refcount;
/**
* @last: Protected by &drm_device.vbl_lock, used for wraparound handling.
*/
u32 last;
/**
* @inmodeset: Tracks whether the vblank is disabled due to a modeset.
* For legacy driver bit 2 additionally tracks whether an additional
* temporary vblank reference has been acquired to paper over the
* hardware counter resetting/jumping. KMS drivers should instead just
* call drm_crtc_vblank_off() and drm_crtc_vblank_on(), which explicitly
* save and restore the vblank count.
*/
unsigned int inmodeset;
/**
* @pipe: drm_crtc_index() of the &drm_crtc corresponding to this
* structure.
*/
unsigned int pipe;
/**
* @framedur_ns: Frame/Field duration in ns, used by
* drm_calc_vbltimestamp_from_scanoutpos() and computed by
* drm_calc_timestamping_constants().
*/
int framedur_ns;
/**
* @linedur_ns: Line duration in ns, used by
* drm_calc_vbltimestamp_from_scanoutpos() and computed by
* drm_calc_timestamping_constants().
*/
int linedur_ns;
/**
* @hwmode:
*
* Cache of the current hardware display mode. Only valid when @enabled
* is set. This is used by helpers like
* drm_calc_vbltimestamp_from_scanoutpos(). We can't just access the
* hardware mode by e.g. looking at &drm_crtc_state.adjusted_mode,
* because that one is really hard to get from interrupt context.
*/
struct drm_display_mode hwmode;
/**
* @enabled: Tracks the enabling state of the corresponding &drm_crtc to
* avoid double-disabling and hence corrupting saved state. Needed by
* drivers not using atomic KMS, since those might go through their CRTC
* disabling functions multiple times.
*/
bool enabled;
};
int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
u64 drm_crtc_vblank_count(struct drm_crtc *crtc);
u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
drm: vblank: use ktime_t instead of timeval The drm vblank handling uses 'timeval' to store timestamps in either monotonic or wall-clock time base. In either case, it reads the current time as a ktime_t in get_drm_timestamp() and converts it from there. This is a bit suspicious, as users of 'timeval' often suffer from the time_t overflow in y2038. I have gone through this code and found that it is unlikely to cause problems here: - The user space ABI does not use time_t or timeval, but uses 'u32' and 'long' as the types. This means at least that rebuilding user programs against a new libc with 64-bit time_t does not change the ABI. - As of commit c61eef726a78 ("drm: add support for monotonic vblank timestamps") in linux-3.8, the monotonic timestamp is the default and can only get reverted to wall-clock through a module-parameter. - With the default monotonic timestamps, there is no problem at all. - The drm_wait_vblank_ioctl() interface is alway safe on 64-bit architectures, on 32-bit it might overflow the 'long' timestamps in 2038 with wall-clock timestamps. - The event handling uses 'u32' seconds, which overflow in 2106 on both 32-bit and 64-bit machines, when wall-clock timestamps are used. - The effect of overflowing either of the two is only temporary (during the overflow, and is likely to keep working again afterwards. It is likely the same problem as observing a 'settimeofday()' call, which was the reason for moving to the monotonic timestamps in the first place. Overall, this seems good enough, so my patch removes the use of 'timeval' from the vblank handling altogether and uses ktime_t consistently, except for the part where we copy the data to user space structures in the existing format. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-10-11 23:20:12 +08:00
ktime_t *vblanktime);
void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
struct drm_pending_vblank_event *e);
void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
struct drm_pending_vblank_event *e);
void drm_vblank_set_event(struct drm_pending_vblank_event *e,
u64 *seq,
ktime_t *now);
bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
int drm_crtc_vblank_get(struct drm_crtc *crtc);
void drm_crtc_vblank_put(struct drm_crtc *crtc);
void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe);
void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
void drm_crtc_vblank_off(struct drm_crtc *crtc);
void drm_crtc_vblank_reset(struct drm_crtc *crtc);
void drm_crtc_vblank_on(struct drm_crtc *crtc);
u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
void drm_vblank_restore(struct drm_device *dev, unsigned int pipe);
void drm_crtc_vblank_restore(struct drm_crtc *crtc);
bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
unsigned int pipe, int *max_error,
drm: vblank: use ktime_t instead of timeval The drm vblank handling uses 'timeval' to store timestamps in either monotonic or wall-clock time base. In either case, it reads the current time as a ktime_t in get_drm_timestamp() and converts it from there. This is a bit suspicious, as users of 'timeval' often suffer from the time_t overflow in y2038. I have gone through this code and found that it is unlikely to cause problems here: - The user space ABI does not use time_t or timeval, but uses 'u32' and 'long' as the types. This means at least that rebuilding user programs against a new libc with 64-bit time_t does not change the ABI. - As of commit c61eef726a78 ("drm: add support for monotonic vblank timestamps") in linux-3.8, the monotonic timestamp is the default and can only get reverted to wall-clock through a module-parameter. - With the default monotonic timestamps, there is no problem at all. - The drm_wait_vblank_ioctl() interface is alway safe on 64-bit architectures, on 32-bit it might overflow the 'long' timestamps in 2038 with wall-clock timestamps. - The event handling uses 'u32' seconds, which overflow in 2106 on both 32-bit and 64-bit machines, when wall-clock timestamps are used. - The effect of overflowing either of the two is only temporary (during the overflow, and is likely to keep working again afterwards. It is likely the same problem as observing a 'settimeofday()' call, which was the reason for moving to the monotonic timestamps in the first place. Overall, this seems good enough, so my patch removes the use of 'timeval' from the vblank handling altogether and uses ktime_t consistently, except for the part where we copy the data to user space structures in the existing format. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-10-11 23:20:12 +08:00
ktime_t *vblank_time,
bool in_vblank_irq);
void drm_calc_timestamping_constants(struct drm_crtc *crtc,
const struct drm_display_mode *mode);
wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc);
#endif