All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Skeggs <skeggsb@gmail.com>
To: Lyude Paul <lyude@redhat.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: Mon, 31 Aug 2020 14:26:19 +1000	[thread overview]
Message-ID: <CACAvsv6GKeX=u4Jn0VVJk1qgnPcnPCW6exukqjvfrfmm2mwSUg@mail.gmail.com> (raw)
In-Reply-To: <76392bff28359a88fbdf0857f011e0ed9f666dc4.camel@redhat.com>

On Wed, 26 Aug 2020 at 02:52, Lyude Paul <lyude@redhat.com> wrote:
>
> 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?
We definitely want to *wait* on GetCapabilities() finishing, I believe
it should also update the notifier the same (or similar) way Update()
does.  But I don't think we want to send an Update() here, it'll
actually trigger a modeset (which, on earlier HW, will tear down the
boot mode.  Not sure about current HW, it might preserve state), and
we may not want that to happen there.

Ben.

>
> > 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: Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@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: Mon, 31 Aug 2020 14:26:19 +1000	[thread overview]
Message-ID: <CACAvsv6GKeX=u4Jn0VVJk1qgnPcnPCW6exukqjvfrfmm2mwSUg@mail.gmail.com> (raw)
In-Reply-To: <76392bff28359a88fbdf0857f011e0ed9f666dc4.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Wed, 26 Aug 2020 at 02:52, Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> 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?
We definitely want to *wait* on GetCapabilities() finishing, I believe
it should also update the notifier the same (or similar) way Update()
does.  But I don't think we want to send an Update() here, it'll
actually trigger a modeset (which, on earlier HW, will tear down the
boot mode.  Not sure about current HW, it might preserve state), and
we may not want that to happen there.

Ben.

>
> > 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: Ben Skeggs <skeggsb@gmail.com>
To: Lyude Paul <lyude@redhat.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: Mon, 31 Aug 2020 14:26:19 +1000	[thread overview]
Message-ID: <CACAvsv6GKeX=u4Jn0VVJk1qgnPcnPCW6exukqjvfrfmm2mwSUg@mail.gmail.com> (raw)
In-Reply-To: <76392bff28359a88fbdf0857f011e0ed9f666dc4.camel@redhat.com>

On Wed, 26 Aug 2020 at 02:52, Lyude Paul <lyude@redhat.com> wrote:
>
> 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?
We definitely want to *wait* on GetCapabilities() finishing, I believe
it should also update the notifier the same (or similar) way Update()
does.  But I don't think we want to send an Update() here, it'll
actually trigger a modeset (which, on earlier HW, will tear down the
boot mode.  Not sure about current HW, it might preserve state), and
we may not want that to happen there.

Ben.

>
> > 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-31  4:26 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
2020-08-25 16:52       ` Lyude Paul
2020-08-25 16:52       ` Lyude Paul
2020-08-31  4:26       ` Ben Skeggs [this message]
2020-08-31  4:26         ` [Nouveau] " 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='CACAvsv6GKeX=u4Jn0VVJk1qgnPcnPCW6exukqjvfrfmm2mwSUg@mail.gmail.com' \
    --to=skeggsb@gmail.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=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=sashal@kernel.org \
    --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.