Daniel Vetter <daniel@xxxxxxxx> 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 setting max_vblank_count > after your change :-) As I said, it's easy enough to do that; I figured I'd do the obvious part and let you decide if you wanted that or not. We could also set max_vblank_count to 0xffffffff if it wasn't set by the driver, and/or add a WARN_ON_ONCE if it wasn't set. Given that it takes over two years to wrap this counter at 60Hz, we're never likely to hit a bug in testing. Let me know what you think; I'm not invested in any particular solution at this point. > Other thought on this, since you bother to change all the types: Afaik > both timespec and timeval suffer from the 32bit issues. I'm not sure what 32bit issues you're concerned about here? We don't compare these values, just report them up to user space. > If we bother with changing everything I think it'd be neat to switch > all internal interfaces over to ktime, and only convert to the > userspace types once when we generate the event. I think that's how > cool hackers are supposed to do it, but not fully sure. Yeah, I can definitely get behind that plan. A simple 64-bit value instead of a struct with two semi-related values which are hard to do arithmetic on. > Otherwise looks all good, but haven't yet carefully hunted for fumbles in > review before the above is clear. Thanks. I'll switch over to ktime and wait to hear what your thoughts are on the vblank count interface changes. -- -keith
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
