- 17 2月, 2017 2 次提交
-
-
由 Ben Skeggs 提交于
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: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 28 11月, 2016 1 次提交
-
-
由 Ben Skeggs 提交于
In this situation, we'd have ended up detecting less VRAM than we have. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 17 11月, 2016 1 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 07 11月, 2016 6 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-By: NKarol Herbst <karolherbst@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Reviewed-By: NKarol Herbst <karolherbst@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Baoyou Xie 提交于
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: NBaoyou Xie <baoyou.xie@linaro.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Baoyou Xie 提交于
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: NBaoyou Xie <baoyou.xie@linaro.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 12 10月, 2016 4 次提交
-
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ard Biesheuvel 提交于
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: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Karol Herbst 提交于
This enables memory reclocking on Maxwell. Sadly without a PMU firmware it is useless for gm20x gpus. Signed-off-by: NKarol Herbst <karolherbst@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Karol Herbst 提交于
Signed-off-by: NKarol Herbst <karolherbst@gmail.com> Tested-by: NAidan Epstein <aidan@jmad.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 14 7月, 2016 3 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
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: NBen Skeggs <bskeggs@redhat.com>
-
- 20 5月, 2016 5 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Later chipsets require setting this up both in FB and GR, so let's just move the allocation to FB. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
These are now specified directly in the MC subdev. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 11 1月, 2016 2 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ilia Mirkin 提交于
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 03 11月, 2015 9 次提交
-
-
由 Karol Herbst 提交于
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: NKarol Herbst <nouveau@karolherbst.de> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Avoids waiting for VBLANKS that never arrive on headless or otherwise unconventional set-ups. Strategy taken from MEMX. Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Tested-by: NPierre Moreau <pierre.morrow@free.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
10053c is not even read on some cards, and I have no idea exactly what the criteria are. Likely NVIDIA pre-scans the VBIOS and in their driver disables all features that are never used. The practical effect should be the same as this implementation though. Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Tested-by: NPierre Moreau <pierre.morrow@free.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up. Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Tested-by: NPierre Moreau <pierre.morrow@free.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Does not seem to be necessary for NVA0, hence untested by me. Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Tested-by: NPierre Moreau <pierre.morrow@free.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Seems to be mostly equal to DDR3 on < GT218, should improve stability for DDR2 reclocks. Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
In preparation of changing FBVDDQ, as observed on at least one GDDR3 card. While at it, adhere to func.log[1] properly for consistency. Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 28 8月, 2015 7 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-