- 25 Nov, 2015 8 commits
-
-
Ben Skeggs authored
Somehow missed these two when removing dodgy void casts during the rework. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
fdo#92761 Signed-off-by: -
Ben Skeggs authored
Each GPCCS unit was reading the mask from GPC0, which causes problems on boards where some GPCs are missing PPCs. Part of the fix for fdo#92761. Signed-off-by: -
Ben Skeggs authored
There's a few places where we need to access a GPC register from ucode, but outside of the falcon's io address space. To do this we need to calculate the offset based on which GPC we're executing on. This used to be done manually, but we've since found a "base" offset that can be added by the hardware. To use this, an extra bit needs to be set in the register address, which is what this macro achieves. There should be no functional change from this commit. Signed-off-by: -
Ben Skeggs authored
Fixes detection of a failed attempt at fetching the entire ROM image in one-shot (a violation of the spec, that works a lot of the time). Tested on a HP Zbook 15 G2. Signed-off-by: -
Ben Skeggs authored
No locking is required for the traversal of this list, as it only happens during suspend/resume where nothing else can be executing. Fixes some of the issues noticed during parallel piglit runs. Signed-off-by: -
Ben Skeggs authored
fdo#70354 - comment #88. Signed-off-by: -
Karol Herbst authored
this is needed for my gpu Signed-off-by:
-
- 03 Nov, 2015 32 commits
-
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
USIF already takes the client mutex, but will need access to ABI16 data in order to provide some limited interoperability. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ilia Mirkin authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Ilia Mirkin authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70354#c75Signed-off-by:
-
Karol Herbst authored
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:
-
Roy Spliet authored
Your milage may vary, as it's only been tested on a single G94 and one G96. Signed-off-by:
Roy Spliet <rspliet@eclipso.eu> Tested-by:
Pierre Moreau <pierre.morrow@free.fr> Signed-off-by:
-
Roy Spliet authored
Avoids waiting for VBLANKS that never arrive on headless or otherwise unconventional set-ups. Strategy taken from MEMX. Signed-off-by:
-
Roy Spliet authored
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:
-
Roy Spliet authored
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up. Signed-off-by:
-
Roy Spliet authored
Does not seem to be necessary for NVA0, hence untested by me. Signed-off-by:
-
Roy Spliet authored
Seems to be mostly equal to DDR3 on < GT218, should improve stability for DDR2 reclocks. Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
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:
-
Roy Spliet authored
Signed-off-by:
-
Pierre Moreau authored
If the hardware supports extended tag field (8-bit ones), then enable it. This is usually done by the VBIOS, but not on some MBPs (see fdo#86537). In case extended tag field is not supported, 5-bit tag field is used which limits the possible number of requests to 32. Apparently bits 7:0 of 0x08841c stores some number of outstanding requests, so cap it to 32 if extended tag is unsupported. Fixes: fdo#86537 v2: Restrict changes to chipsets >= 0x84 v3: * Add nvkm_pci_mask to pci.h * Mask bit 8 before setting it v4: * Rename `add` argument of nvkm_pci_mask to `value` * Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset checks v5: * Rebase code on latest PCI structure * Restore PCIe check * Fix namings in nvkm_pci_mask * Rephrase part of the commit message Signed-off-by: -
Julia Lawall authored
These nvkm_object_func structures are never modified. All other nvkm_object_func structures are declared as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Ilia Mirkin authored
GF110+ supports both the A and B compute classes, make sure to accept both. Signed-off-by:
-
Ilia Mirkin authored
NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE, which apparently happens when trying to use an atomic operation on local or shared memory (instead of global memory). Signed-off-by:
-
Sudip Mukherjee authored
If pm_runtime_get_sync() we were going to "out" but we missed freeing vma. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Sudip Mukherjee authored
coverity.com reported that memset was using a buffer of size 0, on checking the code it turned out that the function was not being used. So remove it. Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Signed-off-by:
-
Ben Skeggs authored
Reported to be needed as per fdo#70354 comment #61. Signed-off-by: -
Ben Skeggs authored
Not 100% confirmed, but seems to match from the few boards I've looked at so far. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Was not able to obtain a trace of NVRM due to kernel version annoyances, however, experimentally confirmed that the WAR we use on NV50/G8x boards works here too. Signed-off-by: -
Ben Skeggs authored
An upcoming patch will implement functionality that we don't use on any NV40 chipset. Signed-off-by: -
Ben Skeggs authored
An upcoming patch will implement functionality that we don't use on the original NV50. Signed-off-by: -
Samuel Pitoiset authored
Increase clock timeout of some unknown engines in order to avoid failure at high gpcclk rate. This fixes IBUS read faults on my GF119 when reclocking is manually enabled. Note that memory reclocking is completely broken and NvMemExec has to be disabled to allow core clock reclocking only. Signed-off-by:
-
Martin Peres authored
I got confirmation that we can read and change the voltage with the same code. The divider is also computed correctly on the gm204 we got our hands on. Thanks to Yoshimo on IRC for executing the tests on his gm204! Signed-off-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Martin Peres authored
Let's ignore the other desktop Maxwells until I get my hands on one and confirm that we still can change the voltage. Signed-off-by: -
Martin Peres authored
Most Keplers actually use the GPIO-based voltage management instead of the new PWM-based one. Use the GPIO mode as a fallback as it already gracefully handles the case where no GPIOs exist. All the Maxwells seem to use the PWM method though. v2: - Do not forget to commit the PWM configuration change! Signed-off-by:
-
