#
45655ff0 |
|
18-Sep-2023 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar/tu102-: prepare for GSP-RM - (temporarily) disable if GSP-RM detected, will be added later - move BAR2 teardown from dtor(), it doesn't belong there Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230918202149.4343-7-skeggsb@gmail.com
|
#
917b24a3 |
|
03-Dec-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: switch to instanced constructor Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
302daab1 |
|
10-Dec-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fifo/gf100-: call into BAR to reset BARs after MMU fault This is needed for Turing, but we're supposed to wait for completion after re-writing the value on older GPUs anyway. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
e062a01e |
|
04-Jan-2018 |
Jon Hunter <jonathanh@nvidia.com> |
drm/nouveau/bar/gk20a: Avoid bar teardown during init Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") introduced add a teardown helper function for BAR1. During initialisation of the Nouveau, initially all the teardown helpers are called once, before calling their init counterparts. For gk20a, after the BAR1 teardown function is called, the device is hanging during the initialisation of the FB sub-device. At this point it is unclear why this is happening and this is still under investigation. However, this change is preventing Tegra124 devices from booting when Nouveau is enabled. To allow Tegra124 to boot, remove the teardown helper for gk20a. This is based upon a previous patch by Guillaume Tucker but limits the workaround to only gk20a GPUs. Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
ffd937bb |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/imem: use fast-path for resume restore Before: "imem: init completed in 299277us" After: "imem: init completed in 11574us" Suspend from Fedora 26 gnome desktop on GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
e9be3c7d |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/imem: use fast-path for suspend backup Before: "imem: suspend completed in 5540487us" After: "imem: suspend completed in 1871526us" Suspend from Fedora 26 gnome desktop on GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
bb7e501a |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: prevent BAR2 mapping of objects during destructor GP100's page table nests a lot more deeply than the GF100-compatible layout we're currently using, which means our hackish-but-simple way of dealing with BAR2 VMM teardown won't work anymore. In order to sanely handle the chicken-and-egg (BAR2's PTs get mapped into themselves) problem, we need prevent page tables getting mapped back into BAR2 during the destruction of its VMM. To do this, we simply key off the state that's now maintained by the BAR2 init/fini functions. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
a78dbce9 |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: modify interface to bar2 vmm mapping Match API with the BAR1 version. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
570889dc |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: modify interface to bar1 vmm mapping Upcoming changes will remove the nvkm_vmm pointer from nvkm_vma, instead requiring it to be explicitly specified on each operation. It's not currently possible to get this information for BAR1 mappings, so let's fix that ahead of time. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
e988952e |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: expose interface to bar2 teardown Will prevent spurious MMU fault interrupts if something decides to touch BAR1 after we've unloaded the driver. Exposed external to BAR so that INSTMEM can use it to better control the suspend/resume fast-path access. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
48fe0247 |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: expose interface to bar2 initialisation If we want to be able to hit the instmem fast-path in a few trickier cases, we need to be more flexible with when we can initialise BAR2 access. There's probably a decent case to be made for merging BAR/INSTMEM into BUS, but that's something to ponder another day. Flushes have been added after the write to bind the instance block, as later commits will reveal the need for them. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
bbb163e1 |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: implement bar1 teardown Will prevent spurious MMU fault interrupts if something decides to touch BAR1 after we've unloaded the driver. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
7313cfa4 |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: move bar1 initialisation into its own function BAR2 being done for practical reasons, this is just for consistency. Flushes have been added after the write to bind the instance block, as later commits will reveal the need for them. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
269fe32d |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: swap oneinit/init ordering, and rename bar3 to bar2 NVIDIA call it BAR2, Linux APIs treat it as BAR3 due to BAR1 being a 64-bit BAR, which I presume take two slots or something. No actual code changes here, just to make future commits less messy. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
e69dae85 |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar/nv50,g84: drop mmu invalidate Will already be done by MMU as a result of the PT writes that occur during BAR2 bootstrapping. This is likely just a left-over from the days when it was hardcoded. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
56d06fa2 |
|
08-Apr-2016 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/core: remove pmc_enable argument from subdev ctor These are now specified directly in the MC subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
32932281 |
|
19-Aug-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: convert to new-style nvkm_subdev Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
d8e83994 |
|
19-Aug-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/imem: improve management of instance memory Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
aa35888f |
|
19-Aug-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/object: rename some functions to avoid upcoming conflicts Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
0df18e6d |
|
19-Aug-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: switch to subdev printk macros Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
5b0c189f |
|
19-Aug-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: cosmetic changes This is purely preparation for upcoming commits, there should be no code changes here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
9ace404b |
|
19-Aug-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/device: include core/device.h automatically for subdevs/engines Pretty much every subdev/engine is going to need access to nvkm_device shortly to touch registers and/or output messages. The odd placement of the includes is necessary to work around some inter-dependencies that currently exist. This will be fixed later. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
245dcfe9 |
|
13-Jan-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/bar: namespace + nvidia gpu names (no binary change) The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
5ce3bf3c |
|
13-Jan-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu: rename from vmmgr (no binary change) Switch to NVIDIA's name for the device. The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
c39f472e |
|
13-Jan-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: remove symlinks, move core/ to nvkm/ (no code changes) The symlinks were annoying some people, and they're not used anywhere else in the kernel tree. The include directory structure has been changed so that symlinks aren't needed anymore. NVKM has been moved from core/ to nvkm/ to make it more obvious as to what the directory is for, and as some minor prep for when NVKM gets split out into its own module (virt) at a later date. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|