All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: ML nouveau <nouveau@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Nouveau] [PATCH 3/6] drm/nouveau: Remove bogus gk20a aperture callback
Date: Fri, 20 Sep 2019 17:55:19 +0200	[thread overview]
Message-ID: <20190920155519.GD10973@ulmo> (raw)
In-Reply-To: <20190917090254.GC17854@ulmo>


[-- Attachment #1.1: Type: text/plain, Size: 6358 bytes --]

On Tue, Sep 17, 2019 at 11:02:54AM +0200, Thierry Reding wrote:
> On Tue, Sep 17, 2019 at 01:43:13PM +1000, Ben Skeggs wrote:
> > On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do
> > > in fact use the same apertures as regular GPUs. Prior to gv11b there are
> > > no checks in hardware for the aperture, so we get away with setting VRAM
> > > as the aperture for buffers that are actually in system memory.
> > Can GK20A take comptags with aperture set to system memory?  For some
> > reason I can recall, I was under the impression PTEs needed to be
> > pointed at "vidmem" (despite them actually accessing system memory
> > anyway) on Tegra parts for compression to work?  I could be mistaken
> > though.
> 
> I don't think GK20A supports comptags at all. I think this wasn't
> introduced until GM20B. nvgpu has some "gk20a" code to flush comptags,
> but that's only used on GM20B and later.
> 
> Anyway, my understanding is that on all of GK20A, GM20B and GP10B the
> aperture field is completely ignored. I think that also goes for
> comptags. nvgpu in particular never requests comptags to be allocated
> from vidmem. See:
> 
> 	https://nv-tegra.nvidia.com/gitweb/?p=linux-nvgpu.git;a=blob;f=drivers/gpu/nvgpu/os/linux/ltc.c;h=baeb20b2e539cc6cb70667ce168603546678dc73;hb=2081ce686bfd4deb461b4130df424d592000ff88#l30
> 
> There are two callers of that, both passing "false" for the vidmem_alloc
> parameter, so comptags always do end up in system memory for Tegra.
> 
> That said, I'll go confirm that with one of our experts and get back to
> you.

So it looks like you're right and indeed GK20A and later (up to, but not
including, GV11B that is) comptags do indeed need to be mapped as vidmem
even if they reside in sysmem.

Conceptually I think what we want to do is decide about the aperture at
allocation time. So if we allocate comptags we would need to force the
aperture to be VRAM on the iGPUs where necessary, even if they are
really allocated in system memory. Ultimately the end result is the same
of course, but I think this way around is a better representation of
this particular hardware quirk and allows us to keep the unification
that this patch series achieves.

But I'll have to look into this and see what I can come up with.

Thierry

