All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lyude Paul <lyude@redhat.com>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: ML nouveau <nouveau@lists.freedesktop.org>,
	Sasha Levin <sashal@kernel.org>, David Airlie <airlied@linux.ie>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" 
	<dri-devel@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>, Daniel Vetter <daniel@ffwll.ch>,
	stable@vger.kernel.org
Subject: Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Date: Tue, 25 Aug 2020 12:52:05 -0400	[thread overview]
Message-ID: <76392bff28359a88fbdf0857f011e0ed9f666dc4.camel@redhat.com> (raw)
In-Reply-To: <CACAvsv6hymdcGkEcigL3fWACZ_1POpB+aefq9d9ChnYv_dHnVg@mail.gmail.com>

On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> On Tue, 25 Aug 2020 at 04:33, Lyude Paul <lyude@redhat.com> wrote:
> > Not entirely sure why this never came up when I originally tested this
> > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> > appears to cause the display engine to throw an exception on driver
> > init, at least on my ThinkPad P72:
> > 
> > nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
> > 
> > This is magic nvidia speak for "You need to have the DMA notifier offset
> > programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> > this by doing that, and also perform an update afterwards to prevent
> > racing with the GPU when reading capabilities.
> > 
> > Changes since v1:
> > * Don't just program the DMA notifier offset, make sure to actually
> >   perform an update
> I'm not sure there's a need to send an Update() method here, I believe
> GetCapabilities() is an action method on its own right?
> 

I'm not entirely sure about this part tbh. I do know that we need to call
GetCapabilities() _after_ the DMA notifier offset is programmed. But, my
assumption was that if GetCapabilities() requires a DMA notifier offset to store
its results in, we'd probably want to fire an update or something to make sure
that we're not reading before it finishes writing capabilities?

> Ben.
> 
> > Signed-off-by: Lyude Paul <lyude@redhat.com>
> > Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP
> > interlacing support")
> > Cc: <stable@vger.kernel.org> # v5.8+
> > ---
> >  drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 ++++++++++++++++-----
> >  1 file changed, 19 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > index e341f572c2696..5e86feec3b720 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > @@ -65,13 +65,26 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
> >  int
> >  core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> >  {
> > -       u32 *push = evo_wait(&disp->core->chan, 2);
> > +       struct nv50_core *core = disp->core;
> > +       u32 interlock[NV50_DISP_INTERLOCK__SIZE] = {0};
> > +       u32 *push;
> > 
> > -       if (push) {
> > -               evo_mthd(push, 0x008c, 1);
> > -               evo_data(push, 0x0);
> > -               evo_kick(push, &disp->core->chan);
> > -       }
> > +       core->func->ntfy_init(disp->sync, NV50_DISP_CORE_NTFY);
> > +
> > +       push = evo_wait(&core->chan, 4);
> > +       if (!push)
> > +               return 0;
> > +
> > +       evo_mthd(push, 0x0084, 1);
> > +       evo_data(push, 0x80000000 | NV50_DISP_CORE_NTFY);
> > +       evo_mthd(push, 0x008c, 1);
> > +       evo_data(push, 0x0);
> > +       evo_kick(push, &core->chan);
> > +
> > +       core->func->update(core, interlock, false);
> > +       if (core->func->ntfy_wait_done(disp->sync, NV50_DISP_CORE_NTFY,
> > +                                      core->chan.base.device))
> > +               NV_ERROR(drm, "core notifier timeout\n");
> > 
> >         return 0;
> >  }
> > --
> > 2.26.2
> > 
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat


WARNING: multiple messages have this Message-ID (diff)
From: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Sasha Levin <sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	ML nouveau
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>,
	stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Date: Tue, 25 Aug 2020 12:52:05 -0400	[thread overview]
