Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Daniel Vetter writes: > I'd drop that part (but keep 64 everywhere else ofc). Yeah, we only ever ask drivers for a delta anyways, so keeping an internal 64-bit value while retaining the 32-bit driver API is easy to manage. >> > Other thought on this, since you bother to change

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On Thu, Jul 06, 2017 at 07:59:51AM -0700, Keith Packard wrote: > Daniel Vetter writes: > > > Extending the reported/sw vblank counter to u64 makes sense imo, but do we > > have to extend the driver interfaces too? If there's no 64 bit hw vblank > > currently I think I'd be good

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 07/07/17 10:34 AM, Michel Dänzer wrote: > On 07/07/17 12:04 AM, Keith Packard wrote: >> Michel Dänzer writes: >> @@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev) if (!dev_priv) return -EINVAL; + if

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 07/07/17 12:04 AM, Keith Packard wrote: > Michel Dänzer writes: > >>> @@ -317,6 +317,9 @@ int via_driver_irq_postinstall(struct drm_device *dev) >>> if (!dev_priv) >>> return -EINVAL; >>> >>> + if (dev->driver->get_vblank_counter) >>> +

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > BTW, this got me thinking that we should probably treat > _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating > vblwait->request.sequence. Otherwise there could theoretically (though > unlikely) be an infinite loop: I was thinking

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > Subtle breakage here: vblwait->request.sequence must still get updated > for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal. Thanks for finding this. I think it might be better to just not modify the request.type field instead, so that

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Daniel Vetter writes: > Extending the reported/sw vblank counter to u64 makes sense imo, but do we > have to extend the driver interfaces too? If there's no 64 bit hw vblank > currently I think I'd be good to postpone that part, simply because I'm > too lazy to audit all the

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 06/07/17 04:45 PM, Michel Dänzer wrote: > On 06/07/17 07:10 AM, Keith Packard wrote: >> This modifies the datatypes used by the vblank code to provide both 64 >> bits of vblank count and to increase the resolution of the vblank >> timestamp from microseconds to nanoseconds. >> >> The driver

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 06/07/17 07:10 AM, Keith Packard wrote: > This modifies the datatypes used by the vblank code to provide both 64 > bits of vblank count and to increase the resolution of the vblank > timestamp from microseconds to nanoseconds. > > The driver interfaces have also been changed to return 64-bits

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On Wed, Jul 05, 2017 at 03:10:11PM -0700, Keith Packard wrote: > This modifies the datatypes used by the vblank code to provide both 64 > bits of vblank count and to increase the resolution of the vblank > timestamp from microseconds to nanoseconds. > > The driver interfaces have also been

[PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

This modifies the datatypes used by the vblank code to provide both 64 bits of vblank count and to increase the resolution of the vblank timestamp from microseconds to nanoseconds. The driver interfaces have also been changed to return 64-bits of vblank count; fortunately all of the code