On Thu, Jul 31, 2014 at 10:56 AM, Michel Dänzer michel@daenzer.net wrote:
On 31.07.2014 16:54, Daniel Vetter wrote:
On Thu, Jul 31, 2014 at 3:14 AM, Michel Dänzer michel@daenzer.net 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