summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/nvkm/subdev/fb
AgeCommit message (Collapse)AuthorFilesLines
2017-11-02drm/nouveau/mmu: remove old vmm frontendBen Skeggs30-82/+0
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb/ram: use new interfaces for vmm operationsBen Skeggs1-4/+14
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb/gm200: enable NV_PFB_MMU_CTRL_USE_FULL_COMP_TAG_LINE where ↵Ben Skeggs1-3/+3
appropriate To avoid wasting compression tags when using 64KiB pages, we need to enable this so we can select between upper/lower comptagline in PTEs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb/ram: remove old allocatorsBen Skeggs10-163/+0
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau: directly handle comptag allocationBen Skeggs2-35/+0
Another transition step to allow finer-grained patches transitioning to new MMU backends. Old backends will continue operate as before (accessing nvkm_mem::tag), and new backends will get a reference to the tags allocated here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau: wrap nvkm_mem objects in nvkm_memory interfacesBen Skeggs1-0/+1
This is a transition step, to enable finer-grained commits while transitioning to new MMU interfaces. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb/ram/gt215: allocate training buffer with nvkm_ram_get()Ben Skeggs1-9/+9
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb/ram: add interface to allocate vram as an nvkm_memory objectBen Skeggs1-0/+122
Upcoming MMU changes use nvkm_memory as its basic representation of memory, so we need to be able to allocate VRAM like this. The code is basically identical to the current chipset-specific allocators, minus support for compression tags (which will be handled elsewhere anyway). Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/core/memory: add reference countingBen Skeggs1-2/+2
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>
2017-11-02drm/nouveau/fb/gf100: clear comptags at allocation time rather than mmu mapBen Skeggs1-1/+5
We probably don't want to destroy compression data when doing multiple mappings of a memory object. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb: move comptag init out of ram submoduleBen Skeggs30-38/+63
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb: move comptags mm into nvkm_fbBen Skeggs9-12/+12
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>
2017-11-02drm/nouveau/core/mm: have users explicitly define heap identifiersBen Skeggs4-7/+13
Different sections of VRAM may have different properties (ie. can't be used for compression/display, can't be mapped, etc). We currently already support this, but it's a bit magic. This change makes it more obvious where we're allocating from. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/fb: finalise big page size selection in constructorBen Skeggs10-26/+32
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-08-22drm/nouveau/fb/gf100-: zero mmu debug buffersBen Skeggs1-2/+2
These are used for accesses to sparse mappings, and we want reads of such mappings to return 0. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/fb/ram/nv40-: use new devinit script interpreter entry-pointBen Skeggs3-22/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-12drm/nouveau/fb/ram/gf100-: remove 0x10f200 readBen Skeggs1-1/+0
This reg has moved on Pascal, and causes a bus fault. We never use the value anyway, so just remove the read. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-04-29drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detectionMario Kleiner1-1/+1
A missing u64 cast causes a 32-Bit wraparound from 4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected if card has 4096 Mib per FBP. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-04-06drm/nouveau/fb: add GP10B supportAlexandre Courbot2-0/+39
GP10B's FB is largely compatible with the GP100 implementation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/fb/gf100-: rework ram detectionBen Skeggs7-101/+173
This commit reworks the RAM detection algorithm, using RAM-per-LTC to determine whether a board has a mixed-memory configuration instead of using RAM-per-FBPA. I'm not certain the algorithm is perfect, but it should handle all currently known configurations in the very least. This should fix GTX 970 boards with 4GiB of RAM where the last 512MiB isn't fully accessible, as well as only detecting half the VRAM on GF108 boards. As a nice side-effect, GP10x memory detection now reuses the majority of the code from earlier chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/fb/gm200: split ram implementation from gm107Ben Skeggs4-1/+44
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/fb/gf108: split implementation from gf100Ben Skeggs4-0/+85
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/fb/gf100-: modify constructors to allow more customisationBen Skeggs4-52/+81
GF108/GM107 implementations will want slightly different functions for the upcoming RAM detection improvements. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau: fix bug id typo in commentIlia Mirkin1-1/+1
The issue was recorded in fd.o bug 27501, not 25701. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/core/mm: replace region list with next pointerBen Skeggs2-18/+15
We never have any need for a double-linked list here, and as there's generally a large number of these objects, replace it with a single- linked list in order to save some memory. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/fb/ram/gk104: remove unused best_clk variableBen Skeggs1-3/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/fb/ram/gp100-: fix memory detection where FBP_NUM != FBPA_NUMBen Skeggs1-2/+2
In this situation, we'd have ended up detecting less VRAM than we have. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/fb/gp102: rename from gp104Ben Skeggs2-4/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau: silence sparse warnings about symbols not being marked staticBen Skeggs1-2/+0
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/fb: add gm20b deviceAlexandre Courbot4-1/+46
gm20b's FB has the same capabilities as gm200, minus the ability to allocate RAM. Create a device that reflects this instead of re-using the gk20a device which may be incorrect. 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-07drm/nouveau/fb/gk20a: use regular gf100's functionsAlexandre Courbot1-12/+5
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-07drm/nouveau/fb/gk20a: fix constructor callAlexandre Courbot1-1/+2
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-07drm/nouveau: mark symbols static where possibleBaoyou Xie1-4/+4
We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous prototype for 'nvbios_fan_entry' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous prototype for 'gt215_link_train_calc' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous prototype for 'gt215_link_train' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous prototype for 'gt215_link_train_init' [-Wmissing-prototypes] .... In fact, both functions are only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau: add missing header dependenciesBaoyou Xie2-0/+2
We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous prototype for 'nvkm_sddr3_calc' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c:60:1: warning: no previous prototype for 'nvkm_sddr2_calc' [-Wmissing-prototypes] .... In fact, these functions are declared in drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h drivers/gpu/drm/nouveau/nvkm/subdev/volt/priv.h drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.h drivers/gpu/drm/nouveau/dispnv04/disp.h. So this patch adds missing header dependencies. Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit() hookArd Biesheuvel1-10/+18
The 100c08 scratch page is mapped using dma_map_page() before the TTM layer has had a chance to set the DMA mask. This means we are still running with the default of 32 when this code executes, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .oneinit hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit() hookArd Biesheuvel1-12/+13
The 100c10 scratch page is mapped using dma_map_page() before the TTM layer has had a chance to set the DMA mask. This means we are still running with the default of 32 when this code executes, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .oneinit hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/fb/ram: Use Kepler implementation on MaxwellKarol Herbst3-12/+9
This enables memory reclocking on Maxwell. Sadly without a PMU firmware it is useless for gm20x gpus. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/fb/ramgk104: Touch 0x62c000 only when there is a display engineKarol Herbst1-4/+12
Signed-off-by: Karol Herbst <karolherbst@gmail.com> Tested-by: Aidan Epstein <aidan@jmad.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gp104: initial supportBen Skeggs4-1/+47
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gp100: initial supportBen Skeggs7-1/+224
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gf100-: allow selection of an alternate big page sizeBen Skeggs7-3/+45
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-05-20drm/nouveau/fb/gm200: setup mmu debug buffer registers at init()Ben Skeggs2-0/+61
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/fb/gk20a,gm20b: setup mmu debug buffer registers at init()Ben Skeggs1-0/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/fb/gf100-: allocate mmu debug buffersBen Skeggs6-0/+34
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-20drm/nouveau/fb: allow chipset-specific actions for oneinit()Ben Skeggs2-0/+9
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/core: remove pmc_enable argument from subdev ctorBen Skeggs1-1/+1
These are now specified directly in the MC subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-01-11drm/nouveau/fb/nv50: remove references to "daemon"Ben Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-01-11drm/nouveau/nvkm: add/remove 0's to make 7 (or 9)-nibble constants use 8 nibblesIlia Mirkin1-4/+4
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5Karol Herbst1-23/+77
This patch uses an approach closer to the nvidia driver to configure both PLLs for high gddr5 memory clocks (usually above 2400MHz) Previously nouveau used the one PLL as it was used for the lower clocks and just adjusted the second PLL to get as close as possible to the requested clock. This means for my card, that I got a 4050 MHz clock although 4008 MHz was requested. Now the driver iterates over a list of PLL configuration also used by the nvidia driver and then adjust the second PLL to get near the requested clock. Also it hold to some restriction I found while analyzing the PLL configurations This won't fix all gddr5 high clock issues itself, but it should be fine on hybrid gpu systems as found on many laptops these days. Also switching while normal desktop usage should be a lot more stable than before. v2: move the pll code into ramgk104 Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/bus/hwsq: Implement VBLANK waiting heuristicRoy Spliet2-2/+2
Avoids waiting for VBLANKS that never arrive on headless or otherwise unconventional set-ups. Strategy taken from MEMX. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-25 09:09:33 +0300