summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
*---. Merge branches 'staging/fixes', 'staging/gm20b_clk', 'staging/ioctls' and ↵baserock/tegra/4.2Alexandre Courbot2015-11-1133-220/+3953
|\ \ \ | | | | | | | | | | | | 'staging/secure_boot' into staging/work
| | | * gm20b: secure-boot FECS falconAlexandre Courbot2015-11-112-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | Enable secure boot of FECS for GM20B. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| | | * gr: support for securely-booted FECS firmwareAlexandre Courbot2015-11-111-10/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trigger the loading of FECS/GPCCS using secure boot if required, and start managed falcons using the CPUCTL_ALIAS register since CPUCTL is protected in that case. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| | | * core: add support for secure bootAlexandre Courbot2015-11-115-0/+1809
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On GM20x and later GPUs, firmware for some essential falcons (notably FECS) must be authenticated by a NVIDIA-produced signature and loaded by a high-secure falcon in order to access certain registers, in a process known as Secure Boot. Secure Boot requires the building of a binary blob containing the firmwares and signatures of the falcons to be loaded. This blob is then given to a high-secure falcon running a signed loader firmware that copies the blob into a write-protected region, checks that the signatures are valid, and finally loads the verified firmware into the managed falcons and switches them to a priviledged mode. This patch adds code that performs this process using PMU as the high-secure falcon, and wires it into the device core. Currently, only the secure loading of the FECS firmware is handled, but support for other falcons (notably GPCCS and PMU) is upcoming. The reason for limiting to FECS is that GR must initiate the loading of FECS at init time, which, being managed by secure boot, will trigger the loading of all other managed firmwares. A solution to this needs to be discussed. This code is tested on Tegra/GM20B and some minor work is required for dGPU support, but the fundations are here for general support of Secure Boot. This work is based on Deepak Goyal's initial port of Secure Boot to Nouveau. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| | * | drm/nouveau: Support fence fd's at kickoffLauri Peltonen2015-11-114-1/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new NOUVEAU_GEM_PUSHBUF_2 ioctl that accepts and emits a sync fence fd from/to user space if the user space requests it by passing corresponding flags. The new ioctl is only supported on relatively new chips, and it does not support relocations or suffix0/suffix1. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> [acourbot@nvidia.com: carry upstream, fix style] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| | * | gem: Split nv50_dma_pushLauri Peltonen2015-11-113-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split this function to provide a version allowing to directly specify a PB entry in its hardware format. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> [acourbot@nvidia.com: split from longer patch] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| | * | drm/nouveau: Add fence fd helpersLauri Peltonen2015-11-112-1/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add nouveau_fence_install, which installs a drm fence as a file descriptor that can be returned to user space. Add nouveau_fence_sync_fd, which pushes semaphore wait commands for each Nouveau fence contained within the sync fd. If the sync fd contains non-Nouveau fences, those are waited on the CPU. Add missing fence_value_str and timeline_value_str callbacks to nouveau fence_ops. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> [acourbot@nvidia.com: carry patch upstream] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| | * | drm/nouveau: Split nouveau_fence_syncLauri Peltonen2015-11-116-59/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split nouveau_fence_sync to two functions: * nouveau_fence_sync, which only adds a fence wait to the channel command stream, and * nouveau_bo_sync, which gets the fences from the reservation object and passes them to nouveau_fence_sync. This factorizes the code in the new nouveau_fence_sync() which was present twice otherwise. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> [acourbot@nvidia.com: factorize code some more, fix style] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| | * | drm/nouveau: add GEM_SET_TILING staging ioctlAri Hirvonen2015-11-117-21/+95
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling mode for imported dma-bufs. This ioctl is staging for now and enabled with the "staging_tiling" module option. Signed-off-by: Ari Hirvonen <ahirvonen@nvidia.com> [acourbot@nvidia.com: carry upstream, many fixes] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
| * | clk/gk20a: introduce mnp structAlexandre Courbot2015-11-111-20/+26
| | |
| * | optimize gm20bAlexandre Courbot2015-11-111-3/+2
| | |
| * | move stuff around...Alexandre Courbot2015-11-113-138/+111
| | |
| * | clk/gk20a: convert parameters to khz for more precisionAlexandre Courbot2015-11-111-13/+14
| | |
| * | gm20b: quick insertion of clock driverAlexandre Courbot2015-11-114-0/+1426
| | | | | | | | | | | | Need to factorize all the code in common with GK20A
| * | volt: add GM20B driverAlexandre Courbot2015-11-114-0/+119
| | |
| * | drm/nouveau/volt: gk20a: make some reusable functions non-staticVince Hsu2015-11-112-18/+51
| | | | | | | | | | | | | | | | | | | | | The CVB calculation and voltage setting functions can be reused for the future chips. So move the declaration to gk20a.h. Signed-off-by: Vince Hsu <vinceh@nvidia.com>
| * | drm/nouveau/volt: add function get_voltage_by_id()Vince Hsu2015-11-113-0/+11
| | | | | | | | | | | | | | | | | | | | | We need the exact voltage value to calculate the PLL coefficients for GM20B. Signed-off-by: Vince Hsu <vinceh@nvidia.com>
| * | add speedo GPU ID informationAlexandre Courbot2015-11-113-3/+5
| | |
| * | add pll_g reference clockAlexandre Courbot2015-11-112-0/+17
| |/
* | instmem/gk20a: add write barrier when releasing DMA objectAlexandre Courbot2015-11-111-0/+2
| | | | | | | | | | | | | | | | | | When using the DMA-API for instmem, we may obtain a write-combined mapping. For such cases, add a write barrier in gk20a_instobj_release_dma() to make sure that all writes have reached memory at this time. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
* | instmem/gk20a: use DMA API CPU mappingAlexandre Courbot2015-11-112-92/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") tried to be smart while using the DMA-API by managing the CPU mappings of buffers allocated with the DMA-API by itself. In doing so, it relied on dma_to_phys() which is an architecture-private function not available everywhere. This broke the build on several architectures. Since there is no reliable and portable way to obtain the physical address of a DMA-API buffer, stop trying to be smart and just use the CPU mapping that the DMA-API can provide. This means that buffers will be CPU-mapped for all their life as opposed to when we need them, but anyway using the DMA-API here is a fallback for when no IOMMU is available so we should not expect optimal behavior. This makes the IOMMU and DMA-API implementations of instmem diverge enough that we should maybe put them into separate files... Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
* | fifo/gm20b: kick channel during cleanupAlexandre Courbot2015-11-115-24/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | instmem/gk20a: fix race conditionsAlexandre Courbot2015-11-111-29/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | tegra: compile fixesAlexandre Courbot2015-11-113-6/+11
|/
* fifo/gf100: fix race condition when updating engine runlistsBen Skeggs2015-11-113-7/+26
| | | | | | Similar in spirit to the gk104 fix with a similar title. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* fifo/gk104: fix race condition when updating engine runlistsBen Skeggs2015-11-113-7/+26
| | | | | | | | | | The CPU-side tracking of engine runlists was not protected by a lock, leading to list corruption, eventually causing runlist_update() to overrun the GPU-side runlist, triggering an OOPS. Fixes some of the issues noticed during parallel piglit runs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* instmem: protect instobj list with a spinlockBen Skeggs2015-11-112-0/+6
| | | | | | Fixes some of the issues noticed during parallel piglit runs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* nvkm: add/remove 0's to make 7 (or 9)-nibble constants use 8 nibblesIlia Mirkin2015-11-053-6/+6
| | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* volt/pwm/gk104: fix an off-by-one resulting in the voltage not being setMartin Peres2015-11-051-1/+1
| | | | | Reported-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Martin Peres <martin.peres@free.fr>
* pci: enable c800 magic for some unknown Samsung laptopBen Skeggs2015-11-051-1/+7
| | | | | | fdo#70354 - comment #88. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* kms: no need to check for empty edid before drm_detect_hdmi_monitorIlia Mirkin2015-11-051-1/+0
| | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* pci: enable c800 magic for Clevo P157SMKarol Herbst2015-11-051-1/+7
| | | | | | this is needed for my gpu Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* core: fix return in error path of device probeAlexandre Courbot2015-11-051-1/+2
| | | | | | | 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>
* kms: allow 225/297MHz pixel clocks for HDMI on Fermi/KeplerIlia Mirkin2015-11-041-3/+21
| | | | | | | | | 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>
* disp: activate dual link TMDS links only when possibleHauke Mehrtens2015-11-043-6/+13
| | | | | | | | | | | | | 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>
* drm: bump patchlevel to indicate availability of abi16/nvif interopBen Skeggs2015-11-031-1/+3
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* abi16: implement limited interoperability with usif/nvifBen Skeggs2015-11-033-2/+53
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* abi16: introduce locked variant of nouveau_abi16_get()Ben Skeggs2015-11-031-5/+13
| | | | | | | 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>
* abi16: remove unused argument from nouveau_abi16_get()Ben Skeggs2015-11-033-9/+8
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* pci: enable c800 magic for Medion Erazer X7827Ilia Mirkin2015-11-031-0/+1
| | | | | | 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>
* pci: enable c800 magic for Lenovo Y510PIlia Mirkin2015-11-031-1/+7
| | | | | | 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>
* pll/gk104: fix PLL instability due to bad configuration with gddr5Karol Herbst2015-11-031-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>
* clk/g84: Enable reclocking for GDDR3 G94-G200Roy Spliet2015-11-031-1/+1
| | | | | | | | 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>
* bus/hwsq: Implement VBLANK waiting heuristicRoy Spliet2015-11-035-2/+41
| | | | | | | | | 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>
* fb/ramnv50: Script changes for G94 and upRoy Spliet2015-11-031-6/+30
| | | | | | | | | | | 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>
* fb/ramnv50: Deal with cards without timing entriesRoy Spliet2015-11-033-7/+50
| | | | | | | | 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>
* fb/ramnv50: Voltage GPIOsRoy Spliet2015-11-032-0/+42
| | | | | | | | 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>
* fb/ramgt215: Restructure r111100 calculation for DDR2Roy Spliet2015-11-031-30/+34
| | | | | | | | 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>
* fb/ramgt215: Change FBVDD/Q when BIOS asks for itRoy Spliet2015-11-033-0/+20
| | | | | Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* fb/ramgt215: Transform GPIO ramfuc method from FBVREF-specific to genericRoy Spliet2015-11-032-24/+19
| | | | | | | | 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>
View Lorry Controller Status