aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_platform.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2013-08-30drm: implement experimental render nodesDavid Herrmann1-0/+9
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: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21drm: Make drm_get_platform_dev() staticLespiau, Damien1-4/+3
It's only used in drm_platform.c. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-10-23drm: platform: Don't initialize driver-private dataThierry Reding1-1/+0
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: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells1-1/+1
Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2012-03-07drm: cope with platformdev->id == -1Rob Clark1-2/+10
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: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-10-31gpu: Add export.h as required to drivers/gpu files.Paul Gortmaker1-0/+1
They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-07-15drm: platform multi-device supportRob Clark1-2/+3
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: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-07drm: rework PCI/platform driver interface.Dave Airlie1-3/+72
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: Dave Airlie <airlied@redhat.com>
2010-09-14drm: fix race between driver loading and userspace open.Dave Airlie1-0/+5
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: Dave Airlie <airlied@redhat.com>
2010-06-01drm: Add support for platform devices to register as DRM devicesJordan Crouse1-0/+122
Allow platform devices without PCI resources to be DRM devices. [airlied: fixup warnings with dev pointers] Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Dave Airlie <airlied@redhat.com>