similar to: VBlank

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

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,

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 >

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

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

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

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

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

Op 30-07-13 04:42, Ben Skeggs schreef: > On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> 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. > I don't know how/why you think this fixes anything. The interrupt >

On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > 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. I don't know how/why you think this fixes anything. The interrupt handler can't possibly be called until after priv->base.vblank has

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 ----

All non-legacy users of VBLANK functions in struct drm_driver have been converted to use the respective interfaces in struct drm_crtc_funcs. The remaining users of VBLANK callbacks in struct drm_driver are legacy drivers with userspace modesetting. There are no users left of get_vblank_timestamp(), so the callback is being removed. The other VBLANK callbacks are being moved to the legacy section

On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote: > I believe the solution is to not call drm_crtc_vblank_off for atomic > modesetting in nouveau_display_fini. I think Ben's working on it. Yes, the goal of vblank_on/off was very much to not paper over driver bugs with clever tricks like these. If the driver cant keep track of its vblank, something has gone wrong, and the core

mimic the behavior of vblank_disable_fn(), another caller of drm_vblank_disable_and_save(). This avoids oopsing, while trying to disable vblank on a not connected display: [ 12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm] [ 12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc uvcvideo rtsx_usb_ms

On 08/12/2013 07:50 AM, Maarten Lankhorst wrote: > 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

On Thu, Jul 20, 2017 at 11:58 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Mh ok, > > paper over in nouveau_display_fini until Ben comes up with a better idea > then?! No paper needed, just don't call drm_vblank_off for the atomic case. Not sure why that patch isn't landed yet, it should be simple. -Daniel > > Greetings, > > Tobias

I compiled correctly WINE (last version) on my Solaris 8 host and it's seems work properly. I'm trying to installa Access 97 but the installation fails with problems copying file with names ~* on the TEMP directory. Jean-Claude Gervais wrote: > Hi, > > I've got a machine running Solaris 8.0 that I would like to run Wine on. > > I know that work has been done

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 ---

On Mon, 2020-04-13 at 16:42 -0400, Tejun Heo wrote: > Hello, > > On Mon, Apr 13, 2020 at 04:18:57PM -0400, Lyude Paul wrote: > > 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 > > Sorry, wasn't following this thread. Have you looked at kthread_worker? > Hi, thanks for the