- 30 8月, 2013 1 次提交
-
-
由 David Herrmann 提交于
Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 21 8月, 2013 1 次提交
-
-
由 Lespiau, Damien 提交于
It's only used in drm_platform.c. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 10月, 2012 1 次提交
-
-
由 Thierry Reding 提交于
Platform device drivers usually use the driver-private data for their own purposes. Having it overwritten by drm_platform_init() is confusing and error-prone. Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 03 10月, 2012 1 次提交
-
-
由 David Howells 提交于
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NDave Airlie <airlied@redhat.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: NDave Jones <davej@redhat.com>
-
- 07 3月, 2012 1 次提交
-
-
由 Rob Clark 提交于
If there are not multiple instances of a platform device, the id should apparently be set to -1. Which results in a odd looking bus-id like "platform:foodrm:-1". Probably we should just treat this case as id 0. Signed-off-by: NRob Clark <rob@ti.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 01 11月, 2011 1 次提交
-
-
由 Paul Gortmaker 提交于
They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 15 7月, 2011 1 次提交
-
-
由 Rob Clark 提交于
Include the device id in the bus-id to give userspace a way to open the correct "cardN" when there are multiple device instances. Signed-off-by: NRob Clark <rob@ti.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 07 2月, 2011 1 次提交
-
-
由 Dave Airlie 提交于
This abstracts the pci/platform interface out a step further, we can go further but this is far enough for now to allow USB to be plugged in. The drivers now just call the init code directly for their device type. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 14 9月, 2010 1 次提交
-
-
由 Dave Airlie 提交于
Not 100% sure this is due to BKL removal, its most likely a combination of that + userspace timing changes in udev/plymouth. The drm adds the sysfs device before the driver has completed internal loading, this causes udev to make the node and plymouth to open it before we've completed loading. The proper solution is to delay the sysfs manipulation until later in loading however this causes knock on issues with sysfs connector nodes, so we can use the global mutex to serialise loading and userspace opens. Reported-by: Toni Spets (hifi on #radeon) Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 01 6月, 2010 1 次提交
-
-
由 Jordan Crouse 提交于
Allow platform devices without PCI resources to be DRM devices. [airlied: fixup warnings with dev pointers] Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-