On Sat, Aug 11, 2012 at 2:22 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> >> + >> >> +/** >> >> + * dma_fence_wait - wait for a fence to be signaled >> >> + * >> >> + * @fence: [in] The fence to wait on >> >> + * @intr: [in] if true, do an interruptible wait >> >> + * @timeout: [in] absolute time for timeout, in jiffies. >> > >> > I don't quite like this, I think we should keep the styl of all other >> > wait_*_timeout functions and pass the arg as timeout in jiffies (and also >> > the same return semantics). Otherwise well have funny code that needs to >> > handle return values differently depending upon whether it waits upon a >> > dma_fence or a native object (where it would us the wait_*_timeout >> > functions directly). >> >> We did start out this way, but there was an ugly jiffies roll-over >> problem that was difficult to deal with properly. Using an absolute >> time avoided the problem. > > Well, as-is the api works differently than all the other _timeout apis > I've seen in the kernel, which makes it confusing. Also, I don't quite see > what jiffies wraparound issue there is? iirc, the problem was in dmabufmgr, in dmabufmgr_wait_completed_cpu().. with an absolute timeout, it could loop over all the fences without having to adjust the timeout for the elapsed time. Otherwise it had to adjust the timeout and keep track of when the timeout elapsed without confusing itself via rollover. BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
