- 02 Dec, 2014 40 commits
-
-
Ben Skeggs authored
Preparation for transition to planes, which use framebuffers for the cursor image. We've always done copies from the userspace buffer up until now for legacy reasons, there's no good reason to do so on the chipsets this code covers. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We have the ability to move buffers around in the kernel if necessary, and should probably use it rather than failing if userspace passes us a non-contig buffer for a plane. The NOUVEAU_GEM_TILE_NONCONTIG flag from userspace will become a mere initial placement hint once all the relevant paths have been updated. Signed-off-by: -
Vince Hsu authored
The voltage value are calculated by the hardware characterized result. Signed-off-by:
Vince Hsu <vinceh@nvidia.com> Reviewed-by:
Alexandre Courbot <acourbot@nvidia.com> Acked-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Vince Hsu authored
For GK20A we need the GPU speedo value to calculate voltage levels. Signed-off-by:
-
Vince Hsu authored
Move the vbios parsing out of init() and call it conditionally if the platform has a vbios. Non-vbios platforms can use the ctor() to init the data structures. Signed-off-by:
-
Ben Skeggs authored
This allows the module to load without acceleration. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
A machine has been spotted where the ramcfg strap is "8", and the ramcfg xlat table goes 0-7,0-7, resulting in us selecting config 0 for memory items. On this particular system, config "8" is available and supposed to be used. It appears that starting from GT21x (where Mv2 appears), we're supposed to use the value in this table instead. One concern here is that not all the places we currently use ramcfg xlat are supposed to be treated the same now. The strap xlat table wasn't removed from the vbios either, presumably for some kind of good reason. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We only support one kind of matching here (ramcfg strap), but it appears alternate methods are possible. I wrote a tool to scan our vbios repo for other types, but did not see any used. Hopefully this means there aren't any in the wild that will now break. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
For the moment, just used to speed up vbios-only testing. Have some ideas for extending in the future. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Alexandre Courbot authored
For some reason max_vco was set to a lower value that it can support, which prevented some clock states to be applied. Fix this by setting it to the same value as downstream. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Alexandre Courbot authored
On architectures for which access to GPU memory is non-coherent, caches need to be flushed and invalidated explicitly when BO control changes between CPU and GPU. This patch adds buffer synchronization functions which invokes the correct API (PCI or DMA) to ensure synchronization is effective. Based on the TTM DMA cache helper patches by Lucas Stach. Signed-off-by:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
-
Alexandre Courbot authored
Specify TTM_PL_FLAG_UNCACHED when allocating GPFIFOs and fences to allow them to be safely accessed by the kernel without being synced on non-coherent architectures. Signed-off-by:
-
Alexandre Courbot authored
Allow nouveau_bo_new() to recognize the TTM_PL_FLAG_UNCACHED flag, which means that we want the allocated BO to be perfectly coherent between the CPU and GPU. This is useful on non-coherent architectures for which we do not want to manually sync some rarely-accessed buffers: typically, fences and pushbuffers. A TTM BO allocated with the TTM_PL_FLAG_UNCACHED on a non-coherent architecture will be populated using the DMA API, and accesses to it performed using the coherent mapping performed by dma_alloc_coherent(). Signed-off-by:
-
Alexandre Courbot authored
Add a function allowing us to know whether a device is CPU-coherent, i.e. accesses performed by the CPU on GPU-mapped buffers will be immediately visible on the GPU side and vice-versa. For now, a device is considered to be coherent if it uses the PCI bus on a non-ARM architecture. Signed-off-by:
-
Alexandre Courbot authored
Pinned BOs are supposed to remain in their current location until unpinned. Display a warning for the supposedly-erroneous case where we are trying to move such objects. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Roy Spliet authored
Signed-off-by: -
Roy Spliet authored
Signed-off-by:
Roy Spliet <rspliet@eclipso.eu> Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
V2: fix whitespace errors in memx.fuc Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Ben Skeggs authored
No code changes. Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
