13 Commits

Author SHA1 Message Date
Ben Skeggs
632b740c54 drm/nouveau/mmu: remove old vmm frontend
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02 13:32:33 +10:00
Ben Skeggs
2854ab8dd8 drm/nouveau/fb: finalise big page size selection in constructor
MMU will need to know this during its constructor, so we can't delay
deciding this until init-time.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02 13:32:20 +10:00
Alexandre Courbot
60958b8f29 drm/nouveau/fb/gk20a: use regular gf100's functions
gk20a's FB is not special compared to other Kepler chips, besides the
fact it does not have VRAM. Use the regular gf100 hooks instead of the
incomplete versions we rewrote.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-By: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07 14:04:39 +10:00
Alexandre Courbot
635cb7da57 drm/nouveau/fb/gk20a: fix constructor call
The gf100 constructor should be called, otherwise we will allocate a
smaller object than expected. This was without effect so far because
gk20a did not allocate a page, but with gf100's page allocation moved
to the oneinit() hook this problem has become apparent.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07 14:04:38 +10:00
Ben Skeggs
c73baa831f drm/nouveau/fb/gf100-: allow selection of an alternate big page size
GFxxx/GM1xx support the selection of 64/128KiB big pages globally.

GM2xx supports the same, as well as another mode where the page size
can be selected per-instance.

We default to 128KiB pages (With per-instance for GM200, but the current
code selects 128KiB there already) as the MMU code isn't currently able
to handle otherwise.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14 11:53:25 +10:00
Ben Skeggs
834b21f5e9 drm/nouveau/fb/gk20a,gm20b: setup mmu debug buffer registers at init()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20 14:43:04 +10:00
Ben Skeggs
99c5917253 drm/nouveau/fb/gf100-: allocate mmu debug buffers
Later chipsets require setting this up both in FB and GR, so let's just
move the allocation to FB.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20 14:43:04 +10:00
Ben Skeggs
03c8952fb3 drm/nouveau/fb: convert to new-style nvkm_subdev
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28 12:40:43 +10:00
Ben Skeggs
6758745b28 drm/nouveau/fb: switch to device pri macros
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28 12:40:14 +10:00
Ben Skeggs
b1e4553cb1 drm/nouveau/fb: cosmetic changes
This is purely preparation for upcoming commits, there should be no
code changes here.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28 12:40:08 +10:00
Alexandre Courbot
1452087675 drm/nouveau/gk20a: remove RAM device
Now that Nouveau can operate even when there is no RAM device, remove
the dummy one used by GK20A.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14 17:00:43 +10:00
Ben Skeggs
639c308eff drm/nouveau/fb: 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>
2015-01-22 12:17:52 +10:00
Ben Skeggs
c39f472e9f 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>
2015-01-22 12:15:10 +10:00