On Tue, Dec 09, 2025 at 12:05:31PM +0200, Jani Nikula wrote: > On Mon, 01 Dec 2025, <[email protected]> wrote: > > From: Leo Li <[email protected]> > > > > Some drivers need to perform blocking operations prior to enabling > > vblank interrupts. A display hardware spin-up from a low-power state > > that requires synchronization with the rest of the driver via a mutex, > > for example. > > > > To support this, introduce a new drm_crtc_vblank_prepare() helper that > > calls back into the driver -- if implemented -- for the driver to do > > such preparation work. > > > > In DRM core, call this helper before drm_vblank_get(). Drivers can > > choose to call this if they implement the callback in the future. > > Have you considered hiding all of this inside drm_vblank.c? Call prepare > in drm_crtc_vblank_get() and a couple of other places? And actually > don't call it on !drm_dev_has_vblank(dev)? > > There's just so much littering all over the place with the prepare, and > it seems brittle. Especially when you expect not only the drm core but > also the relevant drivers to call drm_crtc_vblank_prepare() when needed. > > There does seem to be a few places in amdgpu that wrap the > drm_crtc_vblank_get() inside dev->event_lock, but is there really any > need to do so? Do the get first, and grab the event_lock after? > > Some random comments inline. > > Cc: Ville
drm_vblank_get() can get called from any kind of context. The only workable solution might be the schedule a work from .vblank_enable() and do whatever is needed from there. -- Ville Syrjälä Intel
