kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/Documentation/DocBook/drm.tmpl

3945 lines
162 KiB
Raw Normal View History

drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update copyright I've done quite a bit of cleanups, clarifications and mostly integrating kerneldoc. So I guess I should add myself. Also split up the copyright notices per holder to make it clear which year ranges are covered. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 22:38:57 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Update copyright I've done quite a bit of cleanups, clarifications and mostly integrating kerneldoc. So I guess I should add myself. Also split up the copyright notices per holder to make it clear which year ranges are covered. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 22:38:57 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update copyright I've done quite a bit of cleanups, clarifications and mostly integrating kerneldoc. So I guess I should add myself. Also split up the copyright notices per holder to make it clear which year ranges are covered. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 22:38:57 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-15 13:54:06 -07:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: can -> may Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 17:21:31 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: Eradicate inappropriate uses of the future tense Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 17:18:08 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: Eradicate inappropriate uses of the future tense Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 17:18:08 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm: Document how to register devices without struct drm_bus With the recent addition of the drm_set_unique() function, devices can now be registered without requiring a drm_bus. Add a brief description to the DRM docbook to show how that can be achieved. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-23 11:52:10 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: Improve manual IRQ installation documentation Define the rules for using irqs from drm drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 14:10:59 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: implement experimental render nodes 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-25 18:29:00 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: Add device registration documentation 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-05-19 13:39:07 +02:00
drm: Document how to register devices without struct drm_bus With the recent addition of the drm_set_unique() function, devices can now be registered without requiring a drm_bus. Add a brief description to the DRM docbook to show how that can be achieved. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-04-23 11:52:10 +02:00
drm: Add device registration documentation 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-05-19 13:39:07 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: No more drm perf counters Those all died with commit 0111be42186fc5461b9e9d579014c70869ab3152 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Oct 4 14:53:41 2013 +0300 drm: Kill drm perf counter leftovers Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 16:32:47 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: No more drm perf counters Those all died with commit 0111be42186fc5461b9e9d579014c70869ab3152 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Oct 4 14:53:41 2013 +0300 drm: Kill drm perf counter leftovers Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 16:32:47 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: Improve manual IRQ installation documentation Define the rules for using irqs from drm drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 14:10:59 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: Improve manual IRQ installation documentation Define the rules for using irqs from drm drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 14:10:59 +02:00
drm: pass the irq explicitly to drm_irq_install Unfortunately this requires a drm-wide change, and I didn't see a sane way around that. Luckily it's fairly simple, we just need to inline the respective get_irq implementation from either drm_pci.c or drm_platform.c. With that we can now also remove drm_dev_to_irq from drm_irq.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>
2013-11-03 21:09:27 +01:00
drm: Improve manual IRQ installation documentation Define the rules for using irqs from drm drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 14:10:59 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
doc: fix misspellings with 'codespell' tool Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-08 16:56:16 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-15 13:54:06 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: `(device|driver) specific' -> `(device|driver)-specific' Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-29 18:05:52 +00:00
DocBook/drm: Eradicate inappropriate uses of the future tense Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 17:18:08 +00:00
DocBook/drm: Insert missing comma Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 19:02:52 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: Insert `()' after function name Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 19:19:18 +00:00
DocBook/drm: Remove parentheses and unnecessary repetition Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 19:14:26 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: `(device|driver) specific' -> `(device|driver)-specific' Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-29 18:05:52 +00:00
DocBook/drm: Insert `()' after function name Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 19:19:18 +00:00
drm: fix typos in Linux DRM Developer's Guide A few typos in the DRM Developer's Guide. Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Acked-by: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-05-28 07:33:49 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
DocBook/drm: Clarify `final initialization' via better formatting Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 20:18:14 +00:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
DocBook/drm: Clarify `final initialization' via better formatting Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 20:18:14 +00:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Clarify PRIME documentation PRIME fds aren't actually GEM fds but are (like the modeset API) independent of the underlying buffer manager, as long as that one uses uint32_t as handles. So move that entire section out of the GEM section and reword it a bit to clarify which parts of PRIME are generic, and which are the mandatory pieces for GEM drivers to correctly implement the GEM lifetime rules. The rewording mostly consists of not mixing up GEM, PRIME and DRM. I've considered adding some blurbs to the GEM object lifetime section about interactions with dma-bufs, but then dropped that. As long as drivers use the right helpers they should have this all implemented correctly and hence can be regarded as an implementation detail of the PRIME/GEM helpers. So no need to confuse driver writers with those tricky interactions. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 18:46:33 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Clarify PRIME documentation PRIME fds aren't actually GEM fds but are (like the modeset API) independent of the underlying buffer manager, as long as that one uses uint32_t as handles. So move that entire section out of the GEM section and reword it a bit to clarify which parts of PRIME are generic, and which are the mandatory pieces for GEM drivers to correctly implement the GEM lifetime rules. The rewording mostly consists of not mixing up GEM, PRIME and DRM. I've considered adding some blurbs to the GEM object lifetime section about interactions with dma-bufs, but then dropped that. As long as drivers use the right helpers they should have this all implemented correctly and hence can be regarded as an implementation detail of the PRIME/GEM helpers. So no need to confuse driver writers with those tricky interactions. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 18:46:33 +01:00
drm/doc: Clean up and integrate kerneldoc for drm_gem.c Fairly incomplete, but at least a start. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:39:00 +01:00
drm/doc: Clarify PRIME documentation PRIME fds aren't actually GEM fds but are (like the modeset API) independent of the underlying buffer manager, as long as that one uses uint32_t as handles. So move that entire section out of the GEM section and reword it a bit to clarify which parts of PRIME are generic, and which are the mandatory pieces for GEM drivers to correctly implement the GEM lifetime rules. The rewording mostly consists of not mixing up GEM, PRIME and DRM. I've considered adding some blurbs to the GEM object lifetime section about interactions with dma-bufs, but then dropped that. As long as drivers use the right helpers they should have this all implemented correctly and hence can be regarded as an implementation detail of the PRIME/GEM helpers. So no need to confuse driver writers with those tricky interactions. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 18:46:33 +01:00
drm/doc: Clean up and integrate kerneldoc for drm_gem.c Fairly incomplete, but at least a start. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:39:00 +01:00
drm/doc: Move the vma offset manager to the right spot Currently it's sitting in the mode setting helper section, which isn't quite right. Looks much better in the memory management section next to TTM and GEM. Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:28:42 +01:00
drm/doc: Clarify PRIME documentation PRIME fds aren't actually GEM fds but are (like the modeset API) independent of the underlying buffer manager, as long as that one uses uint32_t as handles. So move that entire section out of the GEM section and reword it a bit to clarify which parts of PRIME are generic, and which are the mandatory pieces for GEM drivers to correctly implement the GEM lifetime rules. The rewording mostly consists of not mixing up GEM, PRIME and DRM. I've considered adding some blurbs to the GEM object lifetime section about interactions with dma-bufs, but then dropped that. As long as drivers use the right helpers they should have this all implemented correctly and hence can be regarded as an implementation detail of the PRIME/GEM helpers. So no need to confuse driver writers with those tricky interactions. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 18:46:33 +01:00
Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-15 13:54:06 -07:00
drm/doc: Clarify PRIME documentation PRIME fds aren't actually GEM fds but are (like the modeset API) independent of the underlying buffer manager, as long as that one uses uint32_t as handles. So move that entire section out of the GEM section and reword it a bit to clarify which parts of PRIME are generic, and which are the mandatory pieces for GEM drivers to correctly implement the GEM lifetime rules. The rewording mostly consists of not mixing up GEM, PRIME and DRM. I've considered adding some blurbs to the GEM object lifetime section about interactions with dma-bufs, but then dropped that. As long as drivers use the right helpers they should have this all implemented correctly and hence can be regarded as an implementation detail of the PRIME/GEM helpers. So no need to confuse driver writers with those tricky interactions. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 18:46:33 +01:00
drm/doc: Add PRIME function references For giant hilarity the DocBook reference overview is only generated when in a level 2 section, not in a level 3 section. So we need to move this up a bit as a side-by-side section to the main PRIME documentation. Whatever. To have a complete set of references add the missing kerneldoc for all functions exported to modules with the exception of the file private init/destroy functions - drivers have no business calling those, so let's just drop the EXPORT_SYMBOL instead. Also reflow the function parameters to align correctly and break at 80 chars - my OCD couldn't stand them while writing the kerneldoc ;-) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 19:16:30 +01:00
drm/doc: Clarify PRIME documentation PRIME fds aren't actually GEM fds but are (like the modeset API) independent of the underlying buffer manager, as long as that one uses uint32_t as handles. So move that entire section out of the GEM section and reword it a bit to clarify which parts of PRIME are generic, and which are the mandatory pieces for GEM drivers to correctly implement the GEM lifetime rules. The rewording mostly consists of not mixing up GEM, PRIME and DRM. I've considered adding some blurbs to the GEM object lifetime section about interactions with dma-bufs, but then dropped that. As long as drivers use the right helpers they should have this all implemented correctly and hence can be regarded as an implementation detail of the PRIME/GEM helpers. So no need to confuse driver writers with those tricky interactions. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 18:46:33 +01:00
drm/doc: Add PRIME function references For giant hilarity the DocBook reference overview is only generated when in a level 2 section, not in a level 3 section. So we need to move this up a bit as a side-by-side section to the main PRIME documentation. Whatever. To have a complete set of references add the missing kerneldoc for all functions exported to modules with the exception of the file private init/destroy functions - drivers have no business calling those, so let's just drop the EXPORT_SYMBOL instead. Also reflow the function parameters to align correctly and break at 80 chars - my OCD couldn't stand them while writing the kerneldoc ;-) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 19:16:30 +01:00
drm/doc: Overview documentation for drm_mm.c kerneldoc polish will follow in the next patch. Hopefully documenting the lru scan support a bit better spurs someone to give this a shot in the ttm eviction code. At least in i915 it helped quite a lot with memory thrashing on platforms where eviction was (we've fixed that too meanwhile) fairly expensive. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-23 00:31:48 +01:00
drm/doc: Add function reference documentation for drm_mm.c While at it do a tiny bit of interface cleanup and convert boolean return values to bool. With this patch all exported functions and inline helpers which are part of the drm_mm public interface are documented. Also drop superflous extern function modifiers since most of drm_mm.h doesn't use them - more consistent that way. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-23 00:39:13 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Integrate drm_modes.c kerneldoc And clean it up so that there's no kerneldoc warnings. There's still a lot to do with this one here. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-23 15:06:15 +01:00
drm: polish function kerneldoc for drm_modes.[hc] - Tune down yelling RETURNS. - OCD align all the parameters the same. - Add missing kerneldoc, which also means that we need to include the kerneldoc from the drm_modes.h header now. - Add missing Returns: sections. - General polish and clarification - especially the kerneldoc for the mode creation helpers seems to have been some good specimen of copypasta gone wrong. All actual code changes have all been extracted into prep patches since there was simply too much to polish. v2: More polish for the command line modeline functions. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-23 20:05:00 +01:00
drm/doc: Integrate drm_modes.c kerneldoc And clean it up so that there's no kerneldoc warnings. There's still a lot to do with this one here. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-23 15:06:15 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Clarify the dumb object interfaces - This is _not_ a generic interface to create gem objects, but just an interface to make early boot services (like boot splash) with a generic KMS userspace driver possible. Hence it's better to move the documentation for this from the GEM section to the KMS section, next to the creation of framebuffer objects. - Make it really clear that the returned handle isn't necessarily a GEM object (it can also be e.g. a TTM handle when running on top of vmwgfx). - Add a paragraph to make it clear that this is just for unaccelarated userspace - gpu drivers need to have their own buffer object creation ioctl which is hardware specific. v2: Clarify that the documentation doesn't just apply to GEM-based drivers only but is now generally valid, as suggested by David. v3: Polish the intro sentence a bit and one s/objects/handles/ for clarification, both suggested by Laurent. v4: More text polish from Laurent's review. v5: More typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:01:41 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: updates for new framebuffer lifetime rules Now that framebuffer are reference-counted for all use-sites, update the documentation accordingly to stress the new rules for initialization and teardown. Also add a short paragraph about the implications for drivers of the new locking rules. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-04 22:31:20 +01:00
drm/doc: Clarify the dumb object interfaces - This is _not_ a generic interface to create gem objects, but just an interface to make early boot services (like boot splash) with a generic KMS userspace driver possible. Hence it's better to move the documentation for this from the GEM section to the KMS section, next to the creation of framebuffer objects. - Make it really clear that the returned handle isn't necessarily a GEM object (it can also be e.g. a TTM handle when running on top of vmwgfx). - Add a paragraph to make it clear that this is just for unaccelarated userspace - gpu drivers need to have their own buffer object creation ioctl which is hardware specific. v2: Clarify that the documentation doesn't just apply to GEM-based drivers only but is now generally valid, as suggested by David. v3: Polish the intro sentence a bit and one s/objects/handles/ for clarification, both suggested by Laurent. v4: More text polish from Laurent's review. v5: More typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:01:41 +01:00
drm/doc: updates for new framebuffer lifetime rules Now that framebuffer are reference-counted for all use-sites, update the documentation accordingly to stress the new rules for initialization and teardown. Also add a short paragraph about the implications for drivers of the new locking rules. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-04 22:31:20 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: updates for new framebuffer lifetime rules Now that framebuffer are reference-counted for all use-sites, update the documentation accordingly to stress the new rules for initialization and teardown. Also add a short paragraph about the implications for drivers of the new locking rules. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-04 22:31:20 +01:00
drm/doc: Fix misplaced </para> Oops. This is a regression from commit 5d7a951537927555fa1286a338e1b91c3b8b7445 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jan 4 22:31:20 2013 +0100 drm/doc: updates for new framebuffer lifetime rules Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-23 21:57:37 +01:00
drm/doc: updates for new framebuffer lifetime rules Now that framebuffer are reference-counted for all use-sites, update the documentation accordingly to stress the new rules for initialization and teardown. Also add a short paragraph about the implications for drivers of the new locking rules. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-04 22:31:20 +01:00
drm/doc: Fix misplaced </para> Oops. This is a regression from commit 5d7a951537927555fa1286a338e1b91c3b8b7445 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jan 4 22:31:20 2013 +0100 drm/doc: updates for new framebuffer lifetime rules Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-23 21:57:37 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Clarify the dumb object interfaces - This is _not_ a generic interface to create gem objects, but just an interface to make early boot services (like boot splash) with a generic KMS userspace driver possible. Hence it's better to move the documentation for this from the GEM section to the KMS section, next to the creation of framebuffer objects. - Make it really clear that the returned handle isn't necessarily a GEM object (it can also be e.g. a TTM handle when running on top of vmwgfx). - Add a paragraph to make it clear that this is just for unaccelarated userspace - gpu drivers need to have their own buffer object creation ioctl which is hardware specific. v2: Clarify that the documentation doesn't just apply to GEM-based drivers only but is now generally valid, as suggested by David. v3: Polish the intro sentence a bit and one s/objects/handles/ for clarification, both suggested by Laurent. v4: More text polish from Laurent's review. v5: More typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:01:41 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: updates for new framebuffer lifetime rules Now that framebuffer are reference-counted for all use-sites, update the documentation accordingly to stress the new rules for initialization and teardown. Also add a short paragraph about the implications for drivers of the new locking rules. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-04 22:31:20 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Document drm_helper_resume_force_mode Stumbled over while reviewing all occurences in the DRM doc talking about suspend/resume. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 16:42:02 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
doc: fix misspellings with 'codespell' tool Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-08 16:56:16 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: Add consistency check for page-flipping Driver implementations of the drm_crtc's .page_flip() function are required to update the crtc->fb field on success to reflect that the new framebuffer is now in use. This is important to keep reference counting on the framebuffers balanced. While at it, document this requirement to keep others from falling into the same trap. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-13 16:08:33 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add drm_send_vblank_event() helper (v5) A helper that drivers can use to send vblank event after a pageflip. If the driver doesn't support proper vblank irq based time/seqn then just pass -1 for the pipe # to get do_gettimestamp() behavior (since there are a lot of drivers that don't use drm_vblank_count_and_time()) Also an internal send_vblank_event() helper for the various other code paths within drm_irq that also need to send vblank events. v1: original v2: add back 'vblwait->reply.sequence = seq' which should not have been deleted v3: add WARN_ON() in case lock is not held and comments v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK as pointed out by Marcin Slusarz v5: update docbook Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-10-16 22:48:40 +00:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add drm_send_vblank_event() helper (v5) A helper that drivers can use to send vblank event after a pageflip. If the driver doesn't support proper vblank irq based time/seqn then just pass -1 for the pipe # to get do_gettimestamp() behavior (since there are a lot of drivers that don't use drm_vblank_count_and_time()) Also an internal send_vblank_event() helper for the various other code paths within drm_irq that also need to send vblank events. v1: original v2: add back 'vblwait->reply.sequence = seq' which should not have been deleted v3: add WARN_ON() in case lock is not held and comments v4: use WARN_ON_SMP() instead to fix issue with !SMP && !DEBUG_SPINLOCK as pointed out by Marcin Slusarz v5: update docbook Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-10-16 22:48:40 +00:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Document the KMS property API Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 16:10:30 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Document the KMS property API Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 16:10:30 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add register and unregister functions for connectors Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-29 16:57:41 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Document the KMS property API Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 16:10:30 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add register and unregister functions for connectors Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-29 16:57:41 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm: add register and unregister functions for connectors Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-29 16:57:41 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: integrate drm_crtc.c kerneldoc And do a quick pass to adjust them to the last few (years?) of changes ... This time actually compile-tested ;-) Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-02 00:09:18 +01:00
drm: convert crtc and connection_mutex to ww_mutex (v5) For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-11-19 12:10:12 -05:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Helpers are not a Midlayer! I'm devoting all my wrath to that fight, so don't misname it ;-) v2: Make it clear that this section talks about kms helpers. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-01 14:45:15 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Helpers are not a Midlayer! I'm devoting all my wrath to that fight, so don't misname it ;-) v2: Make it clear that this section talks about kms helpers. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-01 14:45:15 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: make mode_valid callback optional Many drm connectors do not need mode validation. The patch makes this callback optional and removes dumb implementations. v2: Rebase: - imx move to a shared (but still dummy) ->mode_valid implementation. - probe helpers have been extracted to drm_probe_helper.c Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-02 12:29:46 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Clarify the dumb object interfaces - This is _not_ a generic interface to create gem objects, but just an interface to make early boot services (like boot splash) with a generic KMS userspace driver possible. Hence it's better to move the documentation for this from the GEM section to the KMS section, next to the creation of framebuffer objects. - Make it really clear that the returned handle isn't necessarily a GEM object (it can also be e.g. a TTM handle when running on top of vmwgfx). - Add a paragraph to make it clear that this is just for unaccelarated userspace - gpu drivers need to have their own buffer object creation ioctl which is hardware specific. v2: Clarify that the documentation doesn't just apply to GEM-based drivers only but is now generally valid, as suggested by David. v3: Polish the intro sentence a bit and one s/objects/handles/ for clarification, both suggested by Laurent. v4: More text polish from Laurent's review. v5: More typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:01:41 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: make mode_valid callback optional Many drm connectors do not need mode validation. The patch makes this callback optional and removes dumb implementations. v2: Rebase: - imx move to a shared (but still dummy) ->mode_valid implementation. - probe helpers have been extracted to drm_probe_helper.c Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-02 12:29:46 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: integrate crtc helper api into docbook - Add the missing doc for drm_helper_move_panel_connectors_to_head. - Fixup any outdated stuff in existing sections. I've only looked at those kerneldoc headers that actually resulted in a complaint from the kerneldoc parser tool. v2: - Actually include the docbook snippet in the right patch. - Fix spelling fail. v3: It's now called drm_crtc_helper_set_mode, spotted by Laurent Pinchart. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-01 14:45:16 +01:00
drm: Split out drm_probe_helper.c from drm_crtc_helper.c This is leftover stuff from my previous doc round which I kinda wanted to do but didn't yet due to rebase hell. The modeset helpers and the probing helpers a independent and e.g. i915 uses the probing stuff but has its own modeset infrastructure. It hence makes to split this up. While at it add a DOC: comment for the probing libraray. It would be rather neat to pull some of the DocBook documenting these two helpers into in-line DOC: comments. But unfortunately kerneldoc doesn't support markdown or something similar to make nice-looking documentation, so the current state is better. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-04-10 10:51:11 +02:00
drm/doc: integrate crtc helper api into docbook - Add the missing doc for drm_helper_move_panel_connectors_to_head. - Fixup any outdated stuff in existing sections. I've only looked at those kerneldoc headers that actually resulted in a complaint from the kerneldoc parser tool. v2: - Actually include the docbook snippet in the right patch. - Fix spelling fail. v3: It's now called drm_crtc_helper_set_mode, spotted by Laurent Pinchart. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-01 14:45:16 +01:00
drm/doc: integrate fb helper reference into docs Again only minimal changes to make kerneldoc no longer shout. Plus a little introduction in the form of a inline DOC: section to quickly explain what this is all about. v2: Fixup spelling fail. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-01 14:45:17 +01:00
drm/fb-helper: improve kerneldoc Now that the fbdev helper interface for drivers is trimmed down, update the kerneldoc for all the remaining exported functions. I've tried to beat the DocBook a bit by reordering the function references a bit into a more sensible ordering. But that didn't work out at all. Hence just extend the in-code DOC: section a bit. Also remove the LOCKING: sections - especially for the setup functions they're totally bogus. But that's not a documentation problem, but simply an artifact of the current rather hazardous locking around drm init and even more so around fbdev setup ... v2: Some further improvements: - Also add documentation for drm_fb_helper_single_add_all_connectors, Dave Airlie didn't want me to kill this one from the fb helper interface. - Update docs for drm_fb_helper_fill_var/fix - they should be used from the driver's ->fb_probe callback to setup the fbdev info structure. - Clarify what the ->fb_probe callback should all do - it needs to setup both the fbdev info and allocate the drm framebuffer used as backing storage. - Add basic documentaation for the drm_fb_helper_funcs driver callback vfunc. v3: Implement clarifications Laurent Pinchart suggested in his review. v4: Fix another mispelling Laurent spotted. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-20 22:13:14 +01:00
drm/doc: integrate fb helper reference into docs Again only minimal changes to make kerneldoc no longer shout. Plus a little introduction in the form of a inline DOC: section to quickly explain what this is all about. v2: Fixup spelling fail. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-01 14:45:17 +01:00
drm/doc: add new dp helpers into drm DocBook I didn't bother with documenting the really trivial new "extract something from dpcd" helpers, but the i2c over aux ch is now documented a bit. v2: Clarify the comment for i2c_dp_aux_add_bus a bit. v3: Fix more spelling fail spotted by Laurent Pinchart. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-01 14:45:18 +01:00
drm: Add EDID helper documentation Add a reference section about the EDID helper functions to the DRM documentation. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-14 09:00:31 +01:00
drm: Fix drm_rect documentation The 'struct' keyword was missing so struct drm_rect documentation never ended up in the generated docs. Also move the drm_rect documentations to a new section alognside the various helper functions and add a short description about the intended purpose of drm_rect. v2: Move to new section and add general description Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-08 17:16:45 +03:00
drm: add flip-work helper A small helper to queue up work to do, from workqueue context, after a flip. Typically useful to defer unreffing buffers that may be read by the display controller until vblank. v1: original v2: wire up docbook + couple docbook fixes Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07 14:41:54 -04:00
drm: Fix drm_rect documentation The 'struct' keyword was missing so struct drm_rect documentation never ended up in the generated docs. Also move the drm_rect documentations to a new section alognside the various helper functions and add a short description about the intended purpose of drm_rect. v2: Move to new section and add general description Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-08 17:16:45 +03:00
drm/docs: Include hdmi infoframe helper reference Thierry created such nice kerneldocs, it's a shame we've left them lingering! For the fun of it also add a bit of kerneldoc to the header so that we can also include that. Just in case someone adds kerneldoc in there. Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 18:26:16 +01:00
drm/doc: Update plane documentation and add plane helper library Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-04-01 15:22:43 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Document the KMS property API Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 16:10:30 +02:00
Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-15 13:54:06 -07:00
drm/doc: Document the KMS property API Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-22 16:10:30 +02:00
Documentation: drm: describing drm properties exposed by various drivers Started documenting drm properties for drm drivers. This patch provides information about properties in drm, i915, psb and cdv/gma-500. Information about other properties can be added on top of these. v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau, omap, qxl, radeon, rcar-du v3: Removed "Property Object" column since it is implementation related. Property type column refined.[Ville's review comments] v4: Removed whitespace warnings and minor nits. [Randy's review comments] v5: Restructured output for ENUM properties v6: Review comments on formatting the table. [Laurent's review comments] v7: Minor restructuring. [Laurent's review comments] Cc: Rob Landley <rob@landley.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-03-11 19:55:29 +05:30
drm/doc: Add the "type" plane property to the list of properties Matt aded this plane property before we had a table giving a summary of the properties. Add it there. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-06-09 14:20:22 +01:00
Documentation: drm: describing drm properties exposed by various drivers Started documenting drm properties for drm drivers. This patch provides information about properties in drm, i915, psb and cdv/gma-500. Information about other properties can be added on top of these. v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau, omap, qxl, radeon, rcar-du v3: Removed "Property Object" column since it is implementation related. Property type column refined.[Ville's review comments] v4: Removed whitespace warnings and minor nits. [Randy's review comments] v5: Restructured output for ENUM properties v6: Review comments on formatting the table. [Laurent's review comments] v7: Minor restructuring. [Laurent's review comments] Cc: Rob Landley <rob@landley.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-03-11 19:55:29 +05:30
drm/doc: Add the "type" plane property to the list of properties Matt aded this plane property before we had a table giving a summary of the properties. Add it there. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-06-09 14:20:22 +01:00
Documentation: drm: describing drm properties exposed by various drivers Started documenting drm properties for drm drivers. This patch provides information about properties in drm, i915, psb and cdv/gma-500. Information about other properties can be added on top of these. v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau, omap, qxl, radeon, rcar-du v3: Removed "Property Object" column since it is implementation related. Property type column refined.[Ville's review comments] v4: Removed whitespace warnings and minor nits. [Randy's review comments] v5: Restructured output for ENUM properties v6: Review comments on formatting the table. [Laurent's review comments] v7: Minor restructuring. [Laurent's review comments] Cc: Rob Landley <rob@landley.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-03-11 19:55:29 +05:30
drm/doc: Fix nouveau typo 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>
2014-06-09 14:40:35 +01:00
Documentation: drm: describing drm properties exposed by various drivers Started documenting drm properties for drm drivers. This patch provides information about properties in drm, i915, psb and cdv/gma-500. Information about other properties can be added on top of these. v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau, omap, qxl, radeon, rcar-du v3: Removed "Property Object" column since it is implementation related. Property type column refined.[Ville's review comments] v4: Removed whitespace warnings and minor nits. [Randy's review comments] v5: Restructured output for ENUM properties v6: Review comments on formatting the table. [Laurent's review comments] v7: Minor restructuring. [Laurent's review comments] Cc: Rob Landley <rob@landley.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-03-11 19:55:29 +05:30
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/irq: kerneldoc polish - Integrate into the drm DocBook - Disable kerneldoc for functions not exported to drivers. - Properly document the new drm_vblank_on|off and add cautious comments explaining when drm_vblank_pre|post_modesets shouldn't be used. - General polish and OCD. v2: Polish as suggested by Thierry. Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-08 16:41:51 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: don't call ->firstopen for KMS drivers It has way too much potential for driver writers to do stupid things like delayed hw setup because the load sequence is somehow racy (e.g. the imx driver in staging). So don't call it for modesetting drivers, which reduces the complexity of the drm core -> driver interface a notch. v2: Don't forget to update DocBook. v3: Go with Laurent's slightly more elaborate proposal for the DocBook update. Add a few words on top of his diff to elaborate a bit on what KMS drivers should and shouldn't do in lastclose. There was already a paragraph present talking about restoring properties, I've simply extended that one. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-08 15:41:15 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: don't call ->firstopen for KMS drivers It has way too much potential for driver writers to do stupid things like delayed hw setup because the load sequence is somehow racy (e.g. the imx driver in staging). So don't call it for modesetting drivers, which reduces the complexity of the drm core -> driver interface a notch. v2: Don't forget to update DocBook. v3: Go with Laurent's slightly more elaborate proposal for the DocBook update. Add a few words on top of his diff to elaborate a bit on what KMS drivers should and shouldn't do in lastclose. There was already a paragraph present talking about restoring properties, I've simply extended that one. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-08 15:41:15 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: don't call ->firstopen for KMS drivers It has way too much potential for driver writers to do stupid things like delayed hw setup because the load sequence is somehow racy (e.g. the imx driver in staging). So don't call it for modesetting drivers, which reduces the complexity of the drm core -> driver interface a notch. v2: Don't forget to update DocBook. v3: Go with Laurent's slightly more elaborate proposal for the DocBook update. Add a few words on top of his diff to elaborate a bit on what KMS drivers should and shouldn't do in lastclose. There was already a paragraph present talking about restoring properties, I've simply extended that one. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-08 15:41:15 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
DocBook/drm: Use an itemizedlist for what an encoder needs to provide Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 20:55:58 +00:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
DocBook/drm: Use an itemizedlist for what an encoder needs to provide Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-25 20:55:58 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Hide legacy horrors better By consolidating them all into one section at the very end. And to make double-sure that no one gets confused start with a stern warning against any use of them. And prefix all subsections with "Legacy". Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 16:46:44 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-15 13:54:06 -07:00
drm/doc: Hide legacy horrors better By consolidating them all into one section at the very end. And to make double-sure that no one gets confused start with a stern warning against any use of them. And prefix all subsections with "Legacy". Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 16:46:44 +01:00
Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-15 13:54:06 -07:00
drm/doc: Hide legacy horrors better By consolidating them all into one section at the very end. And to make double-sure that no one gets confused start with a stern warning against any use of them. And prefix all subsections with "Legacy". Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 16:46:44 +01:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Hide legacy horrors better By consolidating them all into one section at the very end. And to make double-sure that no one gets confused start with a stern warning against any use of them. And prefix all subsections with "Legacy". Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 16:46:44 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: `(device|driver) specific' -> `(device|driver)-specific' Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-29 18:05:52 +00:00
DocBook/drm: `device aware' -> `device-aware' Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-29 18:07:13 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
DocBook/drm: Clean up a todo-note Signed-off-by: Michael Witten <mfwitten@gmail.com>
2011-08-29 19:29:16 +00:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: implement experimental render nodes 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-25 18:29:00 +02:00
drm/doc: Remove <term> from rendernode docs The stylesheet doesn't allow this in normal paragraphs. Cc: David Herrmann <dh.herrmann@gmail.com> Acked-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:51:43 +01:00
drm: implement experimental render nodes 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-25 18:29:00 +02:00
drm/doc: Remove <term> from rendernode docs The stylesheet doesn't allow this in normal paragraphs. Cc: David Herrmann <dh.herrmann@gmail.com> Acked-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:51:43 +01:00
drm: implement experimental render nodes 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-25 18:29:00 +02:00
drm/doc: Remove <term> from rendernode docs The stylesheet doesn't allow this in normal paragraphs. Cc: David Herrmann <dh.herrmann@gmail.com> Acked-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:51:43 +01:00
drm: implement experimental render nodes 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-25 18:29:00 +02:00
drm/doc: Remove <term> from rendernode docs The stylesheet doesn't allow this in normal paragraphs. Cc: David Herrmann <dh.herrmann@gmail.com> Acked-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:51:43 +01:00
drm: implement experimental render nodes 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-25 18:29:00 +02:00
drm/doc: Remove <term> from rendernode docs The stylesheet doesn't allow this in normal paragraphs. Cc: David Herrmann <dh.herrmann@gmail.com> Acked-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-21 12:51:43 +01:00
drm: implement experimental render nodes 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-25 18:29:00 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm/doc: Discourage usage of MODESET_CTL ioctl Leftover from the old days of ums and should be used any longer. Since commit 29935554b384b1b3a7377d6f0b03b21d18a61683 Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Date: Wed May 30 00:58:09 2012 +0200 drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers it is a complete no-Op for kms drivers. v2: Fix up mangled sentence spotted by Michel. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Michel Dänzer <michel@daenzer.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-08 15:39:19 +02:00
Documentation: DocBook DRM framework documentation Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <rob.clark@linaro.org>
2012-07-13 00:57:26 +02:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm/i915: Add a brief description of the VLV display PHY internals Document the internal structure of the VLV display PHY a bit to help people understand how the different register blocks relate to each other. v2: Add a bit more text Make it a DOC: comment, but leave the ascii art out since it would get mangled Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-25 20:14:31 +03:00
drm/i915: Provide DPIO diagrams as docboox tables The ascii art version of the DPIO diagram gets mangled by docbook, so we can't use it there. Insted provide another version built using <table>. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-25 20:14:32 +03:00
drm/i915: Add a brief description of the VLV display PHY internals Document the internal structure of the VLV display PHY a bit to help people understand how the different register blocks relate to each other. v2: Add a bit more text Make it a DOC: comment, but leave the ascii art out since it would get mangled Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-25 20:14:31 +03:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm/i915: Integrate cmd parser kerneldoc Ville noticed that we have this nice kerneldoc but it's not integrated anywhere. Fix this asap! Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-25 16:59:00 +02:00
drm/doc: Reorganize driver documentation Split up the DocBook into the core drm part and a 2nd part for driver documentation. As an example add a very (very!) basic skeleton for i915. v1: Typo fixes from Dieter. Cc: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22 12:21:16 +01:00
drm: add initial DRM developer documentation Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-26 13:06:31 -07:00