summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_platform.c
AgeCommit message (Collapse)Author
2014-09-10drm: Goody bye, drm_bus!David Herrmann
..we will not miss you.. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-09-10drm: add driver->set_busid() callbackDavid Herrmann
One step closer to dropping all the drm_bus_* code: Add a driver->set_busid() callback and make all drivers use the generic helpers. Nouveau is the only driver that uses two different bus-types with the same drm_driver. This is totally broken if both buses are available on the same machine (unlikely, but lets be safe). Therefore, we create two different drivers for each platform during module_init() and set the set_busid() callback respectively. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-09-10drm: drop unused drm_master->unique_sizeDavid Herrmann
This field is unused and there is really no reason to optimize unique-allocations. Drop it. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-09-10drm: simplify drm_*_set_unique()David Herrmann
Lets use kasprintf() to avoid pre-allocating the buffer. This is really nothing to optimize for speed and the input is trusted, so kasprintf() is just fine. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-06-05drm: Add device registration documentationThierry Reding
Describe how devices are registered using the drm_*_init() functions. Adding this to docbook requires a largish set of changes to the comments in drm_{pci,usb,platform}.c since they are doxygen-style rather than proper kernel-doc and therefore mess with the docbook generation. While at it, mark usage of drm_put_dev() as discouraged in favour of calling drm_dev_unregister() and drm_dev_unref() directly. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-23drm: Remove dev->kdriverDaniel Vetter
With the last patch to ditch the ->get_name callbacks the last user is now gone. Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-23drm: remove drm_bus->get_nameDaniel Vetter
The only user is the info debugfs file, so we only need something human readable. Now for both pci and platform devices we've used the name of the underlying device driver, which matches the name of the drm driver in all cases. So we can just use that instead. The exception is usb, which used a generic "USB". Not to harmful with just one usb driver, but better to use "udl", too. With that converted we can rip out all the ->get_name implementations. Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-23drm: rip out dev->devnameDaniel Vetter
This was only ever used to pretty-print the irq driver name. And on kms systems due to set_version bonghits we never set up the prettier name, ever. Which make this a bit pointless. Also, we can always dig out the driver-instance/irq relationship through other means, so this isn't that useful. So just rip it out to simplify the set_version/set_busid insanity a bit. Also delete the temporary busname from drm_pci_set_busid, it's now unused. v2: Rebase on top of the new host1x drm_bus for tegra. Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-23drm: remove bus->get_irq implementationsDaniel Vetter
Now that they're all unused we can get rid of them, including the dummy version in drm_usb.c. Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-22drm: kill drm_bus->bus_typeDaniel Vetter
Completely unused. Hooray, midlayer mistakes that didn't cause work to undo! v2: Rebase on top of the recent tegra changes which added a host1x drm bus. Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-16drm: provide device-refcountDavid Herrmann
Lets not trick ourselves into thinking "drm_device" objects are not ref-counted. That's just utterly stupid. We manage "drm_minor" objects on each drm-device and each minor can have an unlimited number of open handles. Each of these handles has the drm_minor (and thus the drm_device) as private-data in the file-handle. Therefore, we may not destroy "drm_device" until all these handles are closed. It is *not* possible to reset all these pointers atomically and restrict access to them, and this is *not* how this is done! Instead, we use ref-counts to make sure the object is valid and not freed. Note that we currently use "dev->open_count" for that, which is *exactly* the same as a reference-count, just open coded. So this patch doesn't change any semantics on DRM devices (well, this patch just introduces the ref-count, anyway. Follow-up patches will replace open_count by it). Also note that generic VFS revoke support could allow us to drop this ref-count again. We could then just synchronously disable any fops->xy() calls. However, this is not the case, yet, and no such patches are in sight (and I seriously question the idea of dropping the ref-cnt again). Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
2013-12-18drm: restrict the device list for shadow attached driversDaniel Vetter
There's really no need for the drm core to keep a list of all devices of a given driver - the linux device model keeps perfect track of this already for us. The exception is old legacy ums drivers using pci shadow attaching. So rename the lists to make the use case clearer and rip out everything else. v2: Rebase on top of David Herrmann's drm device register changes. Also drop the bogus dev_set_drvdata for platform drivers that somehow crept into the original version - drivers really should be in full control of that field. v3: Initialize driver->legacy_dev_list outside of the loop, spotted by David Herrmann. v4: Rebase on top of the newly created host1x drm_bus for tegra. Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: rip out drm_platform_exitDaniel Vetter
This very much looks like a remnant of the old legady ums shadow attach days. Now with the last users gone we can rip it out since we won't ever support an ums drm driver again. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-10-09drm: introduce drm_dev_free() to fix error pathsDavid Herrmann
The error paths in DRM bus drivers currently leak memory as they don't correctly revert drm_dev_alloc(). Introduce drm_dev_free() to free DRM devices which haven't been registered, yet. We must be careful not to introduce any side-effects with cleanups done in drm_dev_free(). drm_ht_remove(), drm_ctxbitmap_cleanup() and drm_gem_destroy() are all fine in that regard. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-10-09drm: merge device setup into drm_dev_register()David Herrmann
All bus drivers do device setup themselves. This requires us to adjust all of them if we introduce new core features. Thus, merge all these into a uniform drm_dev_register() helper. Note that this removes the drm_lastclose() error path for AGP as it is horribly broken. Moreover, no bus driver called this in any other error path either. Instead, we use the recently introduced AGP cleanup helpers. We also keep a DRIVER_MODESET condition around pci_set_drvdata() to keep semantics. [airlied: keep passing flags through so drivers don't oops on load] Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-10-09drm: add drm_dev_alloc() helperDavid Herrmann
Instead of managing device allocation+initialization in each bus-driver, we should do that in a central place. drm_fill_in_dev() already does most of it, but also requires the global drm lock for partial AGP device registration. Split both apart so we have a clean device initialization/allocation phase, and a registration phase. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-30drm: implement experimental render nodesDavid 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: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-21drm: Make drm_get_platform_dev() staticLespiau, Damien
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 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: 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 Howells
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 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: 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 Gortmaker
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 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: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-07drm: rework PCI/platform driver interface.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: Dave Airlie <airlied@redhat.com>
2010-09-14drm: fix race between driver loading and userspace open.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: Dave Airlie <airlied@redhat.com>
2010-06-01drm: Add support for platform devices to register as DRM devicesJordan Crouse
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>