Message-ID: <76392bff28359a88fbdf0857f011e0ed9f666dc4.camel@redhat.com> (raw)
In-Reply-To: <CACAvsv6hymdcGkEcigL3fWACZ_1POpB+aefq9d9ChnYv_dHnVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> On Tue, 25 Aug 2020 at 04:33, Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > Not entirely sure why this never came up when I originally tested this
> > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> > appears to cause the display engine to throw an exception on driver
> > init, at least on my ThinkPad P72:
> > 
> > nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
> > 
> > This is magic nvidia speak for "You need to have the DMA notifier offset
> > programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> > this by doing that, and also perform an update afterwards to prevent
> > racing with the GPU when reading capabilities.
> > 
> > Changes since v1:
> > * Don't just program the DMA notifier offset, make sure to actually
> >   perform an update
> I'm not sure there's a need to send an Update() method here, I believe
> GetCapabilities() is an action method on its own right?
> 

I'm not entirely sure about this part tbh. I do know that we need to call
GetCapabilities() _after_ the DMA notifier offset is programmed. But, my
assumption was that if GetCapabilities() requires a DMA notifier offset to store
its results in, we'd probably want to fire an update or something to make sure
that we're not reading before it finishes writing capabilities?

> Ben.
> 
> > Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP
> > interlacing support")
> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v5.8+
> > ---
> >  drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 ++++++++++++++++-----
> >  1 file changed, 19 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > index e341f572c2696..5e86feec3b720 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > @@ -65,13 +65,26 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
> >  int
> >  core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> >  {
> > -       u32 *push = evo_wait(&disp->core->chan, 2);
> > +       struct nv50_core *core = disp->core;
> > +       u32 interlock[NV50_DISP_INTERLOCK__SIZE] = {0};
> > +       u32 *push;
> > 
> > -       if (push) {
> > -               evo_mthd(push, 0x008c, 1);
> > -               evo_data(push, 0x0);
> > -               evo_kick(push, &disp->core->chan);
> > -       }
> > +       core->func->ntfy_init(disp->sync, NV50_DISP_CORE_NTFY);
> > +
> > +       push = evo_wait(&core->chan, 4);
> > +       if (!push)
> > +               return 0;
> > +
> > +       evo_mthd(push, 0x0084, 1);
> > +       evo_data(push, 0x80000000 | NV50_DISP_CORE_NTFY);
> > +       evo_mthd(push, 0x008c, 1);
> > +       evo_data(push, 0x0);
> > +       evo_kick(push, &core->chan);
> > +
> > +       core->func->update(core, interlock, false);
> > +       if (core->func->ntfy_wait_done(disp->sync, NV50_DISP_CORE_NTFY,
> > +                                      core->chan.base.device))
> > +               NV_ERROR(drm, "core notifier timeout\n");
> > 
> >         return 0;
> >  }
> > --
> > 2.26.2
> > 
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat

WARNING: multiple messages have this Message-ID (diff)
From: Lyude Paul <lyude@redhat.com>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: Sasha Levin <sashal@kernel.org>, David Airlie <airlied@linux.ie>,
	ML nouveau <nouveau@lists.freedesktop.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>,
	stable@vger.kernel.org
Subject: Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
Date: Tue, 25 Aug 2020 12:52:05 -0400	[thread overview]
Message-ID: <76392bff28359a88fbdf0857f011e0ed9f666dc4.camel@redhat.com> (raw)
In-Reply-To: <CACAvsv6hymdcGkEcigL3fWACZ_1POpB+aefq9d9ChnYv_dHnVg@mail.gmail.com>

On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> On Tue, 25 Aug 2020 at 04:33, Lyude Paul <lyude@redhat.com> wrote:
> > Not entirely sure why this never came up when I originally tested this
> > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> > appears to cause the display engine to throw an exception on driver
> > init, at least on my ThinkPad P72:
> > 
> > nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b
> > 
> > This is magic nvidia speak for "You need to have the DMA notifier offset
> > programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> > this by doing that, and also perform an update afterwards to prevent
> > racing with the GPU when reading capabilities.
> > 
> > Changes since v1:
> > * Don't just program the DMA notifier offset, make sure to actually
> >   perform an update
> I'm not sure there's a need to send an Update() method here, I believe
> GetCapabilities() is an action method on its own right?
> 

I'm not entirely sure about this part tbh. I do know that we need to call
GetCapabilities() _after_ the DMA notifier offset is programmed. But, my
assumption was that if GetCapabilities() requires a DMA notifier offset to store
its results in, we'd probably want to fire an update or something to make sure
that we're not reading before it finishes writing capabilities?

