History log of /linux-master/drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.c
Revision Date Author Comments
# 2c0c15a2 24-May-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gp102-ga100: switch to simpler vram size detection method

Also exposes this for use by upcoming GSP-RM initialisation code.

v2: add SPDX header

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230525003106.3853741-3-skeggsb@gmail.com


# 1b9b4f92 19-Feb-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gp102-: cache scrubber binary on first load

During system shutdown nouveau might not be able to request firmware from
Userspace, which then leads to a regression preventing the system from
shutting down.

Cache the scrubber binary for this case.

Fixes: 0e44c21708761 ("drm/nouveau/flcn: new code to load+boot simple HS FWs (VPR scrubber)")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7Uf5=K44y8YLsiy0aMnc1zvGEQdeDe7RQF=AV+fxxzuQ@mail.gmail.com


# e3f32495 01-Jun-2022 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gp102-: unlock VPR right after devinit

Under memory load, instmem allocations could end up in the regions of
VRAM that are inaccessible right after boot, and be corrupted after a
suspend/resume cycle as a result of being restored before booting the
mem unlock firmware.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>


# 5728d064 01-Jun-2022 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: handle sysmem flush page from common code

- also executes pre-DEVINIT, so early boot is able to DMA sysmem

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>


# b7a9369a 03-Dec-2020 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: switch to instanced constructor

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>


# f5cfbd99 01-Dec-2020 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: protect comptags with private mutex

nvkm_subdev.mutex is going away.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>


# c3463aed 28-Jan-2020 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gp102-: allow module to load even when scrubber binary is missing

Without relaxing this requirement, TU10x boards will fail to load without
an updated linux-firmware, and TU11x will completely fail to load because
FW isn't available yet.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# ebe52a58 14-Jan-2020 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gp102-: unlock VPR as part of FB init

We perform memory allocations long before we hit the code in SECBOOT that
would unlock the VPR, which could potentially result in memory allocation
within the locked region.

Run the scrubber binary right after VRAM init to ensure we don't.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 2d5257b7 10-Dec-2018 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios: translate additional memory types

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 2f958e82 18-Jul-2018 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gp100-: disable address remapper

This was causing problems on a system with a large amount of RAM, where
display push buffers were being fetched incorrectly when placed in high
system memory addresses.

While this commit will resolve the issue on that particular system, the
issue will be avoided completely with another patch to more fully solve
problems with display and large amounts of system memory on Pascal.

It's still probably a good idea to disable this to prevent weird issues
in the future.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 632b740c 31-Oct-2017 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/mmu: remove old vmm frontend

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 997a8900 31-Oct-2017 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/core/memory: add reference counting

We need to be able to prevent memory from being freed while it's still
mapped in a GPU's address-space.

Will be used by upcoming MMU changes.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# af793b8c 31-Oct-2017 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: move comptag init out of ram submodule

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 7ef44bee 31-Oct-2017 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: move comptags mm into nvkm_fb

We're moving towards having a central place to handle comptag allocation,
and as some GPUs don't have a ram submodule (ie. Tegra), we need to move
the mm somewhere else.

It probably never belonged in ram anyways.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 2854ab8d 31-Oct-2017 Ben Skeggs <bskeggs@redhat.com>

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>


# 7ff51f82 08-Jul-2016 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb/gp100: initial support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# c73baa83 08-Jul-2016 Ben Skeggs <bskeggs@redhat.com>

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>


# 99c59172 13-Apr-2016 Ben Skeggs <bskeggs@redhat.com>

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>


# 917d95a8 13-Apr-2016 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: allow chipset-specific actions for oneinit()

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>


# 7624fc01 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/mpeg: convert to new-style nvkm_engine

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# c85ee6ca 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/gr: convert to new-style nvkm_engine

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 03c8952f 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: convert to new-style nvkm_subdev

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 3a8c3400 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/subdev: rename some functions to avoid upcoming conflicts

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# d36a99d2 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: transition nvkm_ram away from being based on nvkm_object

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 3ecd329b 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: switch to subdev printk macros

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 6758745b 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fb: switch to device pri macros

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# b1e4553c 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

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>


# eaecf032 20-Feb-2015 Alexandre Courbot <acourbot@nvidia.com>

make RAM device optional

Having a RAM device does not make sense for chips like GK20A which have
no dedicated video memory. The dummy RAM device that we used so far
works as a temporary band-aid, but in the longer term it is desirable
for the driver to be able to work without any kind of VRAM.

This patch adds a few conditionals in places where a RAM device was
assumed to be present and allows some more objects to be allocated from
the TT domain, allowing Nouveau to handle GPUs for which
pfb->ram == NULL.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 639c308e 13-Jan-2015 Ben Skeggs <bskeggs@redhat.com>

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>


# 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>