On Tue, Jan 14, 2020 at 9:23 AM Jordan Crouse <jcrouse@xxxxxxxxxxxxxx> wrote: > > On Tue, Jan 14, 2020 at 08:52:43AM -0800, Rob Clark wrote: > > On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse <jcrouse@xxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Jan 13, 2020 at 10:36:05AM -0500, Brian Ho wrote: > > > > + > > > > + vaddr = base_vaddr + args->offset; > > > > + > > > > + /* Assumes WC mapping */ > > > > + ret = wait_event_interruptible_timeout( > > > > + gpu->event, *vaddr >= args->value, remaining_jiffies); > > > > > > I feel like a barrier might be needed before checking *vaddr just in case you > > > get the interrupt and wake up the queue before the write posts from the > > > hardware. > > > > > > > if the gpu is doing posted (or cached) writes, I don't think there is > > even a CPU side barrier primitive that could wait for that? I think > > we rely on the GPU not interrupting the CPU until the write is posted > > Once the GPU puts the write on the bus then it is up to the whims of the CPU > architecture. If the writes are being done out of order you run a chance of > firing the interrupt and making it all the way to your handler before the writes > catch up. > > Since you are scheduling and doing a bunch of things in between you probably > don't need to worry but if you start missing events and you don't know why then > this could be why. A rmb() would give you piece of mind at the cost of being > Yet Another Barrier (TM). Doesn't the fence case do the same thing without a barrier? > Jordan > > > BR, > > -R > > _______________________________________________ > > Freedreno mailing list > > Freedreno@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/freedreno > > -- > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project