> Ben.
> 
> > Signed-off-by: Lyude Paul <lyude@redhat.com>
> > Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP
> > interlacing support")
> > Cc: <stable@vger.kernel.org> # v5.8+
> > ---
> >  drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 ++++++++++++++++-----
> >  1 file changed, 19 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > index e341f572c2696..5e86feec3b720 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > @@ -65,13 +65,26 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
> >  int
> >  core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> >  {
> > -       u32 *push = evo_wait(&disp->core->chan, 2);
> > +       struct nv50_core *core = disp->core;
> > +       u32 interlock[NV50_DISP_INTERLOCK__SIZE] = {0};
> > +       u32 *push;
> > 
> > -       if (push) {
> > -               evo_mthd(push, 0x008c, 1);
> > -               evo_data(push, 0x0);
> > -               evo_kick(push, &disp->core->chan);
> > -       }
> > +       core->func->ntfy_init(disp->sync, NV50_DISP_CORE_NTFY);
> > +
> > +       push = evo_wait(&core->chan, 4);
> > +       if (!push)
> > +               return 0;
> > +
> > +       evo_mthd(push, 0x0084, 1);
> > +       evo_data(push, 0x80000000 | NV50_DISP_CORE_NTFY);
> > +       evo_mthd(push, 0x008c, 1);
> > +       evo_data(push, 0x0);
> > +       evo_kick(push, &core->chan);
> > +
> > +       core->func->update(core, interlock, false);
> > +       if (core->func->ntfy_wait_done(disp->sync, NV50_DISP_CORE_NTFY,
> > +                                      core->chan.base.device))
> > +               NV_ERROR(drm, "core notifier timeout\n");
> > 
> >         return 0;
> >  }
> > --
> > 2.26.2
> > 
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-08-25 16:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-24 18:32 [PATCH 0/2] drm/nouveau: Backport SOR/PIOR probing fixes for v5.8 Lyude Paul
2020-08-24 18:32 ` [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps Lyude Paul
2020-08-24 18:32   ` Lyude Paul
2020-08-24 18:32   ` Lyude Paul
2020-08-24 22:28   ` [Nouveau] " Ben Skeggs
2020-08-24 22:28     ` Ben Skeggs
2020-08-24 22:28     ` Ben Skeggs
2020-08-25 16:52     ` Lyude Paul [this message]
2020-08-25 16:52       ` Lyude Paul
2020-08-25 16:52       ` Lyude Paul
2020-08-31  4:26       ` [Nouveau] " Ben Skeggs
2020-08-31  4:26         ` Ben Skeggs
2020-08-31  4:26         ` Ben Skeggs
2020-09-01 20:43         ` [Nouveau] " Lyude Paul
2020-09-01 20:43           ` Lyude Paul
2020-09-01 20:43           ` Lyude Paul
2020-09-01 23:38   ` [PATCH v3] " Lyude Paul
2020-09-01 23:38     ` Lyude Paul
2020-09-01 23:38     ` Lyude Paul
2020-09-01 23:42     ` [PATCH v4] " Lyude Paul
2020-09-01 23:42       ` Lyude Paul
2020-09-01 23:42       ` Lyude Paul
2020-09-02 13:38       ` Sasha Levin
2020-09-02 13:38       ` Sasha Levin
2020-09-02 13:38         ` Sasha Levin
2020-09-03  5:15       ` [Nouveau] " Ben Skeggs
2020-09-03  5:15         ` Ben Skeggs
2020-09-03  5:15         ` Ben Skeggs
2020-08-24 18:32 ` [PATCH 2/2] drm/nouveau/kms/nv50-: Log SOR/PIOR caps Lyude Paul
2020-08-24 18:32   ` Lyude Paul
2020-08-24 18:32   ` Lyude Paul

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=76392bff28359a88fbdf0857f011e0ed9f666dc4.camel@redhat.com \
    --to=lyude@redhat.com \
    --cc=airlied@linux.ie \
    --cc=bskeggs@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=sashal@kernel.org \
    --cc=skeggsb@gmail.com \
    --cc=stable@vger.kernel.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: link
Be 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.