kernel/linux.git/drivers/gpu/drm/drm_vblank.c, branch v5.10.264

drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()

2020-09-14T19:37:31+00:00

The timestamping constants have nothing to do with any legacy state so should not be updated from drm_atomic_helper_update_legacy_modeset_state(). Let's make everyone call drm_atomic_helper_calc_timestamping_constants() directly instead of relying on drm_atomic_helper_update_legacy_modeset_state() to call it. @@ expression S; @@ - drm_atomic_helper_calc_timestamping_constants(S); @@ expression D, S; @@ drm_atomic_helper_update_legacy_modeset_state(D, S); + drm_atomic_helper_calc_timestamping_constants(S); v2: Update drm_crtc_vblank_helper_get_vblank_timestamp{,_internal}() docs (Daniel) Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200907120026.6360-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter

drm/vblank: Use spin_(un)lock_irq() in drm_crtc_queue_sequence_ioctl()

2020-07-21T15:08:35+00:00

This is an ioctl callback, so we're guaranteed to have IRQs enabled when calling this function. Use the plain _irq() variants of spin_(un)lock() to make this more obvious. Signed-off-by: Lyude Paul Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-6-lyude@redhat.com Reviewed-by: Daniel Vetter

drm/vblank: Use spin_(un)lock_irq() in drm_queue_vblank_event()

2020-07-21T15:08:04+00:00

This one's easy - we're already calling kzalloc(GFP_KERNEL) in this function, so we must already be guaranteed to have IRQs enabled when calling this. So, use the plain _irq() variants of spin_(un)lock() to make this more obvious. Signed-off-by: Lyude Paul Cc: Daniel Vetter Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-5-lyude@redhat.com

drm/vblank: Use spin_(un)lock_irq() in drm_legacy_vblank_post_modeset()

2020-07-21T15:08:04+00:00

This function is only ever called from ioctl context, so we're guaranteed to have interrupts enabled. Stop using the irqsave/irqrestore variants of spin_(un)lock_irq() to make this more obvious. Signed-off-by: Lyude Paul Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-4-lyude@redhat.com Reviewed-by: Daniel Vetter

drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_on()

2020-07-21T15:08:03+00:00

This is only called from: * Atomic modesetting hooks * Module probing routines * Legacy modesetting hooks All of which have IRQs enabled, so we can also get rid of irqsave/restore here to make the IRQ context of this function more obvious. Signed-off-by: Lyude Paul Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-3-lyude@redhat.com Reviewed-by: Daniel Vetter

drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_reset()

2020-07-21T15:08:03+00:00

All of the drivers in the kernel tree only call this from one of the following contexts: * drm_crtc_funcs->reset * During initial module load Since both of these contexts are guaranteed to have interrupts enabled beforehand, there's no need to use the irqsave/irqrestore variants of spin_(un)lock(). So, fix this to make the irq context of this function more obvious. Signed-off-by: Lyude Paul Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-2-lyude@redhat.com Reviewed-by: Daniel Vetter

drm/vblank: Add vblank works

2020-07-16T22:16:31+00:00

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 - whichever comes first. Whatever hardware programming we do in the work must be fast (must at least complete during the vblank or scanout period, sometimes during the first few scanlines of the vblank). As such we use a high-priority per-CRTC thread to accomplish this. Changes since v7: * Stuff drm_vblank_internal.h and drm_vblank_work_internal.h contents into drm_internal.h * Get rid of unnecessary spinlock in drm_crtc_vblank_on() * Remove !vblank->worker check * Grab vbl_lock in drm_vblank_work_schedule() * Mention self-rearming work items in drm_vblank_work_schedule() kdocs * Return 1 from drm_vblank_work_schedule() if the work was scheduled successfully, 0 or error code otherwise * Use drm_dbg_core() instead of DRM_DEV_ERROR() in drm_vblank_work_schedule() * Remove vblank->worker checks in drm_vblank_destroy_worker() and drm_vblank_flush_worker() Changes since v6: * Get rid of ->pending and seqcounts, and implement flushing through simpler means - danvet * Get rid of work_lock, just use drm_device->event_lock * Move drm_vblank_work item cleanup into drm_crtc_vblank_off() so that we ensure that all vblank work has finished before disabling vblanks * Add checks into drm_crtc_vblank_reset() so we yell if it gets called while there's vblank workers active * Grab event_lock in both drm_crtc_vblank_on()/drm_crtc_vblank_off(), the main reason for this is so that other threads calling drm_vblank_work_schedule() are blocked from attempting to schedule while we're in the middle of enabling/disabling vblanks. * Move drm_handle_vblank_works() call below drm_handle_vblank_events() * Simplify drm_vblank_work_cancel_sync() * Fix drm_vblank_work_cancel_sync() documentation * Move wake_up_all() calls out of spinlock where we can. The only one I left was the call to wake_up_all() in drm_vblank_handle_works() as this seemed like it made more sense just living in that function (which is all technically under lock) * Move drm_vblank_work related functions into their own source files * Add drm_vblank_internal.h so we can export some functions we don't want drivers using, but that we do need to use in drm_vblank_work.c * Add a bunch of documentation Changes since v4: * Get rid of kthread interfaces we tried adding and move all of the locking into drm_vblank.c. For implementing drm_vblank_work_flush(), we now use a wait_queue and sequence counters in order to differentiate between multiple work item executions. * Get rid of drm_vblank_work_cancel() - this would have been pretty difficult to actually reimplement and it occurred to me that neither nouveau or i915 are even planning to use this function. Since there's also no async cancel function for most of the work interfaces in the kernel, it seems a bit unnecessary anyway. * Get rid of to_drm_vblank_work() since we now are also able to just pass the struct drm_vblank_work to work item callbacks anyway Changes since v3: * Use our own spinlocks, don't integrate so tightly with kthread_works Changes since v2: * Use kthread_workers instead of reinventing the wheel. Cc: Tejun Heo Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Reviewed-by: Daniel Vetter Co-developed-by: Ville Syrjälä Signed-off-by: Lyude Paul Acked-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-4-lyude@redhat.com

drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_off()

2020-07-16T22:16:31+00:00

This got me confused for a bit while looking over this code: I had been planning on adding some blocking function calls into this function, but seeing the irqsave/irqrestore variants of spin_(un)lock() didn't make it very clear whether or not that would actually be safe. So I went ahead and reviewed every single driver in the kernel that uses this function, and they all fall into three categories: * Driver probe code * ->atomic_disable() callbacks * Legacy modesetting callbacks All of these will be guaranteed to have IRQs enabled, which means it's perfectly safe to block here. Just to make things a little less confusing to others in the future, let's switch over to spin_lock_irq()/spin_unlock_irq() to make that fact a little more obvious. Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: Ville Syrjälä Acked-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-3-lyude@redhat.com

drm/vblank: Register drmm cleanup action once per drm_vblank_crtc

2020-07-16T22:16:01+00:00

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 Cc: Ville Syrjälä Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Reviewed-by: Daniel Vetter Signed-off-by: Lyude Paul Acked-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-2-lyude@redhat.com

drm : Insert blank lines after declarations.

2020-07-02T13:26:00+00:00

Resolve checkpatch issues for missing blank lines after declarations. Issues found in multiple files with checkpatch.pl. Signed-off-by: Suraj Upadhyay Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200702131749.GA25710@blackclown