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 all the types: Af
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 to postpone that p
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 (dev->driver->get_vblank_coun
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)
>>> + dev->max_vblank_count = 0xf
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 that we should just r
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 on re-entry it gets re
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 drivers for correctly
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 inte
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 o
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 changed
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 necessary
11 matches
Mail list logo
