search for: vblanke

On Tue, Mar 17, 2020 at 08:40:58PM -0400, Lyude Paul wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > Add some kind of vblank workers. The interface is similar to regular > delayed works, and also allows for re-scheduling. > > Whatever hardware programming we do in the work must be fast > (must at least complete during the vblank, sometimes during

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Add some kind of vblank workers. The interface is similar to regular delayed works, and also allows for re-scheduling. Whatever hardware programming we do in the work must be fast (must at least complete during the vblank, sometimes during the first few scanlines of vblank), so we'll fire up a per-crtc high priority thread for

Oops, completely forgot to link to the work_struct version of this patch: [1] https://gitlab.freedesktop.org/lyudess/linux/-/commit/f57886aebbd9631f1ee6e61b516bf73afbfe74f4 On Fri, 2020-03-27 at 16:29 -0400, Lyude Paul wrote: > Adding Tejun to this thread per-Daniel's suggestion on IRC. > > Hi Tejun! So, I don't know what your experience with modesetting related > stuff >

Adding Tejun to this thread per-Daniel's suggestion on IRC. Hi Tejun! So, I don't know what your experience with modesetting related stuff is so I'll quickly explain some important concepts here regarding scanlines, vblanks, etc. If you already understand this, feel free to skip this next paragraph. >From the perspective of a computer, every time a computer monitor displays a new

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled

Hi Tejun! Sorry to bother you, but have you had a chance to look at any of this yet? Would like to continue moving this forward On Fri, 2020-03-27 at 16:38 -0400, Lyude Paul wrote: > Oops, completely forgot to link to the work_struct version of this patch: > > [1] > https://gitlab.freedesktop.org/lyudess/linux/-/commit/f57886aebbd9631f1ee6e61b516bf73afbfe74f4 > > On Fri,

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled

This patch series sets dev->vblank_disable_immediate = true on radeon/amdgpu-kms, nouveau-kms for nv50+, and vc4 for the real kms driver (as opposed to dispmanx firmware backed kms). All the drivers should be ready in theory, given their implementation, for fast vblank disable/enable. In practice, i have performed timing tests with my measurement equipment for all those drivers with the

...mp;dev->event_lock)); + assert_spin_locked(&dev->event_lock); + e->event.sequence = seq; e->event.tv_sec = now->tv_sec; e->event.tv_usec = now->tv_usec; @@ -985,6 +986,59 @@ static void send_vblank_event(struct drm_device *dev, } /** + * drm_arm_vblank_event - arm vblanke event after pageflip + * @dev: DRM device + * @pipe: CRTC index + * @e: the event to prepare to send + * + * A lot of drivers need to generate vblank events for the very next vblank + * interrupt. For example when the page flip interrupt happens when the page + * flip gets armed, but not when it ac...

VBLANK interrupts can be disabled immediately or with a delay, where the latter is the default. The former option can be selected by setting get_vblank_timestamp, and enabling vblank_disable_immediate in struct drm_device. The setup is only evaluated once when DRM initializes VBLANKs. Evaluating the settings on each use of vblank_disable_immediate will allow for easy integration of CRTC VBLANK

Allow the software channel to be created now, since methods for vblanking have been implemented. The instmem flush seems to be needed on fermi to prevent a race, but I enabled it on earlier cards too since they seem to be susceptible to the same race. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 9 ----

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

This fixes a deadlock inversion when vblank is enabled/disabled by drm. &dev->vblank_time_lock is always taken when the vblank state is toggled, which caused a deadlock when &event->lock was also taken during event_get/put. Solve the race by requiring that lock to change enable/disable state, and always keeping vblank on the event list. Core drm ignores unwanted vblanks, so extra

Since we'll be allocating resources for kthread_create_worker() in the next commit (which could fail and require us to clean up the mess), let's simplify the cleanup process a bit by registering a drm_vblank_init_release() action for each drm_vblank_crtc so they're still cleaned up if we fail to initialize one of them. Changes since v3: * Use drmm_add_action_or_reset() - Daniel Vetter

Hi all, the following patch fixes a race-condition in the nouveau ddx which caused frequent x-server crashes for at least 1 user under some loads when OpenGL triple-buffering is enabled, which it is by default on XOrg 1.12 and later. As a side effect, it provides a small optimization for the common case of bufferswap at next vblank. The other way to avoid the race + possible crash is to set

Complete migration of nouveau_event_get/_put from add/remove semantics to enable/disable semantics. Introduce nouveau_event_handler_install/_remove interface to add/remove non-local-scope event handlers (ie., those stored in parent containers). This change in semantics makes explicit the handler lifetime, and distinguishes "one-of" event handlers (such as gpio) from "many

Since we'll be allocating resources for kthread_create_worker() in the next commit (which could fail and require us to clean up the mess), let's simplify the cleanup process a bit by registering a drm_vblank_init_release() action for each drm_vblank_crtc so they're still cleaned up if we fail to initialize one of them. Changes since v3: * Use drmm_add_action_or_reset() - Daniel Vetter

Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before the rework to event interface, so I guess it got reintroduced. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index 7e3875d..35e526b 100644 ---

Mario Kleiner <mario.kleiner.de at gmail.com> writes: > With instantaneous high precision vblank timestamping > that updates at leading edge of vblank, the emulated > "hw vblank counter" from vblank timestamping which > increments at leading edge of vblank, and reliable > page flip execution and completion at leading edge > of vblank, we should meet the