On Thu, Jul 31, 2014 at 10:56 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: > On 31.07.2014 16:54, Daniel Vetter wrote: >> On Thu, Jul 31, 2014 at 3:14 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: >>> I think it would be better to refactor drm_wait_vblank() than to >>> reinvent it. >> >> That's the ioctl implementation which spends most of its time decoding >> ioctl structures. If we take that out then there's about half a line >> which would be shared (since a lot of the stuff in there is ums gunk >> that we don't want to carry over to a kms-only internal interface). So >> imo that doesn't make sense. > > I'm referring to the core logic of waiting for a number of vblank > periods or until the vblank period with a given sequence number, dealing > with wraparound etc. The issues you guys were discussing for a new > function were ironed out there long ago. I'm referering to the same, but that logic is gunked up with special-cases for UMS and absolute vblank waits and all kinds of other stuff, so that sharing this with a kms helper to wait a few vblanks (so relative only) really doesn't buy us all that much. Actually I think you'll be left with nothing shared since for the kms driver-internal functions really shouldn't have all these hacks to paper over races and other issues (like ums shutting down the pipe while we didn't look). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
