| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
RM does this for some reason, and is enforced in HW on Volta.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
RM does this for some reason.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Newer HW doesn't appear to send this event, which will cause long delays
in runlist updates if they don't complete immediately.
RM doesn't use these events anywhere, and an NVGPU commit message notes
that polling is the preferred method even on HW that supports the event.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This will be required to support features on newer hardware.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
allocation
We didn't used to be aware that runlist/engine IDs weren't the same thing,
or that there was such variability in configuration between GPUs.
By exposing this information to a client, and giving it explicit control
of which runlist it's allocating a channel on, we're able to make better
choices.
The immediate effect of this is that on GPUs where CE0 is the "GRCE", we
will now be allocating a copy engine running asynchronously to GR for BO
migrations - as intended.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Will be used to improve channel runlist selection.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This will be required to support Volta.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
These can exist on GP100 and newer.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Will be used for fifo runlist selection.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
properties
We have a need to fetch data from GPU-specific sub-devices that is not
tied to any particular engine object.
This commit provides the framework to support such queries.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This will be required to support Volta, but also allows us to remove code
that's duplicated for each channel type already.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This will be required to support Volta.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Unnecessarily complicated, and a barrier to cleanly supporting Volta.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Introduces a new method of defining channels available from the display,
common to all channel types, allowing for more flexibility in available
channel types/counts, and reducing the amount of boiler-plate required.
This will be required to support Volta.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
More simplification.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Engines are initialised on an as-needed basis, so this results in the
same behaviour, whilst allowing us to simplify things a bit.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
We should be reading registers to determine which subunits are really
present on a given board, and this needs to be done after DEVINIT.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Likely a rebase bug. Should have no impact in default configuration due
to using per-instance setting by default.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
GPU-specific support will be added separately.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This will be responsible for the handling of MMU fault buffers on GPUs
that support them.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
In preparation to enabling -Wvla, remove VLA. In this particular
case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local
variable cmdline_size. Also, remove cmdline_size as it is not
actually useful anymore.
The use of stack Variable Length Arrays needs to be avoided, as they
can be a vector for stack exhaustion, which can be both a runtime bug
or a security flaw. Also, in general, as code evolves it is easy to
lose track of how big a VLA can get. Thus, we can end up having runtime
failures that are hard to debug.
Also, fixed as part of the directive to remove all VLAs from
the kernel: https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
gcc points out a buffer that is clearly too small to be used
in a meaningful way, as the 'sizeof(*args) + argc > sizeof(stack)'
will always fail:
In function 'memcpy',
inlined from 'nvif_vmm_map' at drivers/gpu/drm/nouveau/nvif/vmm.c:55:2:
include/linux/string.h:353:9: error: '__builtin_memcpy' offset 40 is out of the bounds [0, 16] of object 'stack' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds]
return __builtin_memcpy(p, q, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/nouveau/nvif/vmm.c: In function 'nvif_vmm_map':
drivers/gpu/drm/nouveau/nvif/vmm.c:40:5: note: 'stack' declared here
This makes the buffer large enough so it should serve the purpose
that the author presumably had in mind. Alternatively we could
just get rid of it completely and simplify the code at the cost
of always doing the kmalloc (as we do in the current version).
Fixes: 920d2b5ef215 ("drm/nouveau/mmu: define user interfaces to mmu vmm opertaions")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Need to backmerge some nouveau fixes to reduce
the nouveau -next conflicts a lot.
Signed-off-by: Dave Airlie <[email protected]>
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
- Userptr IOCTL zero size check (Matt)
- Two hardware quirk fixes (Michel & Chris)
* tag 'drm-intel-fixes-2018-05-17' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk
drm/i915/execlists: Use rmb() to order CSB reads
drm/i915/userptr: reject zero user_size
|
|
Now that our destroy function is the same as the helper, use that
directly.
Signed-off-by: Daniel Stone <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: [email protected]
Signed-off-by: Thierry Reding <[email protected]>
|
|
User framebuffers are created with either bo->pages or bo->vaddr set,
depending on whether or not an IOMMU is present. On the other hand, the
framebuffer created for fbdev emulation has a vaddr mapping made if
bo->pages is set after creation. This is set up in fbdev probe.
Remove the special case unmapping from the general-purpose framebuffer
destroy, and move it to fbdev teardown.
Signed-off-by: Daniel Stone <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: [email protected]
Signed-off-by: Thierry Reding <[email protected]>
|
|
Since tegra_fb is now the same as drm_framebuffer, we can just replace
the type completely.
Signed-off-by: Daniel Stone <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: [email protected]
Signed-off-by: Thierry Reding <[email protected]>
|
|
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.
Signed-off-by: Daniel Stone <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: [email protected]
Signed-off-by: Thierry Reding <[email protected]>
|
|
drm_framebuffer already stores num_planes for us.
Signed-off-by: Daniel Stone <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: [email protected]
Signed-off-by: Thierry Reding <[email protected]>
|
|
Use new return type vm_fault_t for fault handler. For now, this is just
documenting that the function returns a VM_FAULT value rather than an
errno. Once all instances are converted, vm_fault_t will become a
distinct type.
Reference id -> 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_page() returns err which driver mapped into
VM_FAULT_* type. The new function vmf_insert_page() will replace this
inefficiency by returning VM_FAULT_* type.
Signed-off-by: Souptick Joarder <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The IOVA API uses a memory cache to allocate IOVA nodes from. To make
sure that this cache is available, obtain a reference to it and release
the reference when the cache is no longer needed.
On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
that reference and never releases it. On 32-bit ARM, this is papered
over by the Tegra DRM driver (the sole user of the host1x API requiring
the cache) acquiring a reference to the IOVA cache for its own purposes.
However, there may be additional users of this API in the future, so fix
this upfront to avoid surprises.
Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
Reviewed-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The IOVA API uses a memory cache to allocate IOVA nodes from. To make
sure that this cache is available, obtain a reference to it and release
the reference when the cache is no longer needed.
On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
that reference and never releases it. On 32-bit ARM, however, the DMA
mapping API doesn't do that, so allocation of IOVA nodes fails.
Fixes: ad92601521ea ("drm/tegra: Add Tegra DRM allocation API")
Reviewed-by: Dmitry Osipenko <[email protected]>
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|