From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Ben Skeggs <skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ML nouveau <nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>, Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, ML dri-devel <dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> Subject: Re: [PATCH v3 0/9] drm/nouveau: Various fixes for GP10B Date: Tue, 10 Dec 2019 14:12:19 +0100 [thread overview] Message-ID: <20191210131219.GE2703785@ulmo> (raw) In-Reply-To: <CACAvsv4NX7jvZb5_X5auU4-KKk9PfmtJvmnQNjY7ihqgXaRS6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> [-- Attachment #1.1: Type: text/plain, Size: 4493 bytes --] On Tue, Dec 10, 2019 at 06:15:30PM +1000, Ben Skeggs wrote: > On Mon, 9 Dec 2019 at 22:00, Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > > > > Hi Ben, > > > > here's a revised subset of the patches I had sent out a couple of weeks > > ago. I've reworked the BAR2 accesses in the way that you had suggested, > > which at least for GP10B turned out to be fairly trivial to do. I have > > not looked in detail at this for GV11B yet, but a cursory look showed > > that BAR2 is accessed in more places, so the equivalent for GV11B might > > be a bit more involved. > > > > Other than that, not a lot has changed since then. I've added a couple > > of precursory patches to add IOMMU helper dummies for the case where > > IOMMU is disabled (as suggested by Ben Dooks). > > > > Joerg has given an Acked-by on the first two patches, so I think it'd be > > easiest if you picked those up into the Nouveau tree because of the > > build dependency of subsequent patches on them. > I've merged all the patches in my tree, after fixing a small build > issue on !TEGRA in the WPR config readout patch. Thanks for taking care of that. I'm going to need to add a non-Tegra configuration to my build scripts and make sure I run those. On a related note: have you ever considered submitting the Nouveau tree for linux-next? That'd be very convenient for people like me working on multiple patch series at the same time. In fact I've got another set of patches against Nouveau that I want to send out after you've merged these. Technically I would need to rebase them on your tree (since there may be dependencies on this set), but that means I need to pull in both your tree and linux-next if I want to keep up to date on all fronts and test all patches in my local tree at the same time. I'm not sure how well that would fit into your workflow. It's typically not more effort than setting up a permanent branch that you can push to whenever there's something that's ready for broader consumption. Beyond the initial setup (which is really not more complicated than sending Stephen an email with a URL and the branch name), it's really quite simple and goes a long way to get broad testing early on. And it's especially handy to catch potential conflicts with cross-subsystem changes like the IOMMU patches in this series. Thierry > > Thierry Reding (9): > > iommu: Document iommu_fwspec::flags field > > iommu: Add dummy dev_iommu_fwspec_get() helper > > drm/nouveau: fault: Add support for GP10B > > drm/nouveau: tegra: Do not try to disable PCI device > > drm/nouveau: tegra: Avoid pulsing reset twice > > drm/nouveau: tegra: Set clock rate if not set > > drm/nouveau: secboot: Read WPR configuration from GPU registers > > drm/nouveau: gp10b: Add custom L2 cache implementation > > drm/nouveau: gp10b: Use correct copy engine > > > > .../drm/nouveau/include/nvkm/subdev/fault.h | 1 + > > .../gpu/drm/nouveau/include/nvkm/subdev/ltc.h | 1 + > > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > > .../gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +- > > .../drm/nouveau/nvkm/engine/device/tegra.c | 24 ++++-- > > .../gpu/drm/nouveau/nvkm/subdev/fault/Kbuild | 1 + > > .../gpu/drm/nouveau/nvkm/subdev/fault/base.c | 2 +- > > .../gpu/drm/nouveau/nvkm/subdev/fault/gp100.c | 17 ++-- > > .../gpu/drm/nouveau/nvkm/subdev/fault/gp10b.c | 53 ++++++++++++ > > .../gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 1 + > > .../gpu/drm/nouveau/nvkm/subdev/fault/priv.h | 10 +++ > > .../gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild | 1 + > > .../gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 65 +++++++++++++++ > > .../gpu/drm/nouveau/nvkm/subdev/ltc/priv.h | 2 + > > .../drm/nouveau/nvkm/subdev/secboot/gm200.h | 2 +- > > .../drm/nouveau/nvkm/subdev/secboot/gm20b.c | 81 ++++++++++++------- > > .../drm/nouveau/nvkm/subdev/secboot/gp10b.c | 4 +- > > include/linux/iommu.h | 47 ++++++----- > > 18 files changed, 249 insertions(+), 72 deletions(-) > > create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fault/gp10b.c > > create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c > > > > -- > > 2.23.0 > > > > _______________________________________________ > > Nouveau mailing list > > Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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: 182 bytes --] _______________________________________________ Nouveau mailing list Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org https://lists.freedesktop.org/mailman/listinfo/nouveau
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com> To: Ben Skeggs <skeggsb@gmail.com> Cc: linux-tegra@vger.kernel.org, ML nouveau <nouveau@lists.freedesktop.org>, Ben Skeggs <bskeggs@redhat.com>, ML dri-devel <dri-devel@lists.freedesktop.org> Subject: Re: [Nouveau] [PATCH v3 0/9] drm/nouveau: Various fixes for GP10B Date: Tue, 10 Dec 2019 14:12:19 +0100 [thread overview] Message-ID: <20191210131219.GE2703785@ulmo> (raw) In-Reply-To: <CACAvsv4NX7jvZb5_X5auU4-KKk9PfmtJvmnQNjY7ihqgXaRS6A@mail.gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 4406 bytes --] On Tue, Dec 10, 2019 at 06:15:30PM +1000, Ben Skeggs wrote: > On Mon, 9 Dec 2019 at 22:00, Thierry Reding <thierry.reding@gmail.com> wrote: > > > > From: Thierry Reding <treding@nvidia.com> > > > > Hi Ben, > > > > here's a revised subset of the patches I had sent out a couple of weeks > > ago. I've reworked the BAR2 accesses in the way that you had suggested, > > which at least for GP10B turned out to be fairly trivial to do. I have > > not looked in detail at this for GV11B yet, but a cursory look showed > > that BAR2 is accessed in more places, so the equivalent for GV11B might > > be a bit more involved. > > > > Other than that, not a lot has changed since then. I've added a couple > > of precursory patches to add IOMMU helper dummies for the case where > > IOMMU is disabled (as suggested by Ben Dooks). > > > > Joerg has given an Acked-by on the first two patches, so I think it'd be > > easiest if you picked those up into the Nouveau tree because of the > > build dependency of subsequent patches on them. > I've merged all the patches in my tree, after fixing a small build > issue on !TEGRA in the WPR config readout patch. Thanks for taking care of that. I'm going to need to add a non-Tegra configuration to my build scripts and make sure I run those. On a related note: have you ever considered submitting the Nouveau tree for linux-next? That'd be very convenient for people like me working on multiple patch series at the same time. In fact I've got another set of patches against Nouveau that I want to send out after you've merged these. Technically I would need to rebase them on your tree (since there may be dependencies on this set), but that means I need to pull in both your tree and linux-next if I want to keep up to date on all fronts and test all patches in my local tree at the same time. I'm not sure how well that would fit into your workflow. It's typically not more effort than setting up a permanent branch that you can push to whenever there's something that's ready for broader consumption. Beyond the initial setup (which is really not more complicated than sending Stephen an email with a URL and the branch name), it's really quite simple and goes a long way to get broad testing early on. And it's especially handy to catch potential conflicts with cross-subsystem changes like the IOMMU patches in this series. Thierry > > Thierry Reding (9): > > iommu: Document iommu_fwspec::flags field > > iommu: Add dummy dev_iommu_fwspec_get() helper > > drm/nouveau: fault: Add support for GP10B > > drm/nouveau: tegra: Do not try to disable PCI device > > drm/nouveau: tegra: Avoid pulsing reset twice > > drm/nouveau: tegra: Set clock rate if not set > > drm/nouveau: secboot: Read WPR configuration from GPU registers > > drm/nouveau: gp10b: Add custom L2 cache implementation > > drm/nouveau: gp10b: Use correct copy engine > > > > .../drm/nouveau/include/nvkm/subdev/fault.h | 1 + > > .../gpu/drm/nouveau/include/nvkm/subdev/ltc.h | 1 + > > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > > .../gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +- > > .../drm/nouveau/nvkm/engine/device/tegra.c | 24 ++++-- > > .../gpu/drm/nouveau/nvkm/subdev/fault/Kbuild | 1 + > > .../gpu/drm/nouveau/nvkm/subdev/fault/base.c | 2 +- > > .../gpu/drm/nouveau/nvkm/subdev/fault/gp100.c | 17 ++-- > > .../gpu/drm/nouveau/nvkm/subdev/fault/gp10b.c | 53 ++++++++++++ > > .../gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 1 + > > .../gpu/drm/nouveau/nvkm/subdev/fault/priv.h | 10 +++ > > .../gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild | 1 + > > .../gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 65 +++++++++++++++ > > .../gpu/drm/nouveau/nvkm/subdev/ltc/priv.h | 2 + > > .../drm/nouveau/nvkm/subdev/secboot/gm200.h | 2 +- > > .../drm/nouveau/nvkm/subdev/secboot/gm20b.c | 81 ++++++++++++------- > > .../drm/nouveau/nvkm/subdev/secboot/gp10b.c | 4 +- > > include/linux/iommu.h | 47 ++++++----- > > 18 files changed, 249 insertions(+), 72 deletions(-) > > create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fault/gp10b.c > > create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c > > > > -- > > 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: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-12-10 13:12 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-09 11:59 [PATCH v3 0/9] drm/nouveau: Various fixes for GP10B Thierry Reding 2019-12-09 11:59 ` [PATCH v3 1/9] iommu: Document iommu_fwspec::flags field Thierry Reding 2019-12-09 11:59 ` [PATCH v3 2/9] iommu: Add dummy dev_iommu_fwspec_get() helper Thierry Reding 2019-12-09 11:59 ` [PATCH v3 3/9] drm/nouveau: fault: Add support for GP10B Thierry Reding [not found] ` <20191209120005.2254786-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2019-12-09 12:00 ` [PATCH v3 4/9] drm/nouveau: tegra: Do not try to disable PCI device Thierry Reding 2019-12-09 12:00 ` Thierry Reding 2019-12-09 12:00 ` [PATCH v3 5/9] drm/nouveau: tegra: Avoid pulsing reset twice Thierry Reding 2019-12-09 12:00 ` Thierry Reding 2019-12-09 12:00 ` [PATCH v3 6/9] drm/nouveau: tegra: Set clock rate if not set Thierry Reding 2019-12-09 12:00 ` Thierry Reding 2019-12-09 12:00 ` [PATCH v3 7/9] drm/nouveau: secboot: Read WPR configuration from GPU registers Thierry Reding 2019-12-09 12:00 ` Thierry Reding 2019-12-09 12:00 ` [PATCH v3 8/9] drm/nouveau: gp10b: Add custom L2 cache implementation Thierry Reding 2019-12-09 12:00 ` Thierry Reding 2019-12-09 12:00 ` [PATCH v3 9/9] drm/nouveau: gp10b: Use correct copy engine Thierry Reding 2019-12-10 8:15 ` [Nouveau] [PATCH v3 0/9] drm/nouveau: Various fixes for GP10B Ben Skeggs 2019-12-10 8:15 ` Ben Skeggs [not found] ` <CACAvsv4NX7jvZb5_X5auU4-KKk9PfmtJvmnQNjY7ihqgXaRS6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2019-12-10 13:12 ` Thierry Reding [this message] 2019-12-10 13:12 ` 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=20191210131219.GE2703785@ulmo \ --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \ --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=skeggsb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.