diff options
author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2014-01-21 06:01:41 -0500 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2014-03-13 07:48:25 -0400 |
commit | 065a5027dca8e9383ac308de4310e8e850b0cafb (patch) | |
tree | 3ae6b43cacc705f53e32e402b6441c80835537dd /Documentation/DocBook | |
parent | 786a7828bc74b9b1466e83abb200b75f80f94121 (diff) |
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>
Diffstat (limited to 'Documentation/DocBook')
-rw-r--r-- | Documentation/DocBook/drm.tmpl | 133 |
1 files changed, 72 insertions, 61 deletions
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ed1d6d289022..f2d0f5b89194 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl | |||
@@ -830,62 +830,6 @@ char *date;</synopsis> | |||
830 | </para> | 830 | </para> |
831 | </sect3> | 831 | </sect3> |
832 | <sect3> | 832 | <sect3> |
833 | <title>Dumb GEM Objects</title> | ||
834 | <para> | ||
835 | The GEM API doesn't standardize GEM objects creation and leaves it to | ||
836 | driver-specific ioctls. While not an issue for full-fledged graphics | ||
837 | stacks that include device-specific userspace components (in libdrm for | ||
838 | instance), this limit makes DRM-based early boot graphics unnecessarily | ||
839 | complex. | ||
840 | </para> | ||
841 | <para> | ||
842 | Dumb GEM objects partly alleviate the problem by providing a standard | ||
843 | API to create dumb buffers suitable for scanout, which can then be used | ||
844 | to create KMS frame buffers. | ||
845 | </para> | ||
846 | <para> | ||
847 | To support dumb GEM objects drivers must implement the | ||
848 | <methodname>dumb_create</methodname>, | ||
849 | <methodname>dumb_destroy</methodname> and | ||
850 | <methodname>dumb_map_offset</methodname> operations. | ||
851 | </para> | ||
852 | <itemizedlist> | ||
853 | <listitem> | ||
854 | <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, | ||
855 | struct drm_mode_create_dumb *args);</synopsis> | ||
856 | <para> | ||
857 | The <methodname>dumb_create</methodname> operation creates a GEM | ||
858 | object suitable for scanout based on the width, height and depth | ||
859 | from the struct <structname>drm_mode_create_dumb</structname> | ||
860 | argument. It fills the argument's <structfield>handle</structfield>, | ||
861 | <structfield>pitch</structfield> and <structfield>size</structfield> | ||
862 | fields with a handle for the newly created GEM object and its line | ||
863 | pitch and size in bytes. | ||
864 | </para> | ||
865 | </listitem> | ||
866 | <listitem> | ||
867 | <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, | ||
868 | uint32_t handle);</synopsis> | ||
869 | <para> | ||
870 | The <methodname>dumb_destroy</methodname> operation destroys a dumb | ||
871 | GEM object created by <methodname>dumb_create</methodname>. | ||
872 | </para> | ||
873 | </listitem> | ||
874 | <listitem> | ||
875 | <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, | ||
876 | uint32_t handle, uint64_t *offset);</synopsis> | ||
877 | <para> | ||
878 | The <methodname>dumb_map_offset</methodname> operation associates an | ||
879 | mmap fake offset with the GEM object given by the handle and returns | ||
880 | it. Drivers must use the | ||
881 | <function>drm_gem_create_mmap_offset</function> function to | ||
882 | associate the fake offset as described in | ||
883 | <xref linkend="drm-gem-objects-mapping"/>. | ||
884 | </para> | ||
885 | </listitem> | ||
886 | </itemizedlist> | ||
887 | </sect3> | ||
888 | <sect3> | ||
889 | <title>Memory Coherency</title> | 833 | <title>Memory Coherency</title> |
890 | <para> | 834 | <para> |
891 | When mapped to the device or used in a command buffer, backing pages | 835 | When mapped to the device or used in a command buffer, backing pages |
@@ -968,9 +912,11 @@ int max_width, max_height;</synopsis> | |||
968 | Frame buffers rely on the underneath memory manager for low-level memory | 912 | Frame buffers rely on the underneath memory manager for low-level memory |
969 | operations. When creating a frame buffer applications pass a memory | 913 | operations. When creating a frame buffer applications pass a memory |
970 | handle (or a list of memory handles for multi-planar formats) through | 914 | handle (or a list of memory handles for multi-planar formats) through |
971 | the <parameter>drm_mode_fb_cmd2</parameter> argument. This document | 915 | the <parameter>drm_mode_fb_cmd2</parameter> argument. For drivers using |
972 | assumes that the driver uses GEM, those handles thus reference GEM | 916 | GEM as their userspace buffer management interface this would be a GEM |
973 | objects. | 917 | handle. Drivers are however free to use their own backing storage object |
918 | handles, e.g. vmwgfx directly exposes special TTM handles to userspace | ||
919 | and so expects TTM handles in the create ioctl and not GEM handles. | ||
974 | </para> | 920 | </para> |
975 | <para> | 921 | <para> |
976 | Drivers must first validate the requested frame buffer parameters passed | 922 | Drivers must first validate the requested frame buffer parameters passed |
@@ -992,7 +938,7 @@ int max_width, max_height;</synopsis> | |||
992 | </para> | 938 | </para> |
993 | 939 | ||
994 | <para> | 940 | <para> |
995 | The initailization of the new framebuffer instance is finalized with a | 941 | The initialization of the new framebuffer instance is finalized with a |
996 | call to <function>drm_framebuffer_init</function> which takes a pointer | 942 | call to <function>drm_framebuffer_init</function> which takes a pointer |
997 | to DRM frame buffer operations (struct | 943 | to DRM frame buffer operations (struct |
998 | <structname>drm_framebuffer_funcs</structname>). Note that this function | 944 | <structname>drm_framebuffer_funcs</structname>). Note that this function |
@@ -1052,6 +998,71 @@ int max_width, max_height;</synopsis> | |||
1052 | <function>drm_framebuffer_unregister_private</function>. | 998 | <function>drm_framebuffer_unregister_private</function>. |
1053 | </sect2> | 999 | </sect2> |
1054 | <sect2> | 1000 | <sect2> |
1001 | <title>Dumb Buffer Objects</title> | ||
1002 | <para> | ||
1003 | The KMS API doesn't standardize backing storage object creation and | ||
1004 | leaves it to driver-specific ioctls. Furthermore actually creating a | ||
1005 | buffer object even for GEM-based drivers is done through a | ||
1006 | driver-specific ioctl - GEM only has a common userspace interface for | ||
1007 | sharing and destroying objects. While not an issue for full-fledged | ||
1008 | graphics stacks that include device-specific userspace components (in | ||
1009 | libdrm for instance), this limit makes DRM-based early boot graphics | ||
1010 | unnecessarily complex. | ||
1011 | </para> | ||
1012 | <para> | ||
1013 | Dumb objects partly alleviate the problem by providing a standard | ||
1014 | API to create dumb buffers suitable for scanout, which can then be used | ||
1015 | to create KMS frame buffers. | ||
1016 | </para> | ||
1017 | <para> | ||
1018 | To support dumb objects drivers must implement the | ||
1019 | <methodname>dumb_create</methodname>, | ||
1020 | <methodname>dumb_destroy</methodname> and | ||
1021 | <methodname>dumb_map_offset</methodname> operations. | ||
1022 | </para> | ||
1023 | <itemizedlist> | ||
1024 | <listitem> | ||
1025 | <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, | ||
1026 | struct drm_mode_create_dumb *args);</synopsis> | ||
1027 | <para> | ||
1028 | The <methodname>dumb_create</methodname> operation creates a driver | ||
1029 | object (GEM or TTM handle) suitable for scanout based on the | ||
1030 | width, height and depth from the struct | ||
1031 | <structname>drm_mode_create_dumb</structname> argument. It fills the | ||
1032 | argument's <structfield>handle</structfield>, | ||
1033 | <structfield>pitch</structfield> and <structfield>size</structfield> | ||
1034 | fields with a handle for the newly created object and its line | ||
1035 | pitch and size in bytes. | ||
1036 | </para> | ||
1037 | </listitem> | ||
1038 | <listitem> | ||
1039 | <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, | ||
1040 | uint32_t handle);</synopsis> | ||
1041 | <para> | ||
1042 | The <methodname>dumb_destroy</methodname> operation destroys a dumb | ||
1043 | object created by <methodname>dumb_create</methodname>. | ||
1044 | </para> | ||
1045 | </listitem> | ||
1046 | <listitem> | ||
1047 | <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, | ||
1048 | uint32_t handle, uint64_t *offset);</synopsis> | ||
1049 | <para> | ||
1050 | The <methodname>dumb_map_offset</methodname> operation associates an | ||
1051 | mmap fake offset with the object given by the handle and returns | ||
1052 | it. Drivers must use the | ||
1053 | <function>drm_gem_create_mmap_offset</function> function to | ||
1054 | associate the fake offset as described in | ||
1055 | <xref linkend="drm-gem-objects-mapping"/>. | ||
1056 | </para> | ||
1057 | </listitem> | ||
1058 | </itemizedlist> | ||
1059 | <para> | ||
1060 | Note that dumb objects may not be used for gpu acceleration, as has been | ||
1061 | attempted on some ARM embedded platforms. Such drivers really must have | ||
1062 | a hardware-specific ioctl to allocate suitable buffer objects. | ||
1063 | </para> | ||
1064 | </sect2> | ||
1065 | <sect2> | ||
1055 | <title>Output Polling</title> | 1066 | <title>Output Polling</title> |
1056 | <synopsis>void (*output_poll_changed)(struct drm_device *dev);</synopsis> | 1067 | <synopsis>void (*output_poll_changed)(struct drm_device *dev);</synopsis> |
1057 | <para> | 1068 | <para> |
@@ -2134,7 +2145,7 @@ void intel_crt_init(struct drm_device *dev) | |||
2134 | set the <structfield>display_info</structfield> | 2145 | set the <structfield>display_info</structfield> |
2135 | <structfield>width_mm</structfield> and | 2146 | <structfield>width_mm</structfield> and |
2136 | <structfield>height_mm</structfield> fields if they haven't been set | 2147 | <structfield>height_mm</structfield> fields if they haven't been set |
2137 | already (for instance at initilization time when a fixed-size panel is | 2148 | already (for instance at initialization time when a fixed-size panel is |
2138 | attached to the connector). The mode <structfield>width_mm</structfield> | 2149 | attached to the connector). The mode <structfield>width_mm</structfield> |
2139 | and <structfield>height_mm</structfield> fields are only used internally | 2150 | and <structfield>height_mm</structfield> fields are only used internally |
2140 | during EDID parsing and should not be set when creating modes manually. | 2151 | during EDID parsing and should not be set when creating modes manually. |