similar to: [PATCH 08/13] drm/nouveau: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls

Displaying 20 results from an estimated 400 matches similar to: "[PATCH 08/13] drm/nouveau: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls"

2019 Jun 06
0
[PATCH 08/13] drm/nouveau: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls
On Mon, 27 May 2019 at 09:19, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > From: Emil Velikov <emil.velikov at collabora.com> > > The authentication can be circumvented, by design, by using the render > node. > > From the driver POV there is no distinction between primary and render > nodes, thus we can drop the token. > > Note: the outstanding
2019 May 27
2
[PATCH 12/13] drm/virtio: drop DRM_AUTH usage from the driver
From: Emil Velikov <emil.velikov at collabora.com> The authentication can be circumvented, by design, by using the render node. >From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Cc: David Airlie <airlied at linux.ie> Cc: Daniel
2019 May 27
2
[PATCH 12/13] drm/virtio: drop DRM_AUTH usage from the driver
From: Emil Velikov <emil.velikov at collabora.com> The authentication can be circumvented, by design, by using the render node. >From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Cc: David Airlie <airlied at linux.ie> Cc: Daniel
2019 May 22
3
[PATCH 2/2] drm/nouveau: remove open-coded drm_invalid_op()
From: Emil Velikov <emil.velikov at collabora.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Emil Velikov <emil.velikov at collabora.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 ------ drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 - drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- 3 files changed, 1 insertion(+), 8
2015 May 21
2
[PATCH 1/2] drm/nouveau: add staging module option
On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add a module option allowing to enable staging/unstable APIs. This will > allow us to experiment freely with experimental APIs for a while before > setting them in stone. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drm/nouveau/nouveau_drm.c | 18
2015 May 21
2
[PATCH 1/2] drm/nouveau: add staging module option
On 21 May 2015 at 15:49, Alexandre Courbot <gnurou at gmail.com> wrote: > On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Add a module option allowing to enable staging/unstable APIs. This will >>> allow us to experiment freely with experimental
2015 May 20
3
[PATCH 0/2] drm/nouveau: option for staging ioctls and new SET_TILING ioctl
This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to specify the tiling options of a PRIME-imported buffer. The staging parameter will allow us
2015 Jun 15
4
[PATCH v2 0/2] drm/nouveau: option for staging ioctls and new GEM_SET_TILING ioctl
Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to
2014 Sep 26
14
[RFC] Explicit synchronization for Nouveau
Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes
2015 Sep 09
3
[PATCH 3/5] update virtio gpu driver: add 3d/virgl support
Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/Makefile | 3 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 + drivers/gpu/drm/virtio/virtgpu_drv.h | 60 ++++
2015 Sep 09
3
[PATCH 3/5] update virtio gpu driver: add 3d/virgl support
Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/Makefile | 3 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 + drivers/gpu/drm/virtio/virtgpu_drv.h | 60 ++++
2019 Jun 06
0
[PATCH 12/13] drm/virtio: drop DRM_AUTH usage from the driver
On Mon, 27 May 2019 at 09:19, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > From: Emil Velikov <emil.velikov at collabora.com> > > The authentication can be circumvented, by design, by using the render > node. > > From the driver POV there is no distinction between primary and render > nodes, thus we can drop the token. > > Cc: Gerd Hoffmann
2018 Jan 11
3
[PATCH 0/3] drm/nouveau: Add support for fence FDs
From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the
2015 Aug 31
8
[RFC PATCH v2 0/5] More explicit pushbuf error handling
Hi there, Resending these now that they've had some more polish and testing, and I heard that Ben's vacation is over :-) These patches work as a starting point for more explicit error mechanisms and better robustness. At the moment, when a job hangs or faults, it seems that nouveau doesn't quite know how to handle the situation and often results in a hang. Some of these situations
2015 Sep 21
2
[PATCH v2 4/6] virtio-gpu: add 3d/virgl support
Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/Makefile | 3 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 + drivers/gpu/drm/virtio/virtgpu_drv.h | 60 ++++
2015 Sep 21
2
[PATCH v2 4/6] virtio-gpu: add 3d/virgl support
Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/Makefile | 3 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 + drivers/gpu/drm/virtio/virtgpu_drv.h | 60 ++++
2019 May 23
0
[PATCH 2/2] drm/nouveau: remove open-coded drm_invalid_op()
On Thu, 23 May 2019 at 01:03, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > From: Emil Velikov <emil.velikov at collabora.com> > > Cc: Ben Skeggs <bskeggs at redhat.com> > Cc: nouveau at lists.freedesktop.org > Signed-off-by: Emil Velikov <emil.velikov at collabora.com> Thanks! > --- > drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 ------ >
2020 Sep 16
2
[PATCH v2 04/21] drm/exynos: Introduce GEM object functions
On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in exynos. The only exception is gem_prime_mmap, > which is non-trivial to convert. > > Signed-off-by: Thomas Zimmermann <tzimmermann at
2017 Dec 28
3
[PATCH] drm/virtio: Add window server support
This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified
2017 Dec 28
3
[PATCH] drm/virtio: Add window server support
This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified