- 02 Dec, 2014 40 commits
-
-
Ben Skeggs authored
Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
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 <acourbot@nvidia.com> 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: -
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
Probably missing something here, doesn't make a lot of sense to write or+link data into a register whose offset is calculated by the same or+link info.. This is the all I've witnessed the binary driver and vbios doing so far, so it'll do. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
The binary driver has been doing this since GF119, and we've somehow gotten away with it. But, TMDS that hasn't been initialised already by the x86 vbios code is distorted without it on GM204. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Not entirely sure why this got bumped at all yet. 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: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Left-over from before a rework a while back. Signed-off-by: -
Ben Skeggs authored
Logging at trace level, rather than as en error, as it seems conceivable that failure could be normal under certain circumstances (new bios, older sink that doesn't support a particular DPCD address) Signed-off-by:
-
