From: Daniel Vetter <daniel.vetter@ffwll.ch> To: Rob Clark <robdclark@gmail.com> Cc: "DRI Development" <dri-devel@lists.freedesktop.org>, "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "Rob Clark" <robdclark@chromium.org>, "Sean Paul" <sean@poorly.run>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Christian König" <christian.koenig@amd.com>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, freedreno <freedreno@lists.freedesktop.org>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org>, "moderated list:DMA BUFFER SHARING FRAMEWORK" <linaro-mm-sig@lists.linaro.org>, "Daniel Vetter" <daniel.vetter@intel.com> Subject: Re: [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules Date: Fri, 6 Aug 2021 20:41:47 +0200 [thread overview] Message-ID: <CAKMK7uH2v2x+=Ct-v-2RCVXez4MzjMvhh4yCs_f8HPvYa+DXcA@mail.gmail.com> (raw) In-Reply-To: <CAF6AEGuqxb5jEtpQi-aNvjSfPaq0gasH2TLZ+5O836ov9qw+3w@mail.gmail.com> On Fri, Aug 6, 2021 at 7:15 PM Rob Clark <robdclark@gmail.com> wrote: > > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark <robdclark@gmail.com> wrote: > > > > > > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > > > > > Originally drm_sched_job_init was the point of no return, after which > > > > drivers must submit a job. I've split that up, which allows us to fix > > > > this issue pretty easily. > > > > > > > > Only thing we have to take care of is to not skip to error paths after > > > > that. Other drivers do this the same for out-fence and similar things. > > > > > > > > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") > > > > Cc: Rob Clark <robdclark@chromium.org> > > > > Cc: Rob Clark <robdclark@gmail.com> > > > > Cc: Sean Paul <sean@poorly.run> > > > > Cc: Sumit Semwal <sumit.semwal@linaro.org> > > > > Cc: "Christian König" <christian.koenig@amd.com> > > > > Cc: linux-arm-msm@vger.kernel.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: freedreno@lists.freedesktop.org > > > > Cc: linux-media@vger.kernel.org > > > > Cc: linaro-mm-sig@lists.linaro.org > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > > > --- > > > > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++++++-------- > > > > 1 file changed, 7 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c > > > > index 6d6c44f0e1f3..d0ed4ddc509e 100644 > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > > > > @@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct drm_device *dev, > > > > return ERR_PTR(ret); > > > > } > > > > > > > > - /* FIXME: this is way too early */ > > > > - drm_sched_job_arm(&job->base); > > > > - > > > > xa_init_flags(&submit->deps, XA_FLAGS_ALLOC); > > > > > > > > kref_init(&submit->ref); > > > > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, > > > > > > > > submit->user_fence = dma_fence_get(&submit->base.s_fence->finished); > > > > > > > > + /* point of no return, we _have_ to submit no matter what */ > > > > + drm_sched_job_arm(&submit->base); > > > > + > > > > /* > > > > * Allocate an id which can be used by WAIT_FENCE ioctl to map back > > > > * to the underlying fence. > > > > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, > > > > if (submit->fence_id < 0) { > > > > ret = submit->fence_id = 0; > > > > submit->fence_id = 0; > > > > - goto out; > > > > } > > > > > > > > - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) { > > > > + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) { > > > > struct sync_file *sync_file = sync_file_create(submit->user_fence); > > > > if (!sync_file) { > > > > ret = -ENOMEM; > > > > - goto out; > > > > + } else { > > > > + fd_install(out_fence_fd, sync_file->file); > > > > + args->fence_fd = out_fence_fd; > > > > } > > > > - fd_install(out_fence_fd, sync_file->file); > > > > - args->fence_fd = out_fence_fd; > > > > > > I wonder if instead we should (approximately) undo "drm/msm/submit: > > > Simplify out-fence-fd handling" so that the point that it could fail > > > is moved up ahead of the drm_sched_job_arm()? > > > > Hm yeah. Up to you how you want to paint this shed, I think either is fine. > > > > > Also, does the dma_fence_get() work before drm_sched_job_arm()? From > > > a quick look, it looks like it won't, but I'm still playing catchup > > > and haven't had a chance to look at your entire series. If it doesn't > > > work before drm_sched_job_arm(), then there is really no way to > > > prevent a error path between the fence-init and job-submit. > > > > Yes. I thought I've checked that I put the _arm() in the right spot, > > but I guess I screwed up and you need the fence before the point where > > I've put the job_arm()? And yes the error path cannot be avoided for > > out-fences, that's what I tried to explain in the commit message. > > > > > But, prior to your series, wouldn't a failure after > > > drm_sched_job_init() but before the job is submitted just burn a > > > fence-id, and otherwise carry on it's merry way? > > > > Maybe? I'm not sure whether the scheduler gets confused about the gap > > and freak out abou that. I'm fairly new to that code and learning > > (which is part why I'm working on it). Since you look up in > > fences/syncobj after job_init() it should be pretty easy to whip up a > > testcase and see what happens. Also as long as nothing fails you won't > > see an issue, that's for sure. > > fair.. I'll try to come up with a test case.. pre-scheduler-conversion > it wasn't a problem to fail after the fence seqno was allocated (well, > I guess you might have problems if you had 2^31 failures in a row) Yeah one thing drm/sched forces you to do is have a very clear notion about the point of no return in your submit ioctl. Which I think is a Very Good Thing, at least looking at i915 execbuf where the point of no return is a multi-stage thing with such interesting intermediate points like "we submit the ruquest but without actually running the batchbuffer". The downside is that the submit ioctl isn't perfectly transaction anymore, but I don't think that matters for tha tail stuff, which is generally just some out-fence installing. That generally never fails. -Daniel > > BR, > -R > > > -Daniel > > > > > BR, > > > -R > > > > > > > } > > > > > > > > submit_attach_object_fences(submit); > > > > -- > > > > 2.32.0 > > > > > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch> To: Rob Clark <robdclark@gmail.com> Cc: "DRI Development" <dri-devel@lists.freedesktop.org>, "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "Rob Clark" <robdclark@chromium.org>, "Sean Paul" <sean@poorly.run>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Christian König" <christian.koenig@amd.com>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, freedreno <freedreno@lists.freedesktop.org>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org>, "moderated list:DMA BUFFER SHARING FRAMEWORK" <linaro-mm-sig@lists.linaro.org>, "Daniel Vetter" <daniel.vetter@intel.com> Subject: Re: [Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules Date: Fri, 6 Aug 2021 20:41:47 +0200 [thread overview] Message-ID: <CAKMK7uH2v2x+=Ct-v-2RCVXez4MzjMvhh4yCs_f8HPvYa+DXcA@mail.gmail.com> (raw) In-Reply-To: <CAF6AEGuqxb5jEtpQi-aNvjSfPaq0gasH2TLZ+5O836ov9qw+3w@mail.gmail.com> On Fri, Aug 6, 2021 at 7:15 PM Rob Clark <robdclark@gmail.com> wrote: > > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark <robdclark@gmail.com> wrote: > > > > > > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > > > > > Originally drm_sched_job_init was the point of no return, after which > > > > drivers must submit a job. I've split that up, which allows us to fix > > > > this issue pretty easily. > > > > > > > > Only thing we have to take care of is to not skip to error paths after > > > > that. Other drivers do this the same for out-fence and similar things. > > > > > > > > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") > > > > Cc: Rob Clark <robdclark@chromium.org> > > > > Cc: Rob Clark <robdclark@gmail.com> > > > > Cc: Sean Paul <sean@poorly.run> > > > > Cc: Sumit Semwal <sumit.semwal@linaro.org> > > > > Cc: "Christian König" <christian.koenig@amd.com> > > > > Cc: linux-arm-msm@vger.kernel.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: freedreno@lists.freedesktop.org > > > > Cc: linux-media@vger.kernel.org > > > > Cc: linaro-mm-sig@lists.linaro.org > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > > > --- > > > > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++++++-------- > > > > 1 file changed, 7 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c > > > > index 6d6c44f0e1f3..d0ed4ddc509e 100644 > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > > > > @@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct drm_device *dev, > > > > return ERR_PTR(ret); > > > > } > > > > > > > > - /* FIXME: this is way too early */ > > > > - drm_sched_job_arm(&job->base); > > > > - > > > > xa_init_flags(&submit->deps, XA_FLAGS_ALLOC); > > > > > > > > kref_init(&submit->ref); > > > > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, > > > > > > > > submit->user_fence = dma_fence_get(&submit->base.s_fence->finished); > > > > > > > > + /* point of no return, we _have_ to submit no matter what */ > > > > + drm_sched_job_arm(&submit->base); > > > > + > > > > /* > > > > * Allocate an id which can be used by WAIT_FENCE ioctl to map back > > > > * to the underlying fence. > > > > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, > > > > if (submit->fence_id < 0) { > > > > ret = submit->fence_id = 0; > > > > submit->fence_id = 0; > > > > - goto out; > > > > } > > > > > > > > - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) { > > > > + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) { > > > > struct sync_file *sync_file = sync_file_create(submit->user_fence); > > > > if (!sync_file) { > > > > ret = -ENOMEM; > > > > - goto out; > > > > + } else { > > > > + fd_install(out_fence_fd, sync_file->file); > > > > + args->fence_fd = out_fence_fd; > > > > } > > > > - fd_install(out_fence_fd, sync_file->file); > > > > - args->fence_fd = out_fence_fd; > > > > > > I wonder if instead we should (approximately) undo "drm/msm/submit: > > > Simplify out-fence-fd handling" so that the point that it could fail > > > is moved up ahead of the drm_sched_job_arm()? > > > > Hm yeah. Up to you how you want to paint this shed, I think either is fine. > > > > > Also, does the dma_fence_get() work before drm_sched_job_arm()? From > > > a quick look, it looks like it won't, but I'm still playing catchup > > > and haven't had a chance to look at your entire series. If it doesn't > > > work before drm_sched_job_arm(), then there is really no way to > > > prevent a error path between the fence-init and job-submit. > > > > Yes. I thought I've checked that I put the _arm() in the right spot, > > but I guess I screwed up and you need the fence before the point where > > I've put the job_arm()? And yes the error path cannot be avoided for > > out-fences, that's what I tried to explain in the commit message. > > > > > But, prior to your series, wouldn't a failure after > > > drm_sched_job_init() but before the job is submitted just burn a > > > fence-id, and otherwise carry on it's merry way? > > > > Maybe? I'm not sure whether the scheduler gets confused about the gap > > and freak out abou that. I'm fairly new to that code and learning > > (which is part why I'm working on it). Since you look up in > > fences/syncobj after job_init() it should be pretty easy to whip up a > > testcase and see what happens. Also as long as nothing fails you won't > > see an issue, that's for sure. > > fair.. I'll try to come up with a test case.. pre-scheduler-conversion > it wasn't a problem to fail after the fence seqno was allocated (well, > I guess you might have problems if you had 2^31 failures in a row) Yeah one thing drm/sched forces you to do is have a very clear notion about the point of no return in your submit ioctl. Which I think is a Very Good Thing, at least looking at i915 execbuf where the point of no return is a multi-stage thing with such interesting intermediate points like "we submit the ruquest but without actually running the batchbuffer". The downside is that the submit ioctl isn't perfectly transaction anymore, but I don't think that matters for tha tail stuff, which is generally just some out-fence installing. That generally never fails. -Daniel > > BR, > -R > > > -Daniel > > > > > BR, > > > -R > > > > > > > } > > > > > > > > submit_attach_object_fences(submit); > > > > -- > > > > 2.32.0 > > > > > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
next prev parent reply other threads:[~2021-08-06 18:42 UTC|newest] Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-05 10:46 [PATCH v5 00/20] drm/sched dependency handling and implicit sync fixes Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 01/20] drm/sched: Split drm_sched_job_init Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:43 ` Christian König 2021-08-05 13:43 ` [Intel-gfx] " Christian König 2021-08-05 14:07 ` Daniel Vetter 2021-08-05 14:07 ` [Intel-gfx] " Daniel Vetter 2021-08-05 14:47 ` Christian König 2021-08-05 14:47 ` [Intel-gfx] " Christian König 2021-08-05 15:07 ` Daniel Vetter 2021-08-05 15:07 ` [Intel-gfx] " Daniel Vetter 2021-08-17 8:49 ` [PATCH] " Daniel Vetter 2021-08-17 8:49 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 23:02 ` Rob Clark 2021-08-05 23:02 ` [Intel-gfx] " Rob Clark 2021-08-06 16:41 ` Daniel Vetter 2021-08-06 16:41 ` [Intel-gfx] " Daniel Vetter 2021-08-06 17:19 ` Rob Clark 2021-08-06 17:19 ` [Intel-gfx] " Rob Clark 2021-08-06 18:41 ` Daniel Vetter [this message] 2021-08-06 18:41 ` Daniel Vetter 2021-08-06 19:01 ` Rob Clark 2021-08-06 19:01 ` [Intel-gfx] " Rob Clark 2021-08-06 19:10 ` Daniel Vetter 2021-08-06 19:10 ` [Intel-gfx] " Daniel Vetter 2021-08-06 19:59 ` Rob Clark 2021-08-06 19:59 ` [Intel-gfx] " Rob Clark 2021-08-17 8:53 ` [PATCH] drm/msm: Improve " Daniel Vetter 2021-08-17 8:53 ` [Intel-gfx] " Daniel Vetter 2021-08-26 9:33 ` Daniel Vetter 2021-08-26 9:33 ` [Intel-gfx] " Daniel Vetter 2021-08-26 15:38 ` Rob Clark 2021-08-26 15:38 ` Rob Clark 2021-08-05 10:46 ` [PATCH v5 03/20] drm/sched: Barriers are needed for entity->last_scheduled Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:45 ` Christian König 2021-08-05 13:45 ` [Intel-gfx] " Christian König 2021-08-05 10:46 ` [PATCH v5 04/20] drm/sched: Add dependency tracking Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:47 ` Christian König 2021-08-05 13:47 ` [Intel-gfx] " Christian König 2021-08-05 10:46 ` [PATCH v5 05/20] drm/sched: drop entity parameter from drm_sched_push_job Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:48 ` Christian König 2021-08-05 13:48 ` [Intel-gfx] " Christian König 2021-08-05 10:46 ` [PATCH v5 06/20] drm/sched: improve docs around drm_sched_entity Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 07/20] drm/panfrost: use scheduler dependency tracking Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 15:10 ` Alyssa Rosenzweig 2021-08-05 15:10 ` [Intel-gfx] " Alyssa Rosenzweig 2021-08-05 10:46 ` [PATCH v5 08/20] drm/lima: " Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-12 19:28 ` Daniel Vetter 2021-08-12 19:28 ` [Intel-gfx] " Daniel Vetter 2021-08-14 2:45 ` Qiang Yu 2021-08-14 2:45 ` [Intel-gfx] " Qiang Yu 2021-08-05 10:46 ` [PATCH v5 09/20] drm/v3d: Move drm_sched_job_init to v3d_job_init Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 10/20] drm/v3d: Use scheduler dependency handling Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 11/20] drm/etnaviv: " Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-12 19:28 ` Daniel Vetter 2021-08-12 19:28 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 12/20] drm/msm: " Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-12 19:29 ` Daniel Vetter 2021-08-12 19:29 ` [Intel-gfx] " Daniel Vetter 2021-08-26 16:12 ` Rob Clark 2021-08-26 16:12 ` [Intel-gfx] " Rob Clark 2021-08-30 9:01 ` Daniel Vetter 2021-08-30 9:01 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 13/20] drm/gem: Delete gem array fencing helpers Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-12 19:29 ` Daniel Vetter 2021-08-12 19:29 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:46 ` [PATCH v5 14/20] drm/sched: Don't store self-dependencies Daniel Vetter 2021-08-05 10:46 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:18 ` Christian König 2021-08-05 13:18 ` [Intel-gfx] " Christian König 2021-08-05 13:25 ` Daniel Vetter 2021-08-05 13:25 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:57 ` Christian König 2021-08-05 13:57 ` [Intel-gfx] " Christian König 2021-08-05 15:06 ` Daniel Vetter 2021-08-05 15:06 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:47 ` [PATCH v5 15/20] drm/sched: Check locking in drm_sched_job_await_implicit Daniel Vetter 2021-08-05 10:47 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:19 ` Christian König 2021-08-05 13:19 ` [Intel-gfx] " Christian König 2021-08-05 13:27 ` Daniel Vetter 2021-08-05 13:27 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:47 ` [PATCH v5 16/20] drm/msm: Don't break exclusive fence ordering Daniel Vetter 2021-08-05 10:47 ` [Intel-gfx] " Daniel Vetter 2021-08-26 16:16 ` Rob Clark 2021-08-26 16:16 ` [Intel-gfx] " Rob Clark 2021-08-26 16:16 ` Rob Clark 2021-08-30 9:02 ` Daniel Vetter 2021-08-30 9:02 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:47 ` [PATCH v5 17/20] drm/etnaviv: " Daniel Vetter 2021-08-05 10:47 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:47 ` [PATCH v5 18/20] drm/i915: delete exclude argument from i915_sw_fence_await_reservation Daniel Vetter 2021-08-05 10:47 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:47 ` [PATCH v5 19/20] drm/i915: Don't break exclusive fence ordering Daniel Vetter 2021-08-05 10:47 ` [Intel-gfx] " Daniel Vetter 2021-08-05 10:47 ` [PATCH v5 20/20] dma-resv: Give the docs a do-over Daniel Vetter 2021-08-05 10:47 ` [Intel-gfx] " Daniel Vetter 2021-08-30 19:38 ` Daniel Vetter 2021-08-30 19:38 ` [Intel-gfx] " Daniel Vetter 2021-08-05 13:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency handling and implicit sync fixes Patchwork 2021-08-05 14:29 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork 2021-08-06 19:14 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/sched dependency handling and implicit sync fixes (rev2) Patchwork 2021-08-17 16:27 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency handling and implicit sync fixes (rev4) Patchwork 2021-08-17 16:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-08-17 18:15 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-08-26 13:17 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency handling and implicit sync fixes (rev5) Patchwork 2021-08-26 13:48 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-08-26 21:46 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKMK7uH2v2x+=Ct-v-2RCVXez4MzjMvhh4yCs_f8HPvYa+DXcA@mail.gmail.com' \ --to=daniel.vetter@ffwll.ch \ --cc=christian.koenig@amd.com \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=robdclark@chromium.org \ --cc=robdclark@gmail.com \ --cc=sean@poorly.run \ --cc=sumit.semwal@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.