> 
> Thierry
> 
> > 
> > Ben.
> > 
> > >
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > ---
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h      |  1 -
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c | 10 ----------
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c |  4 ++--
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c |  2 +-
> > >  4 files changed, 3 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> > > index fb3a9e8bb9cd..9862f44ac8b5 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> > > @@ -212,7 +212,6 @@ void gf100_vmm_flush(struct nvkm_vmm *, int);
> > >  void gf100_vmm_invalidate(struct nvkm_vmm *, u32 type);
> > >  void gf100_vmm_invalidate_pdb(struct nvkm_vmm *, u64 addr);
> > >
> > > -int gk20a_vmm_aper(enum nvkm_memory_target);
> > >  int gk20a_vmm_valid(struct nvkm_vmm *, void *, u32, struct nvkm_vmm_map *);
> > >
> > >  int gm200_vmm_new_(const struct nvkm_vmm_func *, const struct nvkm_vmm_func *,
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
> > > index 16d7bf727292..999b953505b3 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
> > > @@ -25,16 +25,6 @@
> > >
> > >  #include <core/memory.h>
> > >
> > > -int
> > > -gk20a_vmm_aper(enum nvkm_memory_target target)
> > > -{
> > > -       switch (target) {
> > > -       case NVKM_MEM_TARGET_NCOH: return 0;
> > > -       default:
> > > -               return -EINVAL;
> > > -       }
> > > -}
> > > -
> > >  int
> > >  gk20a_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
> > >                 struct nvkm_vmm_map *map)
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
> > > index 7a6066d886cd..f5d7819c4a40 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
> > > @@ -25,7 +25,7 @@ static const struct nvkm_vmm_func
> > >  gm20b_vmm_17 = {
> > >         .join = gm200_vmm_join,
> > >         .part = gf100_vmm_part,
> > > -       .aper = gk20a_vmm_aper,
> > > +       .aper = gf100_vmm_aper,
> > >         .valid = gk20a_vmm_valid,
> > >         .flush = gf100_vmm_flush,
> > >         .invalidate_pdb = gf100_vmm_invalidate_pdb,
> > > @@ -41,7 +41,7 @@ static const struct nvkm_vmm_func
> > >  gm20b_vmm_16 = {
> > >         .join = gm200_vmm_join,
> > >         .part = gf100_vmm_part,
> > > -       .aper = gk20a_vmm_aper,
> > > +       .aper = gf100_vmm_aper,
> > >         .valid = gk20a_vmm_valid,
> > >         .flush = gf100_vmm_flush,
> > >         .invalidate_pdb = gf100_vmm_invalidate_pdb,
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
> > > index 180c8f006e32..ffe84ea2f7d9 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
> > > @@ -43,7 +43,7 @@ static const struct nvkm_vmm_func
> > >  gp10b_vmm = {
> > >         .join = gp100_vmm_join,
> > >         .part = gf100_vmm_part,
> > > -       .aper = gk20a_vmm_aper,
> > > +       .aper = gf100_vmm_aper,
> > >         .valid = gp10b_vmm_valid,
> > >         .flush = gp100_vmm_flush,
> > >         .mthd = gp100_vmm_mthd,
> > > --
> > > 2.23.0
> > >
> > > _______________________________________________
> > > Nouveau mailing list
> > > Nouveau@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/nouveau



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

  reply	other threads:[~2019-09-20 15:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-16 15:17 [PATCH 0/6] drm/nouveau: Preparatory work for GV11B support Thierry Reding
     [not found] ` <20190916151757.10953-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-09-16 15:17   ` [PATCH 1/6] drm/nouveau: fault: Store aperture in fault information Thierry Reding
     [not found]     ` <20190916151757.10953-2-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-09-17  3:47       ` Ben Skeggs
     [not found]         ` <CACAvsv70b1-LJoaP1ZL2hvy9xMcO1WXqh0ibGzNfpB81ybgrTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-17  9:05           ` Thierry Reding
2019-09-16 15:17   ` [PATCH 2/6] drm/nouveau: fault: Widen engine field Thierry Reding
     [not found]     ` <20190916151757.10953-3-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-09-17  3:48       ` Ben Skeggs
2019-09-17  9:05         ` [Nouveau] " Thierry Reding
2019-09-16 15:17   ` [PATCH 3/6] drm/nouveau: Remove bogus gk20a aperture callback Thierry Reding
2019-09-17  3:43     ` [Nouveau] " Ben Skeggs
     [not found]       ` <CACAvsv6AzWvpPLaOKahpJErTAMCJet4_4mBvRC8Z+e4+bwaD4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-17  9:02         ` Thierry Reding
2019-09-20 15:55           ` Thierry Reding [this message]
2019-09-16 15:17   ` [PATCH 4/6] drm/nouveau: Implement nvkm_memory_aperture() Thierry Reding
2019-09-16 15:17   ` [PATCH 5/6] drm/nouveau: Remove unused nvkm_vmm_func->aper() implementations Thierry Reding
2019-09-16 15:17 ` [PATCH 6/6] drm/nouveau: Program aperture field where necessary Thierry Reding

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=20190920155519.GD10973@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=skeggsb@gmail.com \
    /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.