| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Included is a scheme to reference the hwref definitions
which NVIDA uses internally called the "drf def" system.
Signed-off-by: Ken Adams <kadams@nvidia.com>
|
|
|
|
|
|
|
|
| |
These headers are generated from NVIDIA-internal hardware
manuals. For this check-in all chips Nouveau supports
>= nv50/g80 are included.
Signed-off-by: Ken Adams <kadams@nvidia.com>
|
|
|
|
|
|
|
|
|
| |
dma_to_phys() is not guaranteed to be available on all platforms and
should not be used outside of arch/. Replace it with what it is expected
to do in our case: simply cast the DMA handle to a physical address.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GM20B requires a channel kick to be performed during gpfifo cleanup, or
the FIFO will attempt to fetch memory from the previous context as a
channel is recycled. A previous commit attempted to do this for all
Kepler GPUs, but due to bug reports that pinned it down it has been
reverted. The present commit limits its scope to GM20B only.
The only effective change of this patch is to add a call to
gk104_fifo_gpfifo_kick() in gpfifo_fini for GM20B, but doing so requires
to export quite a few extra functions, hence its non-trivial length.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LRU list used for recycling CPU mappings was handling concurrency
very poorly. For instance, if an instobj was acquired twice before being
released once, it would end up into the LRU list even though there is
still a client accessing it.
This patch fixes this by properly counting how many clients are
currently using a given instobj.
While at it, we also raise errors when inconsistencies are detected, and
factorize some code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
| |
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
| |
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Martin Peres <martin.peres@free.fr>
|
|
|
|
|
|
| |
fdo#70354 - comment #88.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
| |
this is needed for my gpu
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
| |
We want to unlock nv_devices_mutex in this error path as well.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this patch a pixel clock rate above 165 MHz on a TMDS link is
assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
supports no dual link, but it supports pixel clock rates above 165 MHz.
Only activate Dual Link mode when it is actually possible and requested.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
[imirkin: check for hdmi monitor for computing proto, use sor ctrl to
enable extra config bit]
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
| |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
| |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
| |
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 <bskeggs@redhat.com>
|
|
|
|
| |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70354#c75
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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 <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
| |
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
| |
Does not seem to be necessary for NVA0, hence untested by me.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
| |
Seems to be mostly equal to DDR3 on < GT218, should improve stability for
DDR2 reclocks.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
| |
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 <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
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: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
| |
GF110+ supports both the A and B compute classes, make sure to accept
both.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
| |
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: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
| |
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: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
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: Sudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
| |
Reported to be needed as per fdo#70354 comment #61.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
| |
Not 100% confirmed, but seems to match from the few boards I've looked
at so far.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
| |
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
| |
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 <bskeggs@redhat.com>
|
|
|
|
|
|
|
| |
An upcoming patch will implement functionality that we don't use on any
NV40 chipset.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
| |
An upcoming patch will implement functionality that we don't use on the
original NV50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
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: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
| |
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 <martin.peres@free.fr>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Martin Peres <martin.peres@free.fr>
|
|
|
|
|
|
|
|
| |
This patch is not ideal but it definitely beats a rewrite of the current
interface and is very self-contained.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
So far the DMA mask was not set for platform devices, which limited them
to a 32-bit physical space. Allow dma_set_mask() to be called for
non-PCI devices, and also take the IOMMU bit into account since it could
restrict the physically addressable space.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|