[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJs_Fx6AVwA73eN+Rs=GAvBPD1Leq=WKG9w_2hohpzmecK_C_A@mail.gmail.com>
Date: Tue, 14 Jan 2020 08:52:43 -0800
From: Rob Clark <robdclark@...omium.org>
To: Brian Ho <brian@...ho.com>,
freedreno <freedreno@...ts.freedesktop.org>,
Rob Clark <robdclark@...omium.org>,
David Airlie <airlied@...ux.ie>,
"open list:DRM DRIVER FOR MSM ADRENO GPU"
<linux-arm-msm@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
"open list:DRM DRIVER FOR MSM ADRENO GPU"
<dri-devel@...ts.freedesktop.org>, Rob Clark <robdclark@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Kristian Kristensen <hoegsberg@...omium.org>,
Sean Paul <sean@...rly.run>
Subject: Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl
On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse <jcrouse@...eaurora.org> 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
BR,
-R
Powered by blists - more mailing lists