drm: document drm_crtc_funcs
And merge any docbook we have into the kerneldoc comments. Since it's a legacy entry point with only two implementation (one each in atomic and legacy crtc helpers) I've made the documentation for set_config fairly sparse - no one should ever need to look at this again, all the ABI we have is baked into code. For ->page_flip otoh I kept all the extensive docs from the docbook and even extended it where it was lacking: Currently we have a pile of legacy page_flip implemantations, and even for atomic drivers there's not yet a standard implementation in the helpers. Which means every driver needs to implement this itself, and precise specs are really valuable. Otherwise there's just cursor, which really just boils down to "use at least universal planes". And gamma tables (where we have a bit a mess with the fbdev helper gamma hooks). v2: Spelling fixes (Eric). v3: Suggestions from Thierry. Cc: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-20-git-send-email-daniel.vetter@ffwll.ch
This commit is contained in:
Daniel Vetter
@@ -1174,121 +1174,6 @@ int max_width, max_height;</synopsis>
|
||||
pointer to CRTC functions.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3 id="drm-kms-crtcops">
|
||||
<title>CRTC Operations</title>
|
||||
<sect4>
|
||||
<title>Set Configuration</title>
|
||||
<synopsis>int (*set_config)(struct drm_mode_set *set);</synopsis>
|
||||
<para>
|
||||
Apply a new CRTC configuration to the device. The configuration
|
||||
specifies a CRTC, a frame buffer to scan out from, a (x,y) position in
|
||||
the frame buffer, a display mode and an array of connectors to drive
|
||||
with the CRTC if possible.
|
||||
</para>
|
||||
<para>
|
||||
If the frame buffer specified in the configuration is NULL, the driver
|
||||
must detach all encoders connected to the CRTC and all connectors
|
||||
attached to those encoders and disable them.
|
||||
</para>
|
||||
<para>
|
||||
This operation is called with the mode config lock held.
|
||||
</para>
|
||||
<note><para>
|
||||
Note that the drm core has no notion of restoring the mode setting
|
||||
state after resume, since all resume handling is in the full
|
||||
responsibility of the driver. The common mode setting helper library
|
||||
though provides a helper which can be used for this:
|
||||
<function>drm_helper_resume_force_mode</function>.
|
||||
</para></note>
|
||||
</sect4>
|
||||
<sect4>
|
||||
<title>Page Flipping</title>
|
||||
<synopsis>int (*page_flip)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
|
||||
struct drm_pending_vblank_event *event);</synopsis>
|
||||
<para>
|
||||
Schedule a page flip to the given frame buffer for the CRTC. This
|
||||
operation is called with the mode config mutex held.
|
||||
</para>
|
||||
<para>
|
||||
Page flipping is a synchronization mechanism that replaces the frame
|
||||
buffer being scanned out by the CRTC with a new frame buffer during
|
||||
vertical blanking, avoiding tearing. When an application requests a page
|
||||
flip the DRM core verifies that the new frame buffer is large enough to
|
||||
be scanned out by the CRTC in the currently configured mode and then
|
||||
calls the CRTC <methodname>page_flip</methodname> operation with a
|
||||
pointer to the new frame buffer.
|
||||
</para>
|
||||
<para>
|
||||
The <methodname>page_flip</methodname> operation schedules a page flip.
|
||||
Once any pending rendering targeting the new frame buffer has
|
||||
completed, the CRTC will be reprogrammed to display that frame buffer
|
||||
after the next vertical refresh. The operation must return immediately
|
||||
without waiting for rendering or page flip to complete and must block
|
||||
any new rendering to the frame buffer until the page flip completes.
|
||||
</para>
|
||||
<para>
|
||||
If a page flip can be successfully scheduled the driver must set the
|
||||
<code>drm_crtc->fb</code> field to the new framebuffer pointed to
|
||||
by <code>fb</code>. This is important so that the reference counting
|
||||
on framebuffers stays balanced.
|
||||
</para>
|
||||
<para>
|
||||
If a page flip is already pending, the
|
||||
<methodname>page_flip</methodname> operation must return
|
||||
-<errorname>EBUSY</errorname>.
|
||||
</para>
|
||||
<para>
|
||||
To synchronize page flip to vertical blanking the driver will likely
|
||||
need to enable vertical blanking interrupts. It should call
|
||||
<function>drm_vblank_get</function> for that purpose, and call
|
||||
<function>drm_vblank_put</function> after the page flip completes.
|
||||
</para>
|
||||
<para>
|
||||
If the application has requested to be notified when page flip completes
|
||||
the <methodname>page_flip</methodname> operation will be called with a
|
||||
non-NULL <parameter>event</parameter> argument pointing to a
|
||||
<structname>drm_pending_vblank_event</structname> instance. Upon page
|
||||
flip completion the driver must call <methodname>drm_send_vblank_event</methodname>
|
||||
to fill in the event and send to wake up any waiting processes.
|
||||
This can be performed with
|
||||
<programlisting><![CDATA[
|
||||
spin_lock_irqsave(&dev->event_lock, flags);
|
||||
...
|
||||
drm_send_vblank_event(dev, pipe, event);
|
||||
spin_unlock_irqrestore(&dev->event_lock, flags);
|
||||
]]></programlisting>
|
||||
</para>
|
||||
<note><para>
|
||||
FIXME: Could drivers that don't need to wait for rendering to complete
|
||||
just add the event to <literal>dev->vblank_event_list</literal> and
|
||||
let the DRM core handle everything, as for "normal" vertical blanking
|
||||
events?
|
||||
</para></note>
|
||||
<para>
|
||||
While waiting for the page flip to complete, the
|
||||
<literal>event->base.link</literal> list head can be used freely by
|
||||
the driver to store the pending event in a driver-specific list.
|
||||
</para>
|
||||
<para>
|
||||
If the file handle is closed before the event is signaled, drivers must
|
||||
take care to destroy the event in their
|
||||
<methodname>preclose</methodname> operation (and, if needed, call
|
||||
<function>drm_vblank_put</function>).
|
||||
</para>
|
||||
</sect4>
|
||||
<sect4>
|
||||
<title>Miscellaneous</title>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
|
||||
uint32_t start, uint32_t size);</synopsis>
|
||||
<para>
|
||||
Apply a gamma table to the device. The operation is optional.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect4>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Planes (struct <structname>drm_plane</structname>)</title>
|
||||
@@ -1305,7 +1190,7 @@ int max_width, max_height;</synopsis>
|
||||
<listitem>
|
||||
DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary
|
||||
planes are the planes operated upon by CRTC modesetting and flipping
|
||||
operations described in <xref linkend="drm-kms-crtcops"/>.
|
||||
operations described in the page_flip hook in <structname>drm_crtc_funcs</structname>.
|
||||
</listitem>
|
||||
<listitem>
|
||||
DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor
|
||||
|
||||
Reference in New Issue
Block a user