The DRM subsystem aims for a strong separation between core code and helper libraries. Core code takes care of general setup and teardown and decoding userspace requests to kernel internal objects. Everything else is handled by a large set of helper libraries, which can be combined freely to pick and choose for each driver what fits, and avoid shared code where special behaviour is needed.
This distinction between core code and helpers is especially strong in the modesetting code, where there’s a shared userspace ABI for all drivers. This is in contrast to the render side, where pretty much everything (with very few exceptions) can be considered optional helper code.
There are a few areas these helpers can grouped into:
The DRM mode setting helper functions are common code for drivers to use if they wish. Drivers are not forced to use this code in their implementations but it would be useful if the code they do use at least provides a consistent interface and operation to userspace. Therefore it is highly recommended to use the provided helpers as much as possible.
Because there is only one pointer per modeset object to hold a vfunc table for helper libraries they are by necessity shared among the different helpers.
To make this clear all the helper vtables are pulled together in this location here.
helper operations for CRTCs
Definition
struct drm_crtc_helper_funcs {
void (* dpms) (struct drm_crtc *crtc, int mode);
void (* prepare) (struct drm_crtc *crtc);
void (* commit) (struct drm_crtc *crtc);
bool (* mode_fixup) (struct drm_crtc *crtc,const struct drm_display_mode *mode,struct drm_display_mode *adjusted_mode);
int (* mode_set) (struct drm_crtc *crtc, struct drm_display_mode *mode,struct drm_display_mode *adjusted_mode, int x, int y,struct drm_framebuffer *old_fb);
void (* mode_set_nofb) (struct drm_crtc *crtc);
int (* mode_set_base) (struct drm_crtc *crtc, int x, int y,struct drm_framebuffer *old_fb);
int (* mode_set_base_atomic) (struct drm_crtc *crtc,struct drm_framebuffer *fb, int x, int y,enum mode_set_atomic);
void (* load_lut) (struct drm_crtc *crtc);
void (* disable) (struct drm_crtc *crtc);
void (* enable) (struct drm_crtc *crtc);
int (* atomic_check) (struct drm_crtc *crtc,struct drm_crtc_state *state);
void (* atomic_begin) (struct drm_crtc *crtc,struct drm_crtc_state *old_crtc_state);
void (* atomic_flush) (struct drm_crtc *crtc,struct drm_crtc_state *old_crtc_state);
void (* atomic_disable) (struct drm_crtc *crtc,struct drm_crtc_state *old_crtc_state);
};
Members
Callback to control power levels on the CRTC. If the mode passed in is unsupported, the provider must use the next lowest power level. This is used by the legacy CRTC helpers to implement DPMS functionality in drm_helper_connector_dpms().
This callback is also used to disable a CRTC by calling it with DRM_MODE_DPMS_OFF if the disable hook isn’t used.
This callback is used by the legacy CRTC helpers. Atomic helpers also support using this hook for enabling and disabling a CRTC to facilitate transitions to atomic, but it is deprecated. Instead enable and disable should be used.
This callback should prepare the CRTC for a subsequent modeset, which in practice means the driver should disable the CRTC if it is running. Most drivers ended up implementing this by calling their dpms hook with DRM_MODE_DPMS_OFF.
This callback is used by the legacy CRTC helpers. Atomic helpers also support using this hook for disabling a CRTC to facilitate transitions to atomic, but it is deprecated. Instead disable should be used.
This callback should commit the new mode on the CRTC after a modeset, which in practice means the driver should enable the CRTC. Most drivers ended up implementing this by calling their dpms hook with DRM_MODE_DPMS_ON.
This callback is used by the legacy CRTC helpers. Atomic helpers also support using this hook for enabling a CRTC to facilitate transitions to atomic, but it is deprecated. Instead enable should be used.
This callback is used to validate a mode. The parameter mode is the display mode that userspace requested, adjusted_mode is the mode the encoders need to be fed with. Note that this is the inverse semantics of the meaning for the drm_encoder and drm_bridge_funcs.mode_fixup vfunc. If the CRTC cannot support the requested conversion from mode to adjusted_mode it should reject the modeset.
This function is used by both legacy CRTC helpers and atomic helpers. With atomic helpers it is optional.
NOTE:
This function is called in the check phase of atomic modesets, which can be aborted for any reason (including on userspace’s request to just check whether a configuration would be possible). Atomic drivers MUST NOT touch any persistent state (hardware or software) or data structures except the passed in adjusted_mode parameter.
This is in contrast to the legacy CRTC helpers where this was allowed.
Atomic drivers which need to inspect and adjust more state should instead use the atomic_check callback.
Also beware that neither core nor helpers filter modes before passing them to the driver: While the list of modes that is advertised to userspace is filtered using the drm_connector.mode_valid callback, neither the core nor the helpers do any filtering on modes passed in from userspace when setting a mode. It is therefore possible for userspace to pass in a mode that was previously filtered out using drm_connector.mode_valid or add a custom mode that wasn’t probed from EDID or similar to begin with. Even though this is an advanced feature and rarely used nowadays, some users rely on being able to specify modes manually so drivers must be prepared to deal with it. Specifically this means that all drivers need not only validate modes in drm_connector.mode_valid but also in this or in the drm_encoder_helper_funcs.mode_fixup callback to make sure invalid modes passed in from userspace are rejected.
RETURNS:
True if an acceptable configuration is possible, false if the modeset operation should be rejected.
This callback is used by the legacy CRTC helpers to set a new mode, position and framebuffer. Since it ties the primary plane to every mode change it is incompatible with universal plane support. And since it can’t update other planes it’s incompatible with atomic modeset support.
This callback is only used by CRTC helpers and deprecated.
RETURNS:
0 on success or a negative error code on failure.
This callback is used to update the display mode of a CRTC without changing anything of the primary plane configuration. This fits the requirement of atomic and hence is used by the atomic helpers. It is also used by the transitional plane helpers to implement a mode_set hook in drm_helper_crtc_mode_set().
Note that the display pipe is completely off when this function is called. Atomic drivers which need hardware to be running before they program the new display mode (e.g. because they implement runtime PM) should not use this hook. This is because the helper library calls this hook only once per mode change and not every time the display pipeline is suspended using either DPMS or the new “ACTIVE” property. Which means register values set in this callback might get reset when the CRTC is suspended, but not restored. Such drivers should instead move all their CRTC setup into the enable callback.
This callback is optional.
This callback is used by the legacy CRTC helpers to set a new framebuffer and scanout position. It is optional and used as an optimized fast-path instead of a full mode set operation with all the resulting flickering. If it is not present drm_crtc_helper_set_config() will fall back to a full modeset, using the mode_set callback. Since it can’t update other planes it’s incompatible with atomic modeset support.
This callback is only used by the CRTC helpers and deprecated.
RETURNS:
0 on success or a negative error code on failure.
This callback is used by the fbdev helpers to set a new framebuffer and scanout without sleeping, i.e. from an atomic calling context. It is only used to implement kgdb support.
This callback is optional and only needed for kgdb support in the fbdev helpers.
RETURNS:
0 on success or a negative error code on failure.
Load a LUT prepared with the drm_fb_helper_funcs.gamma_set vfunc.
This callback is optional and is only used by the fbdev emulation helpers.
FIXME:
This callback is functionally redundant with the core gamma table support and simply exists because the fbdev hasn’t yet been refactored to use the core gamma table interfaces.
This callback should be used to disable the CRTC. With the atomic drivers it is called after all encoders connected to this CRTC have been shut off already using their own drm_encoder_helper_funcs.disable hook. If that sequence is too simple drivers can just add their own hooks and call it from this CRTC callback here by looping over all encoders connected to it using for_each_encoder_on_crtc().
This hook is used both by legacy CRTC helpers and atomic helpers. Atomic drivers don’t need to implement it if there’s no need to disable anything at the CRTC level. To ensure that runtime PM handling (using either DPMS or the new “ACTIVE” property) works disable must be the inverse of enable for atomic drivers. Atomic drivers should consider to use atomic_disable instead of this one.
NOTE:
With legacy CRTC helpers there’s a big semantic difference between disable and other hooks (like prepare or dpms) used to shut down a CRTC: disable is only called when also logically disabling the display pipeline and needs to release any resources acquired in mode_set (like shared PLLs, or again release pinned framebuffers).
Therefore disable must be the inverse of mode_set plus commit for drivers still using legacy CRTC helpers, which is different from the rules under atomic.
This callback should be used to enable the CRTC. With the atomic drivers it is called before all encoders connected to this CRTC are enabled through the encoder’s own drm_encoder_helper_funcs.enable hook. If that sequence is too simple drivers can just add their own hooks and call it from this CRTC callback here by looping over all encoders connected to it using for_each_encoder_on_crtc().
This hook is used only by atomic helpers, for symmetry with disable. Atomic drivers don’t need to implement it if there’s no need to enable anything at the CRTC level. To ensure that runtime PM handling (using either DPMS or the new “ACTIVE” property) works enable must be the inverse of disable for atomic drivers.
Drivers should check plane-update related CRTC constraints in this hook. They can also check mode related limitations but need to be aware of the calling order, since this hook is used by drm_atomic_helper_check_planes() whereas the preparations needed to check output routing and the display mode is done in drm_atomic_helper_check_modeset(). Therefore drivers that want to check output routing and display mode constraints in this callback must ensure that drm_atomic_helper_check_modeset() has been called beforehand. This is calling order used by the default helper implementation in drm_atomic_helper_check().
When using drm_atomic_helper_check_planes() this hook is called after the drm_plane_helper_funcs.atomc_check hook for planes, which allows drivers to assign shared resources requested by planes in this callback here. For more complicated dependencies the driver can call the provided check helpers multiple times until the computed state has a final configuration and everything has been checked.
This function is also allowed to inspect any other object’s state and can add more state objects to the atomic commit if needed. Care must be taken though to ensure that state check and compute functions for these added states are all called, and derived state in other objects all updated. Again the recommendation is to just call check helpers until a maximal configuration is reached.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
NOTE:
This function is called in the check phase of an atomic update. The driver is not allowed to change anything outside of the free-standing state objects passed-in or assembled in the overall drm_atomic_state update tracking structure.
RETURNS:
0 on success, -EINVAL if the state or the transition can’t be supported, -ENOMEM on memory allocation failure and -EDEADLK if an attempt to obtain another state object ran into a drm_modeset_lock deadlock.
Drivers should prepare for an atomic update of multiple planes on a CRTC in this hook. Depending upon hardware this might be vblank evasion, blocking updates by setting bits or doing preparatory work for e.g. manual update display.
This hook is called before any plane commit functions are called.
Note that the power state of the display pipe when this function is called depends upon the exact helpers and calling sequence the driver has picked. See drm_atomic_helper_commit_planes() for a discussion of the tradeoffs and variants of plane commit helpers.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
Drivers should finalize an atomic update of multiple planes on a CRTC in this hook. Depending upon hardware this might include checking that vblank evasion was successful, unblocking updates by setting bits or setting the GO bit to flush out all updates.
Simple hardware or hardware with special requirements can commit and flush out all updates for all planes from this hook and forgo all the other commit hooks for plane updates.
This hook is called after any plane commit functions are called.
Note that the power state of the display pipe when this function is called depends upon the exact helpers and calling sequence the driver has picked. See drm_atomic_helper_commit_planes() for a discussion of the tradeoffs and variants of plane commit helpers.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
This callback should be used to disable the CRTC. With the atomic drivers it is called after all encoders connected to this CRTC have been shut off already using their own drm_encoder_helper_funcs.disable hook. If that sequence is too simple drivers can just add their own hooks and call it from this CRTC callback here by looping over all encoders connected to it using for_each_encoder_on_crtc().
This hook is used only by atomic helpers. Atomic drivers don’t need to implement it if there’s no need to disable anything at the CRTC level.
Comparing to disable, this one provides the additional input parameter old_crtc_state which could be used to access the old state. Atomic drivers should consider to use this one instead of disable.
Description
These hooks are used by the legacy CRTC helpers, the transitional plane helpers and the new atomic modesetting helpers.
sets the helper vtable for a crtc
Parameters
helper operations for encoders
Definition
struct drm_encoder_helper_funcs {
void (* dpms) (struct drm_encoder *encoder, int mode);
bool (* mode_fixup) (struct drm_encoder *encoder,const struct drm_display_mode *mode,struct drm_display_mode *adjusted_mode);
void (* prepare) (struct drm_encoder *encoder);
void (* commit) (struct drm_encoder *encoder);
void (* mode_set) (struct drm_encoder *encoder,struct drm_display_mode *mode,struct drm_display_mode *adjusted_mode);
void (* atomic_mode_set) (struct drm_encoder *encoder,struct drm_crtc_state *crtc_state,struct drm_connector_state *conn_state);
struct drm_crtc *(* get_crtc) (struct drm_encoder *encoder);
enum drm_connector_status (* detect) (struct drm_encoder *encoder,struct drm_connector *connector);
void (* disable) (struct drm_encoder *encoder);
void (* enable) (struct drm_encoder *encoder);
int (* atomic_check) (struct drm_encoder *encoder,struct drm_crtc_state *crtc_state,struct drm_connector_state *conn_state);
};
Members
Callback to control power levels on the encoder. If the mode passed in is unsupported, the provider must use the next lowest power level. This is used by the legacy encoder helpers to implement DPMS functionality in drm_helper_connector_dpms().
This callback is also used to disable an encoder by calling it with DRM_MODE_DPMS_OFF if the disable hook isn’t used.
This callback is used by the legacy CRTC helpers. Atomic helpers also support using this hook for enabling and disabling an encoder to facilitate transitions to atomic, but it is deprecated. Instead enable and disable should be used.
This callback is used to validate and adjust a mode. The parameter mode is the display mode that should be fed to the next element in the display chain, either the final drm_connector or a drm_bridge. The parameter adjusted_mode is the input mode the encoder requires. It can be modified by this callback and does not need to match mode.
This function is used by both legacy CRTC helpers and atomic helpers. This hook is optional.
NOTE:
This function is called in the check phase of atomic modesets, which can be aborted for any reason (including on userspace’s request to just check whether a configuration would be possible). Atomic drivers MUST NOT touch any persistent state (hardware or software) or data structures except the passed in adjusted_mode parameter.
This is in contrast to the legacy CRTC helpers where this was allowed.
Atomic drivers which need to inspect and adjust more state should instead use the atomic_check callback.
Also beware that neither core nor helpers filter modes before passing them to the driver: While the list of modes that is advertised to userspace is filtered using the connector’s drm_connector_helper_funcs.mode_valid callback, neither the core nor the helpers do any filtering on modes passed in from userspace when setting a mode. It is therefore possible for userspace to pass in a mode that was previously filtered out using drm_connector_helper_funcs.mode_valid or add a custom mode that wasn’t probed from EDID or similar to begin with. Even though this is an advanced feature and rarely used nowadays, some users rely on being able to specify modes manually so drivers must be prepared to deal with it. Specifically this means that all drivers need not only validate modes in drm_connector.mode_valid but also in this or in the drm_crtc_helper_funcs.mode_fixup callback to make sure invalid modes passed in from userspace are rejected.
RETURNS:
True if an acceptable configuration is possible, false if the modeset operation should be rejected.
This callback should prepare the encoder for a subsequent modeset, which in practice means the driver should disable the encoder if it is running. Most drivers ended up implementing this by calling their dpms hook with DRM_MODE_DPMS_OFF.
This callback is used by the legacy CRTC helpers. Atomic helpers also support using this hook for disabling an encoder to facilitate transitions to atomic, but it is deprecated. Instead disable should be used.
This callback should commit the new mode on the encoder after a modeset, which in practice means the driver should enable the encoder. Most drivers ended up implementing this by calling their dpms hook with DRM_MODE_DPMS_ON.
This callback is used by the legacy CRTC helpers. Atomic helpers also support using this hook for enabling an encoder to facilitate transitions to atomic, but it is deprecated. Instead enable should be used.
This callback is used to update the display mode of an encoder.
Note that the display pipe is completely off when this function is called. Drivers which need hardware to be running before they program the new display mode (because they implement runtime PM) should not use this hook, because the helper library calls it only once and not every time the display pipeline is suspend using either DPMS or the new “ACTIVE” property. Such drivers should instead move all their encoder setup into the enable callback.
This callback is used both by the legacy CRTC helpers and the atomic modeset helpers. It is optional in the atomic helpers.
NOTE:
If the driver uses the atomic modeset helpers and needs to inspect the connector state or connector display info during mode setting, atomic_mode_set can be used instead.
This callback is used to update the display mode of an encoder.
Note that the display pipe is completely off when this function is called. Drivers which need hardware to be running before they program the new display mode (because they implement runtime PM) should not use this hook, because the helper library calls it only once and not every time the display pipeline is suspended using either DPMS or the new “ACTIVE” property. Such drivers should instead move all their encoder setup into the enable callback.
This callback is used by the atomic modeset helpers in place of the mode_set callback, if set by the driver. It is optional and should be used instead of mode_set if the driver needs to inspect the connector state or display info, since there is no direct way to go from the encoder to the current connector.
This callback is used by the legacy CRTC helpers to work around deficiencies in its own book-keeping.
Do not use, use atomic helpers instead, which get the book keeping right.
FIXME:
Currently only nouveau is using this, and as soon as nouveau is atomic we can ditch this hook.
This callback can be used by drivers who want to do detection on the encoder object instead of in connector functions.
It is not used by any helper and therefore has purely driver-specific semantics. New drivers shouldn’t use this and instead just implement their own private callbacks.
FIXME:
This should just be converted into a pile of driver vfuncs. Currently radeon, amdgpu and nouveau are using it.
This callback should be used to disable the encoder. With the atomic drivers it is called before this encoder’s CRTC has been shut off using their own drm_crtc_helper_funcs.disable hook. If that sequence is too simple drivers can just add their own driver private encoder hooks and call them from CRTC’s callback by looping over all encoders connected to it using for_each_encoder_on_crtc().
This hook is used both by legacy CRTC helpers and atomic helpers. Atomic drivers don’t need to implement it if there’s no need to disable anything at the encoder level. To ensure that runtime PM handling (using either DPMS or the new “ACTIVE” property) works disable must be the inverse of enable for atomic drivers.
NOTE:
With legacy CRTC helpers there’s a big semantic difference between disable and other hooks (like prepare or dpms) used to shut down a encoder: disable is only called when also logically disabling the display pipeline and needs to release any resources acquired in mode_set (like shared PLLs, or again release pinned framebuffers).
Therefore disable must be the inverse of mode_set plus commit for drivers still using legacy CRTC helpers, which is different from the rules under atomic.
This callback should be used to enable the encoder. With the atomic drivers it is called after this encoder’s CRTC has been enabled using their own drm_crtc_helper_funcs.enable hook. If that sequence is too simple drivers can just add their own driver private encoder hooks and call them from CRTC’s callback by looping over all encoders connected to it using for_each_encoder_on_crtc().
This hook is used only by atomic helpers, for symmetry with disable. Atomic drivers don’t need to implement it if there’s no need to enable anything at the encoder level. To ensure that runtime PM handling (using either DPMS or the new “ACTIVE” property) works enable must be the inverse of disable for atomic drivers.
This callback is used to validate encoder state for atomic drivers. Since the encoder is the object connecting the CRTC and connector it gets passed both states, to be able to validate interactions and update the CRTC to match what the encoder needs for the requested connector.
This function is used by the atomic helpers, but it is optional.
NOTE:
This function is called in the check phase of an atomic update. The driver is not allowed to change anything outside of the free-standing state objects passed-in or assembled in the overall drm_atomic_state update tracking structure.
RETURNS:
0 on success, -EINVAL if the state or the transition can’t be supported, -ENOMEM on memory allocation failure and -EDEADLK if an attempt to obtain another state object ran into a drm_modeset_lock deadlock.
Description
These hooks are used by the legacy CRTC helpers, the transitional plane helpers and the new atomic modesetting helpers.
sets the helper vtable for an encoder
Parameters
helper operations for connectors
Definition
struct drm_connector_helper_funcs {
int (* get_modes) (struct drm_connector *connector);
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,struct drm_display_mode *mode);
struct drm_encoder *(* best_encoder) (struct drm_connector *connector);
struct drm_encoder *(* atomic_best_encoder) (struct drm_connector *connector,struct drm_connector_state *connector_state);
};
Members
This function should fill in all modes currently valid for the sink into the drm_connector.probed_modes list. It should also update the EDID property by calling drm_mode_connector_update_edid_property().
The usual way to implement this is to cache the EDID retrieved in the probe callback somewhere in the driver-private connector structure. In this function drivers then parse the modes in the EDID and add them by calling drm_add_edid_modes(). But connectors that driver a fixed panel can also manually add specific modes using drm_mode_probed_add(). Drivers which manually add modes should also make sure that the drm_connector.display_info, drm_connector.width_mm and drm_connector.height_mm fields are filled in.
Virtual drivers that just want some standard VESA mode with a given resolution can call drm_add_modes_noedid(), and mark the preferred one using drm_set_preferred_mode().
Finally drivers that support audio probably want to update the ELD data, too, using drm_edid_to_eld().
This function is only called after the detect hook has indicated that a sink is connected and when the EDID isn’t overridden through sysfs or the kernel commandline.
This callback is used by the probe helpers in e.g. drm_helper_probe_single_connector_modes().
RETURNS:
The number of modes added by calling drm_mode_probed_add().
Callback to validate a mode for a connector, irrespective of the specific display configuration.
This callback is used by the probe helpers to filter the mode list (which is usually derived from the EDID data block from the sink). See e.g. drm_helper_probe_single_connector_modes().
NOTE:
This only filters the mode list supplied to userspace in the GETCONNECOTR IOCTL. Userspace is free to create modes of its own and ask the kernel to use them. It this case the atomic helpers or legacy CRTC helpers will not call this function. Drivers therefore must still fully validate any mode passed in in a modeset request.
RETURNS:
Either drm_mode_status.MODE_OK or one of the failure reasons in enum drm_mode_status.
This function should select the best encoder for the given connector.
This function is used by both the atomic helpers (in the drm_atomic_helper_check_modeset() function) and in the legacy CRTC helpers.
NOTE:
In atomic drivers this function is called in the check phase of an atomic update. The driver is not allowed to change or inspect anything outside of arguments passed-in. Atomic drivers which need to inspect dynamic configuration state should instead use atomic_best_encoder.
You can leave this function to NULL if the connector is only attached to a single encoder and you are using the atomic helpers. In this case, the core will call drm_atomic_helper_best_encoder() for you.
RETURNS:
Encoder that should be used for the given connector and connector state, or NULL if no suitable encoder exists. Note that the helpers will ensure that encoders aren’t used twice, drivers should not check for this.
This is the atomic version of best_encoder for atomic drivers which need to select the best encoder depending upon the desired configuration and can’t select it statically.
This function is used by drm_atomic_helper_check_modeset(). If it is not implemented, the core will fallback to best_encoder (or drm_atomic_helper_best_encoder() if best_encoder is NULL).
NOTE:
This function is called in the check phase of an atomic update. The driver is not allowed to change anything outside of the free-standing state objects passed-in or assembled in the overall drm_atomic_state update tracking structure.
RETURNS:
Encoder that should be used for the given connector and connector state, or NULL if no suitable encoder exists. Note that the helpers will ensure that encoders aren’t used twice, drivers should not check for this.
Description
These functions are used by the atomic and legacy modeset helpers and by the probe helpers.
sets the helper vtable for a connector
Parameters
helper operations for planes
Definition
struct drm_plane_helper_funcs {
int (* prepare_fb) (struct drm_plane *plane,struct drm_plane_state *new_state);
void (* cleanup_fb) (struct drm_plane *plane,struct drm_plane_state *old_state);
int (* atomic_check) (struct drm_plane *plane,struct drm_plane_state *state);
void (* atomic_update) (struct drm_plane *plane,struct drm_plane_state *old_state);
void (* atomic_disable) (struct drm_plane *plane,struct drm_plane_state *old_state);
};
Members
This hook is to prepare a framebuffer for scanout by e.g. pinning it’s backing storage or relocating it into a contiguous block of VRAM. Other possible preparatory work includes flushing caches.
This function must not block for outstanding rendering, since it is called in the context of the atomic IOCTL even for async commits to be able to return any errors to userspace. Instead the recommended way is to fill out the fence member of the passed-in drm_plane_state. If the driver doesn’t support native fences then equivalent functionality should be implemented through private members in the plane structure.
The helpers will call cleanup_fb with matching arguments for every successful call to this hook.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
RETURNS:
0 on success or one of the following negative error codes allowed by the drm_mode_config_funcs.atomic_commit vfunc. When using helpers this callback is the only one which can fail an atomic commit, everything else must complete successfully.
This hook is called to clean up any resources allocated for the given framebuffer and plane configuration in prepare_fb.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
Drivers should check plane specific constraints in this hook.
When using drm_atomic_helper_check_planes() plane’s atomic_check hooks are called before the ones for CRTCs, which allows drivers to request shared resources that the CRTC controls here. For more complicated dependencies the driver can call the provided check helpers multiple times until the computed state has a final configuration and everything has been checked.
This function is also allowed to inspect any other object’s state and can add more state objects to the atomic commit if needed. Care must be taken though to ensure that state check and compute functions for these added states are all called, and derived state in other objects all updated. Again the recommendation is to just call check helpers until a maximal configuration is reached.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
NOTE:
This function is called in the check phase of an atomic update. The driver is not allowed to change anything outside of the free-standing state objects passed-in or assembled in the overall drm_atomic_state update tracking structure.
RETURNS:
0 on success, -EINVAL if the state or the transition can’t be supported, -ENOMEM on memory allocation failure and -EDEADLK if an attempt to obtain another state object ran into a drm_modeset_lock deadlock.
Drivers should use this function to update the plane state. This hook is called in-between the drm_crtc_helper_funcs.atomic_begin and drm_crtc_helper_funcs.atomic_flush callbacks.
Note that the power state of the display pipe when this function is called depends upon the exact helpers and calling sequence the driver has picked. See drm_atomic_helper_commit_planes() for a discussion of the tradeoffs and variants of plane commit helpers.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
Drivers should use this function to unconditionally disable a plane. This hook is called in-between the drm_crtc_helper_funcs.atomic_begin and drm_crtc_helper_funcs.atomic_flush callbacks. It is an alternative to atomic_update, which will be called for disabling planes, too, if the atomic_disable hook isn’t implemented.
This hook is also useful to disable planes in preparation of a modeset, by calling drm_atomic_helper_disable_planes_on_crtc() from the drm_crtc_helper_funcs.disable hook.
Note that the power state of the display pipe when this function is called depends upon the exact helpers and calling sequence the driver has picked. See drm_atomic_helper_commit_planes() for a discussion of the tradeoffs and variants of plane commit helpers.
This callback is used by the atomic modeset helpers and by the transitional plane helpers, but it is optional.
Description
These functions are used by the atomic helpers and by the transitional plane helpers.
sets the helper vtable for a plane
Parameters
global modeset helper operations
Definition
struct drm_mode_config_helper_funcs {
void (* atomic_commit_tail) (struct drm_atomic_state *state);
};
Members
This hook is used by the default atomic_commit() hook implemented in drm_atomic_helper_commit() together with the nonblocking commit helpers (see drm_atomic_helper_setup_commit() for a starting point) to implement blocking and nonblocking commits easily. It is not used by the atomic helpers
This function is called when the new atomic state has already been swapped into the various state pointers. The passed in state therefore contains copies of the old/previous state. This hook should commit the new state into hardware. Note that the helpers have already waited for preceeding atomic commits and fences, but drivers can add more waiting calls at the start of their implementation, e.g. to wait for driver-internal request for implicit syncing, before starting to commit the update to the hardware.
After the atomic update is committed to the hardware this hook needs to call drm_atomic_helper_commit_hw_done(). Then wait for the upate to be executed by the hardware, for example using drm_atomic_helper_wait_for_vblanks(), and then clean up the old framebuffers using drm_atomic_helper_cleanup_planes().
When disabling a CRTC this hook _must_ stall for the commit to complete. Vblank waits don’t work on disabled CRTC, hence the core can’t take care of this. And it also can’t rely on the vblank event, since that can be signalled already when the screen shows black, which can happen much earlier than the last hardware access needed to shut off the display pipeline completely.
This hook is optional, the default implementation is drm_atomic_helper_commit_tail().
Description
These helper functions are used by the atomic helpers.
This helper library provides implementations of check and commit functions on top of the CRTC modeset helper callbacks and the plane helper callbacks. It also provides convenience implementations for the atomic state handling callbacks for drivers which don’t need to subclass the drm core structures to add their own additional internal state.
This library also provides default implementations for the check callback in drm_atomic_helper_check() and for the commit callback with drm_atomic_helper_commit(). But the individual stages and callbacks are exposed to allow drivers to mix and match and e.g. use the plane helpers only together with a driver private modeset implementation.
This library also provides implementations for all the legacy driver interfaces on top of the atomic interface. See drm_atomic_helper_set_config(), drm_atomic_helper_disable_plane(), drm_atomic_helper_disable_plane() and the various functions to implement set_property callbacks. New drivers must not implement these functions themselves but must use the provided helpers.
The atomic helper uses the same function table structures as all other modesetting helpers. See the documentation for struct drm_crtc_helper_funcs, struct drm_encoder_helper_funcs and struct drm_connector_helper_funcs. It also shares the struct drm_plane_helper_funcs function table with the plane helpers.
Nonblocking atomic commits have to be implemented in the following sequence:
1. Run drm_atomic_helper_prepare_planes() first. This is the only function which commit needs to call which can fail, so we want to run it first and synchronously.
2. Synchronize with any outstanding nonblocking commit worker threads which might be affected the new state update. This can be done by either cancelling or flushing the work items, depending upon whether the driver can deal with cancelled updates. Note that it is important to ensure that the framebuffer cleanup is still done when cancelling.
Asynchronous workers need to have sufficient parallelism to be able to run different atomic commits on different CRTCs in parallel. The simplest way to achive this is by running them on the system_unbound_wq work queue. Note that drivers are not required to split up atomic commits and run an individual commit in parallel - userspace is supposed to do that if it cares. But it might be beneficial to do that for modesets, since those necessarily must be done as one global operation, and enabling or disabling a CRTC can take a long time. But even that is not required.
3. The software state is updated synchronously with drm_atomic_helper_swap_state(). Doing this under the protection of all modeset locks means concurrent callers never see inconsistent state. And doing this while it’s guaranteed that no relevant nonblocking worker runs means that nonblocking workers do not need grab any locks. Actually they must not grab locks, for otherwise the work flushing will deadlock.
4. Schedule a work item to do all subsequent steps, using the split-out commit helpers: a) pre-plane commit b) plane commit c) post-plane commit and then cleaning up the framebuffers after the old framebuffer is no longer being displayed.
The above scheme is implemented in the atomic helper libraries in drm_atomic_helper_commit() using a bunch of helper functions. See drm_atomic_helper_setup_commit() for a starting point.
Both the drm core and the atomic helpers assume that there is always the full and correct atomic software state for all connectors, CRTCs and planes available. Which is a bit a problem on driver load and also after system suspend. One way to solve this is to have a hardware state read-out infrastructure which reconstructs the full software state (e.g. the i915 driver).
The simpler solution is to just reset the software state to everything off, which is easiest to do by calling drm_mode_config_reset(). To facilitate this the atomic helpers provide default reset implementations for all hooks.
On the upside the precise state tracking of atomic simplifies system suspend and resume a lot. For drivers using drm_mode_config_reset() a complete recipe is implemented in drm_atomic_helper_suspend() and drm_atomic_helper_resume(). For other drivers the building blocks are split out, see the documentation for these functions.
iterate over planes currently attached to CRTC
Parameters
Description
This iterates over the current state, useful (for example) when applying atomic state after it has been checked and swapped. To iterate over the planes which will be attached (more useful in code called from drm_mode_config_funcs.atomic_check) see drm_atomic_crtc_state_for_each_plane().
iterate over attached planes in new state
Parameters
Description
Similar to drm_crtc_for_each_plane(), but iterates the planes that will be attached if the specified state is applied. Useful during for example in code called from drm_mode_config_funcs.atomic_check operations, to validate the incoming state.
iterate over attached planes in new state
Parameters
Description
Similar to drm_crtc_for_each_plane(), but iterates the planes that will be attached if the specified state is applied. Useful during for example in code called from drm_mode_config_funcs.atomic_check operations, to validate the incoming state.
Compared to just drm_atomic_crtc_state_for_each_plane() this also fills in a const plane_state. This is useful when a driver just wants to peek at other active planes on this crtc, but does not need to change it.
check whether a plane is being disabled
Parameters
Description
Checks the atomic state of a plane to determine whether it’s being disabled or not. This also WARNs if it detects an invalid state (both CRTC and FB need to either both be NULL or both be non-NULL).
Return
True if the plane is being disabled, false otherwise.
validate state object for modeset changes
Parameters
Description
Check the state object to see if the requested state is physically possible. This does all the crtc and connector related computations for an atomic update and adds any additional connectors needed for full modesets and calls down into drm_crtc_helper_funcs.mode_fixup and drm_encoder_helper_funcs.mode_fixup or drm_encoder_helper_funcs.atomic_check functions of the driver backend.
drm_crtc_state.mode_changed is set when the input mode is changed. drm_crtc_state.connectors_changed is set when a connector is added or removed from the crtc. drm_crtc_state.active_changed is set when drm_crtc_state.active changes, which is used for DPMS. See also: drm_atomic_crtc_needs_modeset()
IMPORTANT:
Drivers which set drm_crtc_state.mode_changed (e.g. in their drm_plane_helper_funcs.atomic_check hooks if a plane update can’t be done without a full modeset) _must_ call this function afterwards after that change. It is permitted to call this function multiple times for the same update, e.g. when the drm_crtc_helper_funcs.atomic_check functions depend upon the adjusted dotclock for fifo space allocation and watermark computation.
Return
Zero for success or -errno
validate state object for planes changes
Parameters
Description
Check the state object to see if the requested state is physically possible. This does all the plane update related checks using by calling into the drm_crtc_helper_funcs.atomic_check and drm_plane_helper_funcs.atomic_check hooks provided by the driver.
It also sets drm_crtc_state.planes_changed to indicate that a crtc has updated planes.
Return
Zero for success or -errno
validate state object
Parameters
Description
Check the state object to see if the requested state is physically possible. Only crtcs and planes have check callbacks, so for any additional (global) checking that a driver needs it can simply wrap that around this function. Drivers without such needs can directly use this as their drm_mode_config_funcs.atomic_check callback.
This just wraps the two parts of the state checking for planes and modeset state in the default order: First it calls drm_atomic_helper_check_modeset() and then drm_atomic_helper_check_planes(). The assumption is that the drm_plane_helper_funcs.atomic_check and drm_crtc_helper_funcs.atomic_check functions depend upon an updated adjusted_mode.clock to e.g. properly compute watermarks.
Return
Zero for success or -errno
update legacy modeset state
Parameters
Description
This function updates all the various legacy modeset state pointers in connectors, encoders and crtcs. It also updates the timestamping constants used for precise vblank timestamps by calling drm_calc_timestamping_constants().
Drivers can use this for building their own atomic commit if they don’t have a pure helper-based modeset implementation.
modeset commit to disable outputs
Parameters
Description
This function shuts down all the outputs that need to be shut down and prepares them (if required) with the new mode.
For compatibility with legacy crtc helpers this should be called before drm_atomic_helper_commit_planes(), which is what the default commit function does. But drivers with different needs can group the modeset commits together and do the plane commits at the end. This is useful for drivers doing runtime PM since planes updates then only happen when the CRTC is actually enabled.
modeset commit to enable outputs
Parameters
Description
This function enables all the outputs with the new configuration which had to be turned off for the update.
For compatibility with legacy crtc helpers this should be called after drm_atomic_helper_commit_planes(), which is what the default commit function does. But drivers with different needs can group the modeset commits together and do the plane commits at the end. This is useful for drivers doing runtime PM since planes updates then only happen when the CRTC is actually enabled.
wait for fences stashed in plane state
Parameters
Description
For implicit sync, driver should fish the exclusive fence out from the incoming fb’s and stash it in the drm_plane_state. This is called after drm_atomic_helper_swap_state() so it uses the current plane state (and just uses the atomic state to find the changed planes)
Note that pre_swap is needed since the point where we block for fences moves around depending upon whether an atomic commit is blocking or non-blocking. For async commit all waiting needs to happen after drm_atomic_helper_swap_state() is called, but for synchronous commits we want to wait before we do anything that can’t be easily rolled back. That is before we call drm_atomic_helper_swap_state().
Returns zero if success or < 0 if dma_fence_wait() fails.
wait for vblank on crtcs
Parameters
Description
Helper to, after atomic commit, wait for vblanks on all effected crtcs (ie. before cleaning up old framebuffers using drm_atomic_helper_cleanup_planes()). It will only wait on crtcs where the framebuffers have actually changed to optimize for the legacy cursor and plane update use-case.
commit atomic update to hardware
Parameters
Description
This is the default implementation for the drm_mode_config_helper_funcs.atomic_commit_tail hook.
Note that the default ordering of how the various stages are called is to match the legacy modeset helper library closest. One peculiarity of that is that it doesn’t mesh well with runtime PM at all.
For drivers supporting runtime PM the recommended sequence is instead
drm_atomic_helper_commit_modeset_disables(dev, old_state);
drm_atomic_helper_commit_modeset_enables(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state,
DRM_PLANE_COMMIT_ACTIVE_ONLY);
for committing the atomic update to hardware. See the kerneldoc entries for these three functions for more details.
commit validated state object
Parameters
Description
This function commits a with drm_atomic_helper_check() pre-validated state object. This can still fail when e.g. the framebuffer reservation fails. This function implements nonblocking commits, using drm_atomic_helper_setup_commit() and related functions.
Committing the actual hardware state is done through the drm_mode_config_helper_funcs.atomic_commit_tail callback, or it’s default implementation drm_atomic_helper_commit_tail().
Return
Zero for success or -errno.
setup possibly nonblocking commit
Parameters
Description
This function prepares state to be used by the atomic helper’s support for nonblocking commits. Drivers using the nonblocking commit infrastructure should always call this function from their drm_mode_config_funcs.atomic_commit hook.
To be able to use this support drivers need to use a few more helper functions. drm_atomic_helper_wait_for_dependencies() must be called before actually committing the hardware state, and for nonblocking commits this call must be placed in the async worker. See also drm_atomic_helper_swap_state() and it’s stall parameter, for when a driver’s commit hooks look at the drm_crtc.state, drm_plane.state or drm_connector.state pointer directly.
Completion of the hardware commit step must be signalled using drm_atomic_helper_commit_hw_done(). After this step the driver is not allowed to read or change any permanent software or hardware modeset state. The only exception is state protected by other means than drm_modeset_lock locks. Only the free standing state with pointers to the old state structures can be inspected, e.g. to clean up old buffers using drm_atomic_helper_cleanup_planes().
At the very end, before cleaning up state drivers must call drm_atomic_helper_commit_cleanup_done().
This is all implemented by in drm_atomic_helper_commit(), giving drivers a complete and esay-to-use default implementation of the atomic_commit() hook.
The tracking of asynchronously executed and still pending commits is done using the core structure drm_crtc_commit.
By default there’s no need to clean up resources allocated by this function explicitly: drm_atomic_state_default_clear() will take care of that automatically.
Return
0 on success. -EBUSY when userspace schedules nonblocking commits too fast, -ENOMEM on allocation failures and -EINTR when a signal is pending.
wait for required preceeding commits
Parameters
Description
This function waits for all preceeding commits that touch the same CRTC as old_state to both be committed to the hardware (as signalled by drm_atomic_helper_commit_hw_done) and executed by the hardware (as signalled by calling drm_crtc_vblank_send_event() on the drm_crtc_state.event).
This is part of the atomic helper support for nonblocking commits, see drm_atomic_helper_setup_commit() for an overview.
setup possible nonblocking commit
Parameters
Description
This function is used to signal completion of the hardware commit step. After this step the driver is not allowed to read or change any permanent software or hardware modeset state. The only exception is state protected by other means than drm_modeset_lock locks.
Drivers should try to postpone any expensive or delayed cleanup work after this function is called.
This is part of the atomic helper support for nonblocking commits, see drm_atomic_helper_setup_commit() for an overview.
signal completion of commit
Parameters
Description
This signals completion of the atomic update old_state, including any cleanup work. If used, it must be called right before calling drm_atomic_state_put().
This is part of the atomic helper support for nonblocking commits, see drm_atomic_helper_setup_commit() for an overview.
prepare plane resources before commit
Parameters
Description
This function prepares plane state, specifically framebuffers, for the new configuration, by calling drm_plane_helper_funcs.prepare_fb. If any failure is encountered this function will call drm_plane_helper_funcs.cleanup_fb on any already successfully prepared framebuffer.
Return
0 on success, negative error code on failure.
commit plane state
Parameters
Description
This function commits the new plane state using the plane and atomic helper functions for planes and crtcs. It assumes that the atomic state has already been pushed into the relevant object state pointers, since this step can no longer fail.
It still requires the global state object old_state to know which planes and crtcs need to be updated though.
Note that this function does all plane updates across all CRTCs in one step. If the hardware can’t support this approach look at drm_atomic_helper_commit_planes_on_crtc() instead.
Plane parameters can be updated by applications while the associated CRTC is disabled. The DRM/KMS core will store the parameters in the plane state, which will be available to the driver when the CRTC is turned on. As a result most drivers don’t need to be immediately notified of plane updates for a disabled CRTC.
Unless otherwise needed, drivers are advised to set the ACTIVE_ONLY flag in flags in order not to receive plane update notifications related to a disabled CRTC. This avoids the need to manually ignore plane updates in driver code when the driver and/or hardware can’t or just don’t need to deal with updates on disabled CRTCs, for example when supporting runtime PM.
Drivers may set the NO_DISABLE_AFTER_MODESET flag in flags if the relevant display controllers require to disable a CRTC’s planes when the CRTC is disabled. This function would skip the drm_plane_helper_funcs.atomic_disable call for a plane if the CRTC of the old plane state needs a modesetting operation. Of course, the drivers need to disable the planes in their CRTC disable callbacks since no one else would do that.
The drm_atomic_helper_commit() default implementation doesn’t set the ACTIVE_ONLY flag to most closely match the behaviour of the legacy helpers. This should not be copied blindly by drivers.
commit plane state for a crtc
Parameters
Description
This function commits the new plane state using the plane and atomic helper functions for planes on the specific crtc. It assumes that the atomic state has already been pushed into the relevant object state pointers, since this step can no longer fail.
This function is useful when plane updates should be done crtc-by-crtc instead of one global step like drm_atomic_helper_commit_planes() does.
This function can only be savely used when planes are not allowed to move between different CRTCs because this function doesn’t handle inter-CRTC depencies. Callers need to ensure that either no such depencies exist, resolve them through ordering of commit calls or through some other means.
helper to disable CRTC’s planes
Parameters
Description
Disables all planes associated with the given CRTC. This can be used for instance in the CRTC helper atomic_disable callback to disable all planes.
If the atomic-parameter is set the function calls the CRTC’s atomic_begin hook before and atomic_flush hook after disabling the planes.
It is a bug to call this function without having implemented the drm_plane_helper_funcs.atomic_disable plane hook.
cleanup plane resources after commit
Parameters
Description
This function cleans up plane state, specifically framebuffers, from the old configuration. Hence the old configuration must be perserved in old_state to be able to call this function.
This function must also be called on the new state when the atomic update fails at any point after calling drm_atomic_helper_prepare_planes().
store atomic state into current sw state
Parameters
Description
This function stores the atomic state into the current state pointers in all driver objects. It should be called after all failing steps have been done and succeeded, but before the actual hardware state is committed.
For cleanup and error recovery the current state for all changed objects will be swaped into state.
With that sequence it fits perfectly into the plane prepare/cleanup sequence:
5. Call drm_atomic_helper_cleanup_planes() with state, which since step 3 contains the old state. Also do any other cleanup required with that state.
stall must be set when nonblocking commits for this driver directly access the drm_plane.state, drm_crtc.state or drm_connector.state pointer. With the current atomic helpers this is almost always the case, since the helpers don’t pass the right state structures to the callbacks.
Helper for primary plane update using atomic
Parameters
Description
Provides a default plane update handler using the atomic driver interface.
Return
Zero on success, error code on failure
Helper for primary plane disable using * atomic
Parameters
Description
Provides a default plane disable handler using the atomic driver interface.
Return
Zero on success, error code on failure
set a new config from userspace
Parameters
Description
Provides a default crtc set_config handler using the atomic driver interface.
NOTE
For backwards compatibility with old userspace this automatically resets the “link-status” property to GOOD, to force any link re-training. The SETCRTC ioctl does not define whether an update does need a full modeset or just a plane update, hence we’re allowed to do that. See also drm_mode_connector_set_link_status_property().
Return
Returns 0 on success, negative errno numbers on failure.
disable all currently active outputs
Parameters
Description
Loops through all connectors, finding those that aren’t turned off and then turns them off by setting their DPMS mode to OFF and deactivating the CRTC that they are connected to.
This is used for example in suspend/resume to disable all currently active functions when suspending. If you just want to shut down everything at e.g. driver unload, look at drm_atomic_helper_shutdown().
Note that if callers haven’t already acquired all modeset locks this might return -EDEADLK, which must be handled by calling drm_modeset_backoff().
Return
0 on success or a negative error code on failure.
See also: drm_atomic_helper_suspend(), drm_atomic_helper_resume() and drm_atomic_helper_shutdown().
shutdown all CRTC
Parameters
Description
This shuts down all CRTC, which is useful for driver unloading. Shutdown on suspend should instead be handled with drm_atomic_helper_suspend(), since that also takes a snapshot of the modeset state to be restored on resume.
This is just a convenience wrapper around drm_atomic_helper_disable_all(), and it is the atomic version of drm_crtc_force_disable_all().
subsystem-level suspend helper
Parameters
Description
Duplicates the current atomic state, disables all active outputs and then returns a pointer to the original atomic state to the caller. Drivers can pass this pointer to the drm_atomic_helper_resume() helper upon resume to restore the output configuration that was active at the time the system entered suspend.
Note that it is potentially unsafe to use this. The atomic state object returned by this function is assumed to be persistent. Drivers must ensure that this holds true. Before calling this function, drivers must make sure to suspend fbdev emulation so that nothing can be using the device.
Return
A pointer to a copy of the state before suspend on success or an ERR_PTR()- encoded error code on failure. Drivers should store the returned atomic state object and pass it to the drm_atomic_helper_resume() helper upon resume.
See also: drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(), drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
commit duplicated state
Parameters
Description
The state returned by drm_atomic_helper_duplicate_state() and drm_atomic_helper_suspend() is partially invalid, and needs to be fixed up before commit.
Return
0 on success or a negative error code on failure.
See also: drm_atomic_helper_suspend()
subsystem-level resume helper
Parameters
Description
Calls drm_mode_config_reset() to synchronize hardware and software states, grabs all modeset locks and commits the atomic state object. This can be used in conjunction with the drm_atomic_helper_suspend() helper to implement suspend/resume for drivers that support atomic mode-setting.
Return
0 on success or a negative error code on failure.
See also: drm_atomic_helper_suspend()
helper for crtc properties
Parameters
Description
Provides a default crtc set_property handler using the atomic driver interface.
Return
Zero on success, error code on failure
helper for plane properties
Parameters
Description
Provides a default plane set_property handler using the atomic driver interface.
Return
Zero on success, error code on failure
helper for connector properties
Parameters
Description
Provides a default connector set_property handler using the atomic driver interface.
Return
Zero on success, error code on failure
execute a legacy page flip
Parameters
Description
Provides a default drm_crtc_funcs.page_flip implementation using the atomic driver interface.
Return
Returns 0 on success, negative errno numbers on failure.
See also: drm_atomic_helper_page_flip_target()
do page flip on target vblank period.
Parameters
Description
Provides a default drm_crtc_funcs.page_flip_target implementation. Similar to drm_atomic_helper_page_flip() with extra parameter to specify target vblank period to flip.
Return
Returns 0 on success, negative errno numbers on failure.
connector dpms helper implementation
Parameters
Description
This is the main helper function provided by the atomic helper framework for implementing the legacy DPMS connector interface. It computes the new desired drm_crtc_state.active state for the corresponding CRTC (if the connector is enabled) and updates it.
Return
Returns 0 on success, negative errno numbers on failure.
Helper for drm_connector_helper_funcs.best_encoder callback
Parameters
Description
This is a drm_connector_helper_funcs.best_encoder callback helper for connectors that support exactly 1 encoder, statically determined at driver init time.
default drm_crtc_funcs.reset hook for CRTCs
Parameters
Description
Resets the atomic state for crtc by freeing the state pointer (which might be NULL, e.g. at driver load time) and allocating a new empty state object.
copy atomic CRTC state
Parameters
Description
Copies atomic state from a CRTC’s current state and resets inferred values. This is useful for drivers that subclass the CRTC state.
default state duplicate hook
Parameters
Description
Default CRTC state duplicate hook for drivers which don’t have their own subclassed CRTC state structure.
release CRTC state
Parameters
Description
Releases all resources stored in the CRTC state without actually freeing the memory of the CRTC state. This is useful for drivers that subclass the CRTC state.
default state destroy hook
Parameters
Description
Default CRTC state destroy hook for drivers which don’t have their own subclassed CRTC state structure.
default drm_plane_funcs.reset hook for planes
Parameters
Description
Resets the atomic state for plane by freeing the state pointer (which might be NULL, e.g. at driver load time) and allocating a new empty state object.
copy atomic plane state
Parameters
Description
Copies atomic state from a plane’s current state. This is useful for drivers that subclass the plane state.
default state duplicate hook
Parameters
Description
Default plane state duplicate hook for drivers which don’t have their own subclassed plane state structure.
release plane state
Parameters
Description
Releases all resources stored in the plane state without actually freeing the memory of the plane state. This is useful for drivers that subclass the plane state.
default state destroy hook
Parameters
Description
Default plane state destroy hook for drivers which don’t have their own subclassed plane state structure.
reset state on connector
Parameters
Description
Initializes the newly allocated conn_state and assigns it to the drm_conector->state pointer of connector, usually required when initializing the drivers or when called from the drm_connector_funcs.reset hook.
This is useful for drivers that subclass the connector state.
default drm_connector_funcs.reset hook for connectors
Parameters
Description
Resets the atomic state for connector by freeing the state pointer (which might be NULL, e.g. at driver load time) and allocating a new empty state object.
copy atomic connector state
Parameters
Description
Copies atomic state from a connector’s current state. This is useful for drivers that subclass the connector state.
default state duplicate hook
Parameters
Description
Default connector state duplicate hook for drivers which don’t have their own subclassed connector state structure.
duplicate an atomic state object
Parameters
Description
Makes a copy of the current atomic state by looping over all objects and duplicating their respective states. This is used for example by suspend/ resume support code to save the state prior to suspend such that it can be restored upon resume.
Note that this treats atomic state as persistent between save and restore. Drivers must make sure that this is possible and won’t result in confusion or erroneous behaviour.
Note that if callers haven’t already acquired all modeset locks this might return -EDEADLK, which must be handled by calling drm_modeset_backoff().
Return
A pointer to the copy of the atomic state object on success or an ERR_PTR()-encoded error code on failure.
See also: drm_atomic_helper_suspend(), drm_atomic_helper_resume()
release connector state
Parameters
Description
Releases all resources stored in the connector state without actually freeing the memory of the connector state. This is useful for drivers that subclass the connector state.
default state destroy hook
Parameters
Description
Default connector state destroy hook for drivers which don’t have their own subclassed connector state structure.
set the legacy gamma correction table
Parameters
Description
Implements support for legacy gamma correction table for drivers that support color management through the DEGAMMA_LUT/GAMMA_LUT properties.
The CRTC modeset helper library provides a default set_config implementation in drm_crtc_helper_set_config(). Plus a few other convenience functions using the same callbacks which drivers can use to e.g. restore the modeset configuration on resume with drm_helper_resume_force_mode().
Note that this helper library doesn’t track the current power state of CRTCs and encoders. It can call callbacks like drm_encoder_helper_funcs.dpms even though the hardware is already in the desired state. This deficiency has been fixed in the atomic helpers.
The driver callbacks are mostly compatible with the atomic modeset helpers, except for the handling of the primary plane: Atomic helpers require that the primary plane is implemented as a real standalone plane and not directly tied to the CRTC state. For easier transition this library provides functions to implement the old semantics required by the CRTC helpers using the new plane and atomic helper callbacks.
Drivers are strongly urged to convert to the atomic helpers (by way of first converting to the plane helpers). New drivers must not use these functions but need to implement the atomic interface instead, potentially using the atomic helpers for that.
These legacy modeset helpers use the same function table structures as all other modesetting helpers. See the documentation for struct drm_crtc_helper_funcs, struct drm_encoder_helper_funcs and struct drm_connector_helper_funcs.
check if a given encoder is in use
Parameters
Description
Checks whether encoder is with the current mode setting output configuration in use by any connector. This doesn’t mean that it is actually enabled since the DPMS state is tracked separately.
Return
True if encoder is used, false otherwise.
Parameters
Description
Checks whether crtc is with the current mode setting output configuration in use by any connector. This doesn’t mean that it is actually enabled since the DPMS state is tracked separately.
Return
True if crtc is used, false otherwise.
disable unused objects
Parameters
Description
This function walks through the entire mode setting configuration of dev. It will remove any CRTC links of unused encoders and encoder links of disconnected connectors. Then it will disable all unused encoders and CRTCs either by calling their disable callback if available or by calling their dpms callback with DRM_MODE_DPMS_OFF.
NOTE
This function is part of the legacy modeset helper library and will cause major confusion with atomic drivers. This is because atomic helpers guarantee to never call ->:c:func:disable() hooks on a disabled function, or ->:c:func:enable() hooks on an enabled functions. drm_helper_disable_unused_functions() on the other hand throws such guarantees into the wind and calls disable hooks unconditionally on unused functions.
internal helper to set a mode
Parameters
Description
Try to set mode on crtc. Give crtc and its associated connectors a chance to fixup or reject the mode prior to trying to set it. This is an internal helper that drivers could e.g. use to update properties that require the entire output pipe to be disabled and re-enabled in a new configuration. For example for changing whether audio is enabled on a hdmi link or for changing panel fitter or dither attributes. It is also called by the drm_crtc_helper_set_config() helper function to drive the mode setting sequence.
Return
True if the mode was set successfully, false otherwise.
set a new config from userspace
Parameters
Description
The drm_crtc_helper_set_config() helper function implements the of drm_crtc_funcs.set_config callback for drivers using the legacy CRTC helpers.
It first tries to locate the best encoder for each connector by calling the connector drm_connector_helper_funcs.best_encoder helper operation.
After locating the appropriate encoders, the helper function will call the mode_fixup encoder and CRTC helper operations to adjust the requested mode, or reject it completely in which case an error will be returned to the application. If the new configuration after mode adjustment is identical to the current configuration the helper function will return without performing any other operation.
If the adjusted mode is identical to the current mode but changes to the frame buffer need to be applied, the drm_crtc_helper_set_config() function will call the CRTC drm_crtc_helper_funcs.mode_set_base helper operation.
If the adjusted mode differs from the current mode, or if the ->:c:func:mode_set_base() helper operation is not provided, the helper function performs a full mode set sequence by calling the ->:c:func:prepare(), ->:c:func:mode_set() and ->:c:func:commit() CRTC and encoder helper operations, in that order. Alternatively it can also use the dpms and disable helper operations. For details see struct drm_crtc_helper_funcs and struct drm_encoder_helper_funcs.
This function is deprecated. New drivers must implement atomic modeset support, for which this function is unsuitable. Instead drivers should use drm_atomic_helper_set_config().
Return
Returns 0 on success, negative errno numbers on failure.
connector dpms helper implementation
Parameters
Description
The drm_helper_connector_dpms() helper function implements the drm_connector_funcs.dpms callback for drivers using the legacy CRTC helpers.
This is the main helper function provided by the CRTC helper framework for implementing the DPMS connector attribute. It computes the new desired DPMS state for all encoders and CRTCs in the output mesh and calls the drm_crtc_helper_funcs.dpms and drm_encoder_helper_funcs.dpms callbacks provided by the driver.
This function is deprecated. New drivers must implement atomic modeset support, for which this function is unsuitable. Instead drivers should use drm_atomic_helper_connector_dpms().
Return
Always returns 0.
force-restore mode setting configuration
Parameters
Description
Drivers which use the mode setting helpers can use this function to force-restore the mode setting configuration e.g. on resume or when something else might have trampled over the hw state (like some overzealous old BIOSen tended to do).
This helper doesn’t provide a error return value since restoring the old config should never fail due to resource allocation issues since the driver has successfully set the restored configuration already. Hence this should boil down to the equivalent of a few dpms on calls, which also don’t provide an error code.
Drivers where simply restoring an old configuration again might fail (e.g. due to slight differences in allocating shared resources when the configuration is restored in a different order than when userspace set it up) need to use their own restore logic.
This function is deprecated. New drivers should implement atomic mode- setting and use the atomic suspend/resume helpers.
See also: drm_atomic_helper_suspend(), drm_atomic_helper_resume()
mode_set implementation for atomic plane helpers
Parameters
Description
This function implements a callback useable as the ->mode_set callback required by the CRTC helpers. Besides the atomic plane helper functions for the primary plane the driver must also provide the ->mode_set_nofb callback to set up the CRTC.
This is a transitional helper useful for converting drivers to the atomic interfaces.
mode_set_base implementation for atomic plane helpers
Parameters
Description
This function implements a callback useable as the ->mode_set_base used required by the CRTC helpers. The driver must provide the atomic plane helper functions for the primary plane.
This is a transitional helper useful for converting drivers to the atomic interfaces.
This helper library provides helpers for drivers for simple display hardware.
drm_simple_display_pipe_init() initializes a simple display pipeline which has only one full-screen scanout buffer feeding one output. The pipeline is represented by struct drm_simple_display_pipe and binds together drm_plane, drm_crtc and drm_encoder structures into one fixed entity. Some flexibility for code reuse is provided through a separately allocated drm_connector object and supporting optional drm_bridge encoder drivers.
helper operations for a simple display pipeline
Definition
struct drm_simple_display_pipe_funcs {
void (* enable) (struct drm_simple_display_pipe *pipe,struct drm_crtc_state *crtc_state);
void (* disable) (struct drm_simple_display_pipe *pipe);
int (* check) (struct drm_simple_display_pipe *pipe,struct drm_plane_state *plane_state,struct drm_crtc_state *crtc_state);
void (* update) (struct drm_simple_display_pipe *pipe,struct drm_plane_state *old_plane_state);
int (* prepare_fb) (struct drm_simple_display_pipe *pipe,struct drm_plane_state *plane_state);
void (* cleanup_fb) (struct drm_simple_display_pipe *pipe,struct drm_plane_state *plane_state);
};
Members
This function is called in the check phase of an atomic update, specifically when the underlying plane is checked. The simple display pipeline helpers already check that the plane is not scaled, fills the entire visible area and is always enabled when the crtc is also enabled. This hook is optional.
RETURNS:
0 on success, -EINVAL if the state or the transition can’t be supported, -ENOMEM on memory allocation failure and -EDEADLK if an attempt to obtain another state object ran into a drm_modeset_lock deadlock.
This function is called when the underlying plane state is updated. This hook is optional.
This is the function drivers should submit the drm_pending_vblank_event from. Using either drm_crtc_arm_vblank_event(), when the driver supports vblank interrupt handling, or drm_crtc_send_vblank_event() directly in case the hardware lacks vblank support entirely.
simple display pipeline
Definition
struct drm_simple_display_pipe {
struct drm_crtc crtc;
struct drm_plane plane;
struct drm_encoder encoder;
struct drm_connector * connector;
const struct drm_simple_display_pipe_funcs * funcs;
};
Members
Description
Simple display pipeline with plane, crtc and encoder collapsed into one entity. It should be initialized by calling drm_simple_display_pipe_init().
Attach a bridge to the display pipe
Parameters
Description
Makes it possible to still use the drm_simple_display_pipe helpers when a DRM bridge has to be used.
Note that you probably want to initialize the pipe by passing a NULL connector to drm_simple_display_pipe_init().
Return
Zero on success, negative error code on failure.
Initialize a simple display pipeline
Parameters
Description
Sets up a display pipeline which consist of a really simple plane-crtc-encoder pipe.
If a connector is supplied, the pipe will be coupled with the provided connector. You may supply a NULL connector when using drm bridges, that handle connectors themselves (see drm_simple_display_pipe_attach_bridge()).
Teardown of a simple display pipe is all handled automatically by the drm core through calling drm_mode_config_cleanup(). Drivers afterwards need to release the memory for the structure themselves.
Return
Zero on success, negative error code on failure.
The fb helper functions are useful to provide an fbdev on top of a drm kernel mode setting driver. They can be used mostly independently from the crtc helper functions used by many drivers to implement the kernel mode setting interfaces.
Initialization is done as a four-step process with drm_fb_helper_prepare(), drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and drm_fb_helper_initial_config(). Drivers with fancier requirements than the default behaviour can override the third step with their own code. Teardown is done with drm_fb_helper_fini() after the fbdev device is unregisters using drm_fb_helper_unregister_fbi().
At runtime drivers should restore the fbdev console by calling drm_fb_helper_restore_fbdev_mode_unlocked() from their drm_driver.lastclose callback. They should also notify the fb helper code from updates to the output configuration by calling drm_fb_helper_hotplug_event(). For easier integration with the output polling code in drm_crtc_helper.c the modeset code provides a drm_mode_config_funcs.output_poll_changed callback.
All other functions exported by the fb helper library can be used to implement the fbdev driver interface by the driver.
It is possible, though perhaps somewhat tricky, to implement race-free hotplug detection using the fbdev helpers. The drm_fb_helper_prepare() helper must be called first to initialize the minimum required to make hotplug detection work. Drivers also need to make sure to properly set up the drm_mode_config.funcs member. After calling drm_kms_helper_poll_init() it is safe to enable interrupts and start processing hotplug events. At the same time, drivers should initialize all modeset objects such as CRTCs, encoders and connectors. To finish up the fbdev helper initialization, the drm_fb_helper_init() function is called. To probe for all attached displays and set up an initial configuration using the detected hardware, drivers should call drm_fb_helper_single_add_all_connectors() followed by drm_fb_helper_initial_config().
If drm_framebuffer_funcs.dirty is set, the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions will accumulate changes and schedule drm_fb_helper.dirty_work to run right away. This worker then calls the dirty() function ensuring that it will always run in process context since the fb_*() function could be running in atomic context. If drm_fb_helper_deferred_io() is used as the deferred_io callback it will also schedule dirty_work with the damage collected from the mmap page writes.
describes fbdev size and scanout surface size
Definition
struct drm_fb_helper_surface_size {
u32 fb_width;
u32 fb_height;
u32 surface_width;
u32 surface_height;
u32 surface_bpp;
u32 surface_depth;
};
Members
Description
Note that the scanout surface width/height may be larger than the fbdev width/height. In case of multiple displays, the scanout surface is sized according to the largest width/height (so it is large enough for all CRTCs to scanout). But the fbdev width/height is sized to the minimum width/ height of all the displays. This ensures that fbcon fits on the smallest of the attached displays.
So what is passed to drm_fb_helper_fill_var() should be fb_width/fb_height, rather than the surface size.
driver callbacks for the fbdev emulation library
Definition
struct drm_fb_helper_funcs {
void (* gamma_set) (struct drm_crtc *crtc, u16 red, u16 green,u16 blue, int regno);
void (* gamma_get) (struct drm_crtc *crtc, u16 *red, u16 *green,u16 *blue, int regno);
int (* fb_probe) (struct drm_fb_helper *helper,struct drm_fb_helper_surface_size *sizes);
bool (* initial_config) (struct drm_fb_helper *fb_helper,struct drm_fb_helper_crtc **crtcs,struct drm_display_mode **modes,struct drm_fb_offset *offsets,bool *enabled, int width, int height);
};
Members
Set the given gamma LUT register on the given CRTC.
This callback is optional.
FIXME:
This callback is functionally redundant with the core gamma table support and simply exists because the fbdev hasn’t yet been refactored to use the core gamma table interfaces.
Read the given gamma LUT register on the given CRTC, used to save the current LUT when force-restoring the fbdev for e.g. kdbg.
This callback is optional.
FIXME:
This callback is functionally redundant with the core gamma table support and simply exists because the fbdev hasn’t yet been refactored to use the core gamma table interfaces.
Driver callback to allocate and initialize the fbdev info structure. Furthermore it also needs to allocate the DRM framebuffer used to back the fbdev.
This callback is mandatory.
RETURNS:
The driver should return 0 on success and a negative error code on failure.
Driver callback to setup an initial fbdev display configuration. Drivers can use this callback to tell the fbdev emulation what the preferred initial configuration is. This is useful to implement smooth booting where the fbdev (and subsequently all userspace) never changes the mode, but always inherits the existing configuration.
This callback is optional.
RETURNS:
The driver should return true if a suitable initial configuration has been filled out and false when the fbdev helper should fall back to the default probing logic.
Description
Driver callbacks used by the fbdev emulation helper library.
main structure to emulate fbdev on top of KMS
Definition
struct drm_fb_helper {
struct drm_framebuffer * fb;
struct drm_device * dev;
int crtc_count;
struct drm_fb_helper_crtc * crtc_info;
int connector_count;
int connector_info_alloc_count;
struct drm_fb_helper_connector ** connector_info;
const struct drm_fb_helper_funcs * funcs;
struct fb_info * fbdev;
u32 pseudo_palette[17];
struct drm_clip_rect dirty_clip;
spinlock_t dirty_lock;
struct work_struct dirty_work;
struct work_struct resume_work;
struct list_head kernel_fb_list;
bool delayed_hotplug;
};
Members
Description
This is the main structure used by the fbdev helpers. Drivers supporting fbdev emulation should embedded this into their overall driver structure. Drivers must also fill out a struct drm_fb_helper_funcs with a few operations.
helper define for drm drivers
Parameters
Description
Helper define to register default implementations of drm_fb_helper functions. To be used in struct fb_ops of drm drivers.
add all connectors to fbdev emulation helper
Parameters
Description
This functions adds all the available connectors for use with the given fb_helper. This is a separate step to allow drivers to freely assign connectors to the fbdev, e.g. if some are reserved for special purposes or not adequate to be used for the fbcon.
This function is protected against concurrent connector hotadds/removals using drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
implementation for fb_ops.fb_debug_enter
Parameters
implementation for fb_ops.fb_debug_leave
Parameters
restore fbdev configuration
Parameters
Description
This should be called from driver’s drm drm_driver.lastclose callback when implementing an fbcon on top of kms using this helper. This ensures that the user isn’t greeted with a black screen when e.g. X dies.
Return
Zero if everything went ok, negative error code otherwise.
implementation for fb_ops.fb_blank
Parameters
setup a drm_fb_helper structure
Parameters
Description
Sets up the bare minimum to make the framebuffer helper usable. This is useful to implement race-free initialization of the polling helpers.
initialize a struct drm_fb_helper
Parameters
Description
This allocates the structures for the fbdev helper with the given limits. Note that this won’t yet touch the hardware (through the driver interfaces) nor register the fbdev. This is only done in drm_fb_helper_initial_config() to allow driver writes more control over the exact init sequence.
Drivers must call drm_fb_helper_prepare() before calling this function.
Return
Zero if everything went ok, nonzero otherwise.
allocate fb_info and some of its members
Parameters
Description
A helper to alloc fb_info and the members cmap and apertures. Called by the driver within the fb_probe fb_helper callback function. Drivers do not need to release the allocated fb_info structure themselves, this is automatically done when calling drm_fb_helper_fini().
Return
fb_info pointer if things went okay, pointer containing error code otherwise
unregister fb_info framebuffer device
Parameters
Description
A wrapper around unregister_framebuffer, to release the fb_info framebuffer device. This must be called before releasing all resources for fb_helper by calling drm_fb_helper_fini().
finialize a struct drm_fb_helper
Parameters
Description
This cleans up all remaining resources associated with fb_helper. Must be called after drm_fb_helper_unlink_fbi() was called.
wrapper around unlink_framebuffer
Parameters
Description
A wrapper around unlink_framebuffer implemented by fbdev core
fbdev deferred_io callback function
Parameters
Description
This function is used as the fb_deferred_io.deferred_io callback function for flushing the fbdev mmap writes.
wrapper around fb_sys_read
Parameters
Description
A wrapper around fb_sys_read implemented by fbdev core
wrapper around fb_sys_write
Parameters
Description
A wrapper around fb_sys_write implemented by fbdev core
wrapper around sys_fillrect
Parameters
Description
A wrapper around sys_fillrect implemented by fbdev core
wrapper around sys_copyarea
Parameters
Description
A wrapper around sys_copyarea implemented by fbdev core
wrapper around sys_imageblit
Parameters
Description
A wrapper around sys_imageblit implemented by fbdev core
wrapper around cfb_fillrect
Parameters
Description
A wrapper around cfb_imageblit implemented by fbdev core
wrapper around cfb_copyarea
Parameters
Description
A wrapper around cfb_copyarea implemented by fbdev core
wrapper around cfb_imageblit
Parameters
Description
A wrapper around cfb_imageblit implemented by fbdev core
wrapper around fb_set_suspend
Parameters
Description
A wrapper around fb_set_suspend implemented by fbdev core. Use drm_fb_helper_set_suspend_unlocked() if you don’t need to take the lock yourself
wrapper around fb_set_suspend that also takes the console lock
Parameters
Description
A wrapper around fb_set_suspend() that takes the console lock. If the lock isn’t available on resume, a worker is tasked with waiting for the lock to become available. The console lock can be pretty contented on resume due to all the printk activity.
This function can be called multiple times with the same state since fb_info.state is checked to see if fbdev is running or not before locking.
Use drm_fb_helper_set_suspend() if you need to take the lock yourself.
implementation for fb_ops.fb_setcmap
Parameters
legacy ioctl implementation
Parameters
Description
A helper to implement the standard fbdev ioctl. Only FBIO_WAITFORVSYNC is implemented for now.
implementation for fb_ops.fb_check_var
Parameters
implementation for fb_ops.fb_set_par
Parameters
Description
This will let fbcon do the mode init and is called at initialization time by the fbdev core when registering the driver, and later on through the hotplug callback.
implementation for fb_ops.fb_pan_display
Parameters
initializes fixed fbdev information
Parameters
Description
Helper to fill in the fixed fbdev information useful for a non-accelerated fbdev emulations. Drivers which support acceleration methods which impose additional constraints need to set up their own limits.
Drivers should call this (or their equivalent setup code) from their drm_fb_helper_funcs.fb_probe callback.
initalizes variable fbdev information
Parameters
Description
Sets up the variable fbdev metainformation from the given fb helper instance and the drm framebuffer allocated in drm_fb_helper.fb.
Drivers should call this (or their equivalent setup code) from their drm_fb_helper_funcs.fb_probe callback after having allocated the fbdev backing storage framebuffer.
setup a sane initial connector configuration
Parameters
Description
Scans the CRTCs and connectors and tries to put together an initial setup. At the moment, this is a cloned configuration across all heads with a new framebuffer object as the backing store.
Note that this also registers the fbdev and so allows userspace to call into the driver through the fbdev interfaces.
This function will call down into the drm_fb_helper_funcs.fb_probe callback to let the driver allocate and initialize the fbdev info structure and the drm framebuffer used to back the fbdev. drm_fb_helper_fill_var() and drm_fb_helper_fill_fix() are provided as helpers to setup simple default values for the fbdev info structure.
HANG DEBUGGING:
When you have fbcon support built-in or already loaded, this function will do a full modeset to setup the fbdev console. Due to locking misdesign in the VT/fbdev subsystem that entire modeset sequence has to be done while holding console_lock. Until console_unlock is called no dmesg lines will be sent out to consoles, not even serial console. This means when your driver crashes, you will see absolutely nothing else but a system stuck in this function, with no further output. Any kind of printk() you place within your own driver or in the drm core modeset code will also never show up.
Standard debug practice is to run the fbcon setup without taking the console_lock as a hack, to be able to see backtraces and crashes on the serial line. This can be done by setting the fb.lockless_register_fb=1 kernel cmdline option.
The other option is to just disable fbdev emulation since very likely the first modeset from userspace will crash in the same way, and is even easier to debug. This can be done by setting the drm_kms_helper.fbdev_emulation=0 kernel cmdline option.
Return
Zero if everything went ok, nonzero otherwise.
respond to a hotplug notification by probing all the outputs attached to the fb
Parameters
Description
Scan the connectors attached to the fb_helper and try to put together a setup after notification of a change in output configuration.
Called at runtime, takes the mode config locks to be able to check/change the modeset configuration. Must be run from process context (which usually means either the output polling work or a work item launched from the driver’s hotplug interrupt).
Note that drivers may call this even before calling drm_fb_helper_initial_config but only after drm_fb_helper_init. This allows for a race-free fbcon setup and will make sure that the fbdev emulation will not miss any hotplug events.
Return
0 on success and a non-zero error code otherwise.
Provides helper functions for creating a cma (contiguous memory allocator) backed framebuffer.
drm_fb_cma_create() is used in the drm_mode_config_funcs.fb_create callback function to create a cma backed framebuffer.
An fbdev framebuffer backed by cma is also available by calling drm_fbdev_cma_init(). drm_fbdev_cma_fini() tears it down. If the drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will be set up automatically. drm_framebuffer_funcs.dirty is called by drm_fb_helper_deferred_io() in process context (struct delayed_work).
Example fbdev deferred io code:
static int driver_fb_dirty(struct drm_framebuffer *fb,
struct drm_file *file_priv,
unsigned flags, unsigned color,
struct drm_clip_rect *clips,
unsigned num_clips)
{
struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
... push changes ...
return 0;
}
static struct drm_framebuffer_funcs driver_fb_funcs = {
.destroy = drm_fb_cma_destroy,
.create_handle = drm_fb_cma_create_handle,
.dirty = driver_fb_dirty,
};
Initialize:
fbdev = drm_fbdev_cma_init_with_funcs(dev, 16,
dev->mode_config.num_crtc,
dev->mode_config.num_connector,
:c:type:`driver_fb_funcs`);
helper function for the drm_mode_config_funcs.fb_create callback
Parameters
Description
This can be used to set drm_framebuffer_funcs for drivers that need the drm_framebuffer_funcs.dirty callback. Use drm_fb_cma_create() if you don’t need to change drm_framebuffer_funcs.
drm_mode_config_funcs.fb_create callback function
Parameters
Description
If your hardware has special alignment or pitch requirements these should be checked before calling this function. Use drm_fb_cma_create_with_funcs() if you need to set drm_framebuffer_funcs.dirty.
Get CMA GEM object for framebuffer
Parameters
Description
Return the CMA GEM object for given framebuffer.
This function will usually be called from the CRTC callback functions.
Prepare CMA framebuffer
Parameters
Description
This should be set as the struct drm_plane_helper_funcs.prepare_fb hook.
This function checks if the plane FB has an dma-buf attached, extracts the exclusive fence and attaches it to plane state for the atomic helper to wait on.
There is no need for cleanup_fb for CMA based framebuffer drivers.
Helper to list CMA framebuffer objects in debugfs.
Parameters
Allocate and initializes a drm_fbdev_cma struct
Parameters
Description
Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
Allocate and initializes a drm_fbdev_cma struct
Parameters
Description
Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
Free drm_fbdev_cma struct
Parameters
Restores initial framebuffer mode
Parameters
Description
This function is usually called from the drm_driver.lastclose callback.
Poll for hotpulug events
Parameters
Description
This function is usually called from the drm_mode_config.output_poll_changed callback.
wrapper around drm_fb_helper_set_suspend
Parameters
Description
Calls drm_fb_helper_set_suspend, which is a wrapper around fb_set_suspend implemented by fbdev core.
wrapper around drm_fb_helper_set_suspend_unlocked
Parameters
Description
Calls drm_fb_helper_set_suspend, which is a wrapper around fb_set_suspend implemented by fbdev core.
struct drm_bridge represents a device that hangs on to an encoder. These are handy when a regular drm_encoder entity isn’t enough to represent the entire encoder chain.
A bridge is always attached to a single drm_encoder at a time, but can be either connected to it directly, or through an intermediate bridge:
encoder ---> bridge B ---> bridge A
Here, the output of the encoder feeds to bridge B, and that furthers feeds to bridge A.
The driver using the bridge is responsible to make the associations between the encoder and bridges. Once these links are made, the bridges will participate along with encoder functions to perform mode_set/enable/disable through the ops provided in drm_bridge_funcs.
drm_bridge, like drm_panel, aren’t drm_mode_object entities like planes, CRTCs, encoders or connectors and hence are not visible to userspace. They just provide additional hooks to get the desired output at the end of the encoder chain.
Bridges can also be chained up using the drm_bridge.next pointer.
Both legacy CRTC helpers and the new atomic modeset helpers support bridges.
The drm_bridge_funcs ops are populated by the bridge driver. The DRM internals (atomic and CRTC helpers) use the helpers defined in drm_bridge.c These helpers call a specific drm_bridge_funcs op for all the bridges during encoder configuration.
For detailed specification of the bridge callbacks see drm_bridge_funcs.
drm_bridge control functions
Definition
struct drm_bridge_funcs {
int (* attach) (struct drm_bridge *bridge);
void (* detach) (struct drm_bridge *bridge);
bool (* mode_fixup) (struct drm_bridge *bridge,const struct drm_display_mode *mode,struct drm_display_mode *adjusted_mode);
void (* disable) (struct drm_bridge *bridge);
void (* post_disable) (struct drm_bridge *bridge);
void (* mode_set) (struct drm_bridge *bridge,struct drm_display_mode *mode,struct drm_display_mode *adjusted_mode);
void (* pre_enable) (struct drm_bridge *bridge);
void (* enable) (struct drm_bridge *bridge);
};
Members
This callback is invoked whenever our bridge is being attached to a drm_encoder.
The attach callback is optional.
RETURNS:
Zero on success, error code on failure.
This callback is invoked whenever our bridge is being detached from a drm_encoder.
The detach callback is optional.
This callback is used to validate and adjust a mode. The paramater mode is the display mode that should be fed to the next element in the display chain, either the final drm_connector or the next drm_bridge. The parameter adjusted_mode is the input mode the bridge requires. It can be modified by this callback and does not need to match mode.
This is the only hook that allows a bridge to reject a modeset. If this function passes all other callbacks must succeed for this configuration.
The mode_fixup callback is optional.
NOTE:
This function is called in the check phase of atomic modesets, which can be aborted for any reason (including on userspace’s request to just check whether a configuration would be possible). Drivers MUST NOT touch any persistent state (hardware or software) or data structures except the passed in state parameter.
RETURNS:
True if an acceptable configuration is possible, false if the modeset operation should be rejected.
This callback should disable the bridge. It is called right before the preceding element in the display pipe is disabled. If the preceding element is a bridge this means it’s called before that bridge’s disable vfunc. If the preceding element is a drm_encoder it’s called right before the drm_encoder_helper_funcs.disable, drm_encoder_helper_funcs.prepare or drm_encoder_helper_funcs.dpms hook.
The bridge can assume that the display pipe (i.e. clocks and timing signals) feeding it is still running when this callback is called.
The disable callback is optional.
This callback should disable the bridge. It is called right after the preceding element in the display pipe is disabled. If the preceding element is a bridge this means it’s called after that bridge’s post_disable function. If the preceding element is a drm_encoder it’s called right after the encoder’s drm_encoder_helper_funcs.disable, drm_encoder_helper_funcs.prepare or drm_encoder_helper_funcs.dpms hook.
The bridge must assume that the display pipe (i.e. clocks and timing singals) feeding it is no longer running when this callback is called.
The post_disable callback is optional.
This callback should enable the bridge. It is called right before the preceding element in the display pipe is enabled. If the preceding element is a bridge this means it’s called before that bridge’s pre_enable function. If the preceding element is a drm_encoder it’s called right before the encoder’s drm_encoder_helper_funcs.enable, drm_encoder_helper_funcs.commit or drm_encoder_helper_funcs.dpms hook.
The display pipe (i.e. clocks and timing signals) feeding this bridge will not yet be running when this callback is called. The bridge must not enable the display link feeding the next bridge in the chain (if there is one) when this callback is called.
The pre_enable callback is optional.
This callback should enable the bridge. It is called right after the preceding element in the display pipe is enabled. If the preceding element is a bridge this means it’s called after that bridge’s enable function. If the preceding element is a drm_encoder it’s called right after the encoder’s drm_encoder_helper_funcs.enable, drm_encoder_helper_funcs.commit or drm_encoder_helper_funcs.dpms hook.
The bridge can assume that the display pipe (i.e. clocks and timing signals) feeding it is running when this callback is called. This callback must enable the display link feeding the next bridge in the chain if there is one.
The enable callback is optional.
central DRM bridge control structure
Definition
struct drm_bridge {
struct drm_device * dev;
struct drm_encoder * encoder;
struct drm_bridge * next;
#ifdef CONFIG_OF
struct device_node * of_node;
#endif
struct list_head list;
const struct drm_bridge_funcs * funcs;
void * driver_private;
};
Members
add the given bridge to the global bridge list
Parameters
Return
Unconditionally returns Zero.
remove the given bridge from the global bridge list
Parameters
attach the bridge to an encoder’s chain
Parameters
Description
Called by a kms driver to link the bridge to an encoder’s chain. The previous argument specifies the previous bridge in the chain. If NULL, the bridge is linked directly at the encoder’s output. Otherwise it is linked at the previous bridge’s output.
If non-NULL the previous bridge must be already attached by a call to this function.
Return
Zero on success, error code on failure
fixup proposed mode for all bridges in the encoder chain
Parameters
Description
Calls drm_bridge_funcs.mode_fixup for all the bridges in the encoder chain, starting from the first bridge to the last.
Note
the bridge passed should be the one closest to the encoder
Return
true on success, false on failure
disables all bridges in the encoder chain
Parameters
Description
Calls drm_bridge_funcs.disable op for all the bridges in the encoder chain, starting from the last bridge to the first. These are called before calling the encoder’s prepare op.
Note
the bridge passed should be the one closest to the encoder
cleans up after disabling all bridges in the encoder chain
Parameters
Description
Calls drm_bridge_funcs.post_disable op for all the bridges in the encoder chain, starting from the first bridge to the last. These are called after completing the encoder’s prepare op.
Note
the bridge passed should be the one closest to the encoder
set proposed mode for all bridges in the encoder chain
Parameters
Description
Calls drm_bridge_funcs.mode_set op for all the bridges in the encoder chain, starting from the first bridge to the last.
Note
the bridge passed should be the one closest to the encoder
prepares for enabling all bridges in the encoder chain
Parameters
Description
Calls drm_bridge_funcs.pre_enable op for all the bridges in the encoder chain, starting from the last bridge to the first. These are called before calling the encoder’s commit op.
Note
the bridge passed should be the one closest to the encoder
enables all bridges in the encoder chain
Parameters
Description
Calls drm_bridge_funcs.enable op for all the bridges in the encoder chain, starting from the first bridge to the last. These are called after completing the encoder’s commit op.
Note that the bridge passed should be the one closest to the encoder
find the bridge corresponding to the device node in the global bridge list
Parameters
Return
drm_bridge control struct on success, NULL on failure
The DRM panel helpers allow drivers to register panel objects with a central registry and provide functions to retrieve those panels in display drivers.
perform operations on a given panel
Definition
struct drm_panel_funcs {
int (* disable) (struct drm_panel *panel);
int (* unprepare) (struct drm_panel *panel);
int (* prepare) (struct drm_panel *panel);
int (* enable) (struct drm_panel *panel);
int (* get_modes) (struct drm_panel *panel);
int (* get_timings) (struct drm_panel *panel, unsigned int num_timings,struct display_timing *timings);
};
Members
Description
The .:c:func:prepare() function is typically called before the display controller starts to transmit video data. Panel drivers can use this to turn the panel on and wait for it to become ready. If additional configuration is required (via a control bus such as I2C, SPI or DSI for example) this is a good time to do that.
After the display controller has started transmitting video data, it’s safe to call the .:c:func:enable() function. This will typically enable the backlight to make the image on screen visible. Some panels require a certain amount of time or frames before the image is displayed. This function is responsible for taking this into account before enabling the backlight to avoid visual glitches.
Before stopping video transmission from the display controller it can be necessary to turn off the panel to avoid visual glitches. This is done in the .:c:func:disable() function. Analogously to .:c:func:enable() this typically involves turning off the backlight and waiting for some time to make sure no image is visible on the panel. It is then safe for the display controller to cease transmission of video data.
To save power when no video data is transmitted, a driver can power down the panel. This is the job of the .:c:func:unprepare() function.
DRM panel object
Definition
struct drm_panel {
struct drm_device * drm;
struct drm_connector * connector;
struct device * dev;
const struct drm_panel_funcs * funcs;
struct list_head list;
};
Members
Parameters
Description
Calling this function will completely power off a panel (assert the panel’s reset, turn off power supplies, ...). After this function has completed, it is usually no longer possible to communicate with the panel until another call to drm_panel_prepare().
Return
0 on success or a negative error code on failure.
Parameters
Description
This will typically turn off the panel’s backlight or disable the display drivers. For smart panels it should still be possible to communicate with the integrated circuitry via any command bus after this call.
Return
0 on success or a negative error code on failure.
Parameters
Description
Calling this function will enable power and deassert any reset signals to the panel. After this has completed it is possible to communicate with any integrated circuitry via a command bus.
Return
0 on success or a negative error code on failure.
Parameters
Description
Calling this function will cause the panel display drivers to be turned on and the backlight to be enabled. Content will be visible on screen after this call completes.
Return
0 on success or a negative error code on failure.
Parameters
Description
The modes probed from the panel are automatically added to the connector that the panel is attached to.
Return
The number of modes available from the panel on success or a negative error code on failure.
Parameters
Description
Sets up internal fields of the panel so that it can subsequently be added to the registry.
Parameters
Description
Add a panel to the global registry so that it can be looked up by display drivers.
Return
0 on success or a negative error code on failure.
Parameters
Description
Removes a panel from the global registry.
attach a panel to a connector
Parameters
Description
After obtaining a pointer to a DRM panel a display driver calls this function to attach a panel to a connector.
An error is returned if the panel is already attached to another connector.
Return
0 on success or a negative error code on failure.
Parameters
Description
Detaches a panel from the connector it is attached to. If a panel is not attached to any connector this is effectively a no-op.
Return
0 on success or a negative error code on failure.
look up a panel using a device tree node
Parameters
Description
Searches the set of registered panels for one that matches the given device tree node. If a matching panel is found, return a pointer to it.
Return
A pointer to the panel registered for the specified device tree node or NULL if no panel matching the device tree node can be found.
These functions contain some common logic and helpers at various abstraction levels to deal with Display Port sink devices and related things like DP aux channel transfers, EDID reading over DP aux channels, decoding certain DPCD blocks, ...
The DisplayPort AUX channel is an abstraction to allow generic, driver- independent access to AUX functionality. Drivers can take advantage of this by filling in the fields of the drm_dp_aux structure.
Transactions are described using a hardware-independent drm_dp_aux_msg structure, which is passed into a driver’s .:c:func:transfer() implementation. Both native and I2C-over-AUX transactions are supported.
DisplayPort AUX channel transaction
Definition
struct drm_dp_aux_msg {
unsigned int address;
u8 request;
u8 reply;
void * buffer;
size_t size;
};
Members
DisplayPort AUX channel
Definition
struct drm_dp_aux {
const char * name;
struct i2c_adapter ddc;
struct device * dev;
struct drm_crtc * crtc;
struct mutex hw_mutex;
struct work_struct crc_work;
u8 crc_count;
ssize_t (* transfer) (struct drm_dp_aux *aux,struct drm_dp_aux_msg *msg);
unsigned i2c_nack_count;
unsigned i2c_defer_count;
};
Members
Description
The .dev field should be set to a pointer to the device that implements the AUX channel.
The .name field may be used to specify the name of the I2C adapter. If set to NULL, dev_name() of .dev will be used.
Drivers provide a hardware-specific implementation of how transactions are executed via the .:c:func:transfer() function. A pointer to a drm_dp_aux_msg structure describing the transaction is passed into this function. Upon success, the implementation should return the number of payload bytes that were transferred, or a negative error-code on failure. Helpers propagate errors from the .:c:func:transfer() function, with the exception of the -EBUSY error, which causes a transaction to be retried. On a short, helpers will return -EPROTO to make it simpler to check for failure.
An AUX channel can also be used to transport I2C messages to a sink. A typical application of that is to access an EDID that’s present in the sink device. The .:c:func:transfer() function can also be used to execute such transactions. The drm_dp_aux_register() function registers an I2C adapter that can be passed to drm_probe_ddc(). Upon removal, drivers should call drm_dp_aux_unregister() to remove the I2C adapter. The I2C adapter uses long transfers by default; if a partial response is received, the adapter will drop down to the size given by the partial response for this transaction only.
Note that the aux helper code assumes that the .:c:func:transfer() function only modifies the reply field of the drm_dp_aux_msg structure. The retry logic and i2c helpers assume this is the case.
read a single byte from the DPCD
Parameters
Description
Returns the number of bytes transferred (1) on success, or a negative error code on failure.
write a single byte to the DPCD
Parameters
Description
Returns the number of bytes transferred (1) on success, or a negative error code on failure.
read a series of bytes from the DPCD
Parameters
Description
Returns the number of bytes transferred on success, or a negative error code on failure. -EIO is returned if the request was NAKed by the sink or if the retry count was exceeded. If not all bytes were transferred, this function returns -EPROTO. Errors from the underlying AUX channel transfer function, with the exception of -EBUSY (which causes the transaction to be retried), are propagated to the caller.
write a series of bytes to the DPCD
Parameters
Description
Returns the number of bytes transferred on success, or a negative error code on failure. -EIO is returned if the request was NAKed by the sink or if the retry count was exceeded. If not all bytes were transferred, this function returns -EPROTO. Errors from the underlying AUX channel transfer function, with the exception of -EBUSY (which causes the transaction to be retried), are propagated to the caller.
read DPCD link status (bytes 0x202-0x207)
Parameters
Description
Returns the number of bytes transferred on success or a negative error code on failure.
probe a DisplayPort link for capabilities
Parameters
Description
The structure filled in by this function can usually be passed directly into drm_dp_link_power_up() and drm_dp_link_configure() to power up and configure the link based on the link’s capabilities.
Returns 0 on success or a negative error code on failure.
power up a DisplayPort link
Parameters
Description
Returns 0 on success or a negative error code on failure.
power down a DisplayPort link
Parameters
Description
Returns 0 on success or a negative error code on failure.
configure a DisplayPort link
Parameters
Description
Returns 0 on success or a negative error code on failure.
extract branch device max pixel rate for legacy VGA converter or max TMDS clock rate for others
Parameters
Description
Returns max clock in kHz on success or 0 if max clock not defined
extract branch device max bits per component
Parameters
Description
Returns max bpc on success or 0 if max bpc not defined
identify branch device
Parameters
Description
Returns branch device id on success or NULL on failure
debug DP branch devices
Parameters
minimally initialise an aux channel
Parameters
Description
If you need to use the drm_dp_aux’s i2c adapter prior to registering it with the outside world, call drm_dp_aux_init() first. You must still call drm_dp_aux_register() once the connector has been registered to allow userspace access to the auxiliary DP channel.
initialise and register aux channel
Parameters
Description
Automatically calls drm_dp_aux_init() if this hasn’t been done yet.
Returns 0 on success or a negative error code on failure.
unregister an AUX adapter
Parameters
PSR setup in time usec
Parameters
Return
PSR setup time for the panel in microseconds, negative error code on failure.
start capture of frame CRCs
Parameters
Description
Returns 0 on success or a negative error code on failure.
stop capture of frame CRCs
Parameters
Description
Returns 0 on success or a negative error code on failure.
Helper functions to deal with DP dual mode (aka. DP++) adaptors.
Type 1: Adaptor registers (if any) and the sink DDC bus may be accessed via I2C.
Type 2: Adaptor registers and sink DDC bus can be accessed either via I2C or I2C-over-AUX. Source devices may choose to implement either of these access methods.
Constants
Type of the DP dual mode adaptor
Constants
Read from the DP dual mode adaptor register(s)
Parameters
Description
Reads size bytes from the DP dual mode adaptor registers starting at offset.
Return
0 on success, negative error code on failure
Write to the DP dual mode adaptor register(s)
Parameters
Description
Writes size bytes to the DP dual mode adaptor registers starting at offset.
Return
0 on success, negative error code on failure
Identify the DP dual mode adaptor
Parameters
Description
Attempt to identify the type of the DP dual mode adaptor used.
Note that when the answer is DRM_DP_DUAL_MODE_UNKNOWN it’s not certain whether we’re dealing with a native HDMI port or a type 1 DVI dual mode adaptor. The driver will have to use some other hardware/driver specific mechanism to make that distinction.
Return
The type of the DP dual mode adaptor used
Max TMDS clock for DP dual mode adaptor
Parameters
Description
Determine the max TMDS clock the adaptor supports based on the type of the dual mode adaptor and the DP_DUAL_MODE_MAX_TMDS_CLOCK register (on type2 adaptors). As some type 1 adaptors have problems with registers (see comments in drm_dp_dual_mode_detect()) we don’t read the register on those, instead we simply assume a 165 MHz limit based on the specification.
Return
Maximum supported TMDS clock rate for the DP dual mode adaptor in kHz.
Get the state of the TMDS output buffers in the DP dual mode adaptor
Parameters
Description
Get the state of the TMDS output buffers in the adaptor. For type2 adaptors this is queried from the DP_DUAL_MODE_TMDS_OEN register. As some type 1 adaptors have problems with registers (see comments in drm_dp_dual_mode_detect()) we don’t read the register on those, instead we simply assume that the buffers are always enabled.
Return
0 on success, negative error code on failure
Enable/disable TMDS output buffers in the DP dual mode adaptor
Parameters
Description
Set the state of the TMDS output buffers in the adaptor. For type2 this is set via the DP_DUAL_MODE_TMDS_OEN register. As some type 1 adaptors have problems with registers (see comments in drm_dp_dual_mode_detect()) we avoid touching the register, making this function a no-op on type 1 adaptors.
Return
0 on success, negative error code on failure
Get the name of the DP dual mode adaptor type as a string
Parameters
Return
String representation of the DP dual mode adaptor type
Parameters
Description
reading offset (0x80, 0x41)
Return
0 on success, sets the current_mode value to appropriate mode -error on failure
Parameters
Description
writing offset (0x80, 0x40)
Return
0 on success, -error on failure/timeout
These functions contain parts of the DisplayPort 1.2a MultiStream Transport protocol. The helpers contain a topology manager and bandwidth manager. The helpers encapsulate the sending and received of sideband msgs.
Virtual Channel Payload Identifier
Definition
struct drm_dp_vcpi {
int vcpi;
int pbn;
int aligned_pbn;
int num_slots;
};
Members
MST port
Definition
struct drm_dp_mst_port {
struct kref kref;
u8 port_num;
bool input;
bool mcs;
bool ddps;
u8 pdt;
bool ldps;
u8 dpcd_rev;
u8 num_sdp_streams;
u8 num_sdp_stream_sinks;
uint16_t available_pbn;
struct list_head next;
struct drm_dp_mst_branch * mstb;
struct drm_dp_aux aux;
struct drm_dp_mst_branch * parent;
struct drm_dp_vcpi vcpi;
struct drm_connector * connector;
struct drm_dp_mst_topology_mgr * mgr;
struct edid * cached_edid;
bool has_audio;
};
Members
Description
This structure represents an MST port endpoint on a device somewhere in the MST topology.
MST branch device.
Definition
struct drm_dp_mst_branch {
struct kref kref;
u8 rad[8];
u8 lct;
int num_ports;
int msg_slots;
struct list_head ports;
struct drm_dp_mst_port * port_parent;
struct drm_dp_mst_topology_mgr * mgr;
struct drm_dp_sideband_msg_tx * tx_slots[2];
int last_seqno;
bool link_address_sent;
u8 guid[16];
};
Members
Description
This structure represents an MST branch device, there is one primary branch device at the root, along with any other branches connected to downstream port of parent branches.
DisplayPort MST manager
Definition
struct drm_dp_mst_topology_mgr {
struct drm_device * dev;
const struct drm_dp_mst_topology_cbs * cbs;
int max_dpcd_transaction_bytes;
struct drm_dp_aux * aux;
int max_payloads;
int conn_base_id;
struct drm_dp_sideband_msg_rx down_rep_recv;
struct drm_dp_sideband_msg_rx up_req_recv;
struct mutex lock;
bool mst_state;
struct drm_dp_mst_branch * mst_primary;
u8 dpcd[DP_RECEIVER_CAP_SIZE];
u8 sink_count;
int pbn_div;
struct mutex qlock;
struct list_head tx_msg_downq;
struct mutex payload_lock;
struct drm_dp_vcpi ** proposed_vcpis;
struct drm_dp_payload * payloads;
unsigned long payload_mask;
unsigned long vcpi_mask;
wait_queue_head_t tx_waitq;
struct work_struct work;
struct work_struct tx_work;
struct list_head destroy_connector_list;
struct mutex destroy_connector_lock;
struct work_struct destroy_connector_work;
};
Members
Description
This struct represents the toplevel displayport MST topology manager. There should be one instance of this for every MST capable DP connector on the GPU.
Execute payload update part 1
Parameters
Description
This iterates over all proposed virtual channels, and tries to allocate space in the link for them. For 0->slots transitions, this step just writes the VCPI to the MST device. For slots->0 transitions, this writes the updated VCPIs and removes the remote VC payloads.
after calling this the driver should generate ACT and payload packets.
Execute payload update part 2
Parameters
Description
This iterates over all proposed virtual channels, and tries to allocate space in the link for them. For 0->slots transitions, this step writes the remote VC payload commands. For slots->0 this just resets some internal state.
Set the MST state for a topology manager
Parameters
Description
This is called by the driver when it detects an MST capable device plugged into a DP MST capable port, or when a DP MST capable device is unplugged.
suspend the MST manager
Parameters
Description
This function tells the MST device that we can’t handle UP messages anymore. This should stop it from sending any since we are suspended.
resume the MST manager
Parameters
Description
This will fetch DPCD and see if the device is still there, if it is, it will rewrite the MSTM control bits, and return.
if the device fails this returns -1, and the driver should do a full MST reprobe, in case we were undocked.
MST hotplug IRQ notify
Parameters
Description
This should be called from the driver when it detects a short IRQ, along with the value of the DEVICE_SERVICE_IRQ_VECTOR_ESI0. The topology manager will process the sideband messages received as a result of this.
get connection status for an MST port
Parameters
Description
This returns the current connection state for a port. It validates the port pointer still exists so the caller doesn’t require a reference
Check whether port has audio capability or not
Parameters
Description
This returns whether the port supports audio or not.
get EDID for an MST port
Parameters
Description
This returns an EDID for the port connected to a connector, It validates the pointer still exists so the caller doesn’t require a reference.
find slots for this PBN value
Parameters
Allocate a virtual channel
Parameters
Reset number of slots to 0 for VCPI
Parameters
Description
This just resets the number of slots for the ports VCPI for later programming.
deallocate a VCPI
Parameters
Check ACT handled status.
Parameters
Description
Check the payload status bits in the DPCD for ACT handled completion.
Calculate the PBN for a mode.
Parameters
Description
This uses the formula in the spec to calculate the PBN value for a mode.
Parameters
Description
helper to dump MST topology to a seq file for debugfs.
initialise a topology manager
Parameters
Description
Return 0 for success, or negative error code on failure
destroy topology manager.
Parameters
These functions contain some common logic and helpers to deal with MIPI DSI peripherals.
Helpers are provided for a number of standard MIPI DSI command as well as a subset of the MIPI DCS command set.
read/write DSI buffer
Definition
struct mipi_dsi_msg {
u8 channel;
u8 type;
u16 flags;
size_t tx_len;
const void * tx_buf;
size_t rx_len;
void * rx_buf;
};
Members
represents a MIPI DSI packet in protocol format
Definition
struct mipi_dsi_packet {
size_t size;
u8 header[4];
size_t payload_length;
const u8 * payload;
};
Members
DSI bus operations
Definition
struct mipi_dsi_host_ops {
int (* attach) (struct mipi_dsi_host *host,struct mipi_dsi_device *dsi);
int (* detach) (struct mipi_dsi_host *host,struct mipi_dsi_device *dsi);
ssize_t (* transfer) (struct mipi_dsi_host *host,const struct mipi_dsi_msg *msg);
};
Members
Description
DSI packets transmitted by .:c:func:transfer() are passed in as mipi_dsi_msg structures. This structure contains information about the type of packet being transmitted as well as the transmit and receive buffers. When an error is encountered during transmission, this function will return a negative error code. On success it shall return the number of bytes transmitted for write packets or the number of bytes received for read packets.
Note that typically DSI packet transmission is atomic, so the .:c:func:transfer() function will seldomly return anything other than the number of bytes contained in the transmit buffer on success.
DSI host device
Definition
struct mipi_dsi_host {
struct device * dev;
const struct mipi_dsi_host_ops * ops;
struct list_head list;
};
Members
template for creating a mipi_dsi_device
Definition
struct mipi_dsi_device_info {
char type[DSI_DEV_NAME_SIZE];
u32 channel;
struct device_node * node;
};
Members
Description
This is populated and passed to mipi_dsi_device_new to create a new DSI device
DSI peripheral device
Definition
struct mipi_dsi_device {
struct mipi_dsi_host * host;
struct device dev;
char name[DSI_DEV_NAME_SIZE];
unsigned int channel;
unsigned int lanes;
enum mipi_dsi_pixel_format format;
unsigned long mode_flags;
};
Members
obtain the number of bits per pixel for any given pixel format defined by the MIPI DSI specification
Parameters
Return
The number of bits per pixel of the given pixel format.
Tearing Effect Output Line mode
Constants
DSI driver
Definition
struct mipi_dsi_driver {
struct device_driver driver;
int(* probe) (struct mipi_dsi_device *dsi);
int(* remove) (struct mipi_dsi_device *dsi);
void (* shutdown) (struct mipi_dsi_device *dsi);
};
Members
find the MIPI DSI device matching a device tree node
Parameters
Return
create a MIPI DSI device
Parameters
Description
Create a MIPI DSI device by using the device information provided by mipi_dsi_device_info template
Return
A pointer to the newly created MIPI DSI device, or, a pointer encoded with an error
unregister MIPI DSI device
Parameters
find the MIPI DSI host matching a device tree node
Parameters
Return
A pointer to the MIPI DSI host corresponding to node or NULL if no such device exists (or has not been registered yet).
attach a DSI device to its DSI host
Parameters
detach a DSI device from its DSI host
Parameters
check if a packet is of the short format
Parameters
Return
true if the packet for the given data type is a short packet, false otherwise.
check if a packet is of the long format
Parameters
Return
true if the packet for the given data type is a long packet, false otherwise.
create a packet from a message according to the DSI protocol
Parameters
Return
0 on success or a negative error code on failure.
sends a Shutdown Peripheral command
Parameters
Return
0 on success or a negative error code on failure.
sends a Turn On Peripheral command
Parameters
Return
0 on success or a negative error code on failure.
transmit data using a generic write packet
Parameters
Description
This function will automatically choose the right data type depending on the payload length.
Return
The number of bytes transmitted on success or a negative error code on failure.
receive data using a generic read packet
Parameters
Description
This function will automatically choose the right data type depending on the number of parameters passed in.
Return
The number of bytes successfully read or a negative error code on failure.
transmit a DCS command with payload
Parameters
Description
This function will automatically choose the right data type depending on the command payload length.
Return
The number of bytes successfully transmitted or a negative error code on failure.
send DCS write command
Parameters
Description
This function will automatically choose the right data type depending on the command payload length.
Return
The number of bytes successfully transmitted or a negative error code on failure.
send DCS read request command
Parameters
Return
The number of bytes read or a negative error code on failure.
send DCS nop packet
Parameters
Return
0 on success or a negative error code on failure.
perform a software reset of the display module
Parameters
Return
0 on success or a negative error code on failure.
query the display module’s current power mode
Parameters
Return
0 on success or a negative error code on failure.
gets the pixel format for the RGB image data used by the interface
Parameters
Return
0 on success or a negative error code on failure.
disable all unnecessary blocks inside the display module except interface communication
Parameters
Return
0 on success or a negative error code on failure.
enable all blocks inside the display module
Parameters
Return
0 on success or a negative error code on failure.
stop displaying the image data on the display device
Parameters
Return
0 on success or a negative error code on failure.
start displaying the image data on the display device
Parameters
Return
0 on success or a negative error code on failure
define the column extent of the frame memory accessed by the host processor
Parameters
Return
0 on success or a negative error code on failure.
define the page extent of the frame memory accessed by the host processor
Parameters
Return
0 on success or a negative error code on failure.
turn off the display module’s Tearing Effect output signal on the TE signal line
Parameters
Return
0 on success or a negative error code on failure
turn on the display module’s Tearing Effect output signal on the TE signal line.
Parameters
Return
0 on success or a negative error code on failure
sets the pixel format for the RGB image data used by the interface
Parameters
Return
0 on success or a negative error code on failure.
set the scanline to use as trigger for the Tearing Effect output signal of the display module
Parameters
Return
0 on success or a negative error code on failure
sets the brightness value of the display
Parameters
Return
0 on success or a negative error code on failure.
gets the current brightness value of the display
Parameters
Return
0 on success or a negative error code on failure.
register a driver for DSI devices
Parameters
Return
0 on success or a negative error code on failure.
unregister a driver for DSI devices
Parameters
Return
0 on success or a negative error code on failure.
This library provides some helper code for output probing. It provides an implementation of the core drm_connector_funcs.fill_modes interface with drm_helper_probe_single_connector_modes.
It also provides support for polling connectors with a work item and for generic hotplug interrupt handling where the driver doesn’t or cannot keep track of a per-connector hpd interrupt.
This helper library can be used independently of the modeset helper library. Drivers can also overwrite different parts e.g. use their own hotplug handling code to avoid probing unrelated outputs.
The probe helpers share the function table structures with other display helper libraries. See struct drm_connector_helper_funcs for the details.
re-enable output polling.
Parameters
Description
This function re-enables the output polling work, after it has been temporarily disabled using drm_kms_helper_poll_disable(), for example over suspend/resume.
Drivers can call this helper from their device resume implementation. It is an error to call this when the output polling support has not yet been set up.
Note that calls to enable and disable polling must be strictly ordered, which is automatically the case when they’re only call from suspend/resume callbacks.
get complete set of display modes
Parameters
Description
Based on the helper callbacks implemented by connector in struct drm_connector_helper_funcs try to detect all valid modes. Modes will first be added to the connector’s probed_modes list, then culled (based on validity and the maxX, maxY parameters) and put into the normal modes list.
Intended to be used as a generic implementation of the drm_connector_funcs.fill_modes() vfunc for drivers that use the CRTC helpers for output mode filtering and detection.
The basic procedure is as follows
All modes currently on the connector’s modes list are marked as stale
New modes are added to the connector’s probed_modes list with drm_mode_probed_add(). New modes start their life with status as OK. Modes are added from a single source using the following priority order.
Finally modes specified via the kernel command line (video=...) are added in addition to what the earlier probes produced (drm_helper_probe_add_cmdline_mode()). These modes are generated using the VESA GTF/CVT formulas.
Modes are moved from the probed_modes list to the modes list. Potential duplicates are merged together (see drm_mode_connector_list_update()). After this step the probed_modes list will be empty again.
Any non-stale mode on the modes list then undergoes validation
Any mode whose status is not OK is pruned from the connector’s modes list, accompanied by a debug message indicating the reason for the mode’s rejection (see drm_mode_prune_invalid()).
Return
The number of modes found on connector.
fire off KMS hotplug events
Parameters
Description
This function fires off the uevent for userspace and also calls the output_poll_changed function, which is most commonly used to inform the fbdev emulation code and allow it to update the fbcon output configuration.
Drivers should call this from their hotplug handling code when a change is detected. Note that this function does not do any output detection of its own, like drm_helper_hpd_irq_event() does - this is assumed to be done by the driver already.
This function must be called from process context with no mode setting locks held.
disable output polling
Parameters
Description
This function disables the output polling work.
Drivers can call this helper from their device suspend implementation. It is not an error to call this even when output polling isn’t enabled or already disabled. Polling is re-enabled by calling drm_kms_helper_poll_enable().
Note that calls to enable and disable polling must be strictly ordered, which is automatically the case when they’re only call from suspend/resume callbacks.
initialize and enable output polling
Parameters
Description
This function intializes and then also enables output polling support for dev. Drivers which do not have reliable hotplug support in hardware can use this helper infrastructure to regularly poll such connectors for changes in their connection state.
Drivers can control which connectors are polled by setting the DRM_CONNECTOR_POLL_CONNECT and DRM_CONNECTOR_POLL_DISCONNECT flags. On connectors where probing live outputs can result in visual distortion drivers should not set the DRM_CONNECTOR_POLL_DISCONNECT flag to avoid this. Connectors which have no flag or only DRM_CONNECTOR_POLL_HPD set are completely ignored by the polling logic.
Note that a connector can be both polled and probed from the hotplug handler, in case the hotplug interrupt is known to be unreliable.
disable output polling and clean it up
Parameters
hotplug processing
Parameters
Description
Drivers can use this helper function to run a detect cycle on all connectors which have the DRM_CONNECTOR_POLL_HPD flag set in their polled member. All other connectors are ignored, which is useful to avoid reprobing fixed panels.
This helper function is useful for drivers which can’t or don’t track hotplug interrupts for each connector.
Drivers which support hotplug interrupts for each connector individually and which have a more fine-grained detect logic should bypass this code and directly call drm_kms_helper_hotplug_event() in case the connector state changed.
This function must be called from process context with no mode setting locks held.
Note that a connector can be both polled and probed from the hotplug handler, in case the hotplug interrupt is known to be unreliable.
Get ELD monitor name length in bytes.
Parameters
Get ELD SAD structures.
Parameters
Get ELD SAD count.
Parameters
Calculate baseline block size in bytes
Parameters
Description
This is a helper for determining the payload size of the baseline block, in bytes, for e.g. setting the Baseline_ELD_Len field in the ELD header block.
Get ELD size in bytes
Parameters
Description
The returned value does not include the vendor block. It’s vendor specific, and comprises of the remaining bytes in the ELD memory buffer after drm_eld_size() bytes of header and baseline block.
The returned value is guaranteed to be a multiple of 4.
Get speaker allocation
Parameters
Description
The returned value is the speakers mask. User has to use DRM_ELD_SPEAKER field definitions to identify speakers.
Get device type hdmi/dp connected
Parameters
Description
The caller need to use DRM_ELD_CONN_TYPE_HDMI or DRM_ELD_CONN_TYPE_DP to identify the display type connected.
sanity check the header of the base EDID block
Parameters
Description
Sanity check the header of the base EDID block.
Return
8 if the header is perfect, down to 0 if it’s totally wrong.
Sanity check the EDID block (base or extension)
Parameters
Description
Validate a base or extension EDID block and optionally dump bad blocks to the console.
Return
True if the block is valid, false otherwise.
sanity check EDID data
Parameters
Description
Sanity-check an entire EDID record (including extensions)
Return
True if the EDID data is valid, false otherwise.
get EDID data using a custom EDID block read function
Parameters
Description
When the I2C adapter connected to the DDC bus is hidden behind a device that exposes a different interface to read EDID blocks this function can be used to get EDID data using a custom block read function.
As in the general case the DDC bus is accessible by the kernel at the I2C level, drivers must make all reasonable efforts to expose it as an I2C adapter and use drm_get_edid() instead of abusing this function.
Return
Pointer to valid EDID or NULL if we couldn’t find any.
probe DDC presence
Parameters
Return
True on success, false on failure.
get EDID data, if available
Parameters
Description
Poke the given I2C channel to grab EDID data if possible. If found, attach it to the connector.
Return
Pointer to valid EDID or NULL if we couldn’t find any.
get EDID data for a vga_switcheroo output
Parameters
Description
Wrapper around drm_get_edid() for laptops with dual GPUs using one set of outputs. The wrapper adds the requisite vga_switcheroo calls to temporarily switch DDC to the GPU which is retrieving EDID.
Return
Pointer to valid EDID or NULL if we couldn’t find any.
duplicate an EDID and the extensions
Parameters
Return
Pointer to duplicated EDID or NULL on allocation failure.
look for a CEA mode matching given mode
Parameters
Return
The CEA Video ID (VIC) of the mode or 0 if it isn’t a CEA-861 mode.
get the picture aspect ratio corresponding to the input VIC from the CEA mode list
Parameters
Description
Returns picture aspect ratio
fetch the monitor name from the edid
Parameters
build ELD from EDID
Parameters
Description
Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
extracts SADs from EDID
Parameters
Description
Looks for CEA EDID block and extracts SADs (Short Audio Descriptors) from it.
Note
The returned pointer needs to be freed using kfree().
Return
The number of found SADs or negative number on error.
extracts Speaker Allocation Data Blocks from EDID
Parameters
Description
Looks for CEA EDID block and extracts the Speaker Allocation Data Block from it.
Note
The returned pointer needs to be freed using kfree().
Return
The number of found Speaker Allocation Blocks or negative number on error.
compute the HDMI/DP sink audio-video sync delay
Parameters
Return
The HDMI/DP sink’s audio-video sync delay in milliseconds or 0 if the sink doesn’t support audio or video.
detect whether monitor is HDMI
Parameters
Description
Parse the CEA extension according to CEA-861-B.
Return
True if the monitor is HDMI, false if not or unknown.
check monitor audio capability
Parameters
Description
Monitor should have CEA extension block. If monitor has ‘basic audio’, but no CEA audio blocks, it’s ‘basic audio’ only. If there is any audio extension block and supported audio format, assume at least ‘basic audio’ support, even if ‘basic audio’ is not defined in EDID.
Return
True if the monitor supports audio, false otherwise.
is RGB quantization range selectable?
Parameters
Description
Check whether the monitor reports the RGB quantization range selection as supported. The AVI infoframe can then be used to inform the monitor which quantization range (full or limited) is used.
Return
True if the RGB quantization range is selectable, false otherwise.
default RGB quantization range
Parameters
Description
Determine the default RGB quantization range for the mode, as specified in CEA-861.
Return
The default RGB quantization range for the mode
add modes from EDID data, if available
Parameters
Description
Add the specified modes to the connector’s mode list. Also fills out the drm_display_info structure in connector with any information which can be derived from the edid.
Return
The number of modes added or 0 if we couldn’t find any.
add modes for the connectors without EDID
Parameters
Description
Add the specified modes to the connector’s mode list. Only when the hdisplay/vdisplay is not beyond the given limit, it will be added.
Return
The number of modes added or 0 if we couldn’t find any.
Sets the preferred mode of a connector
Parameters
Description
Marks a mode as preferred if it matches the resolution specified by hpref and vpref.
fill an HDMI AVI infoframe with data from a DRM display mode
Parameters
Return
0 on success or a negative error code on failure.
fill the HDMI AVI infoframe quantization range information
Parameters
fill an HDMI infoframe with data from a DRM display mode
Parameters
Description
Note that there’s is a need to send HDMI vendor infoframes only when using a 4k or stereoscopic 3D mode. So when giving any other mode as input this function will return -EINVAL, error that can be safely ignored.
Return
0 on success or a negative error code on failure.
Status and Control Data Channel (SCDC) is a mechanism introduced by the HDMI 2.0 specification. It is a point-to-point protocol that allows the HDMI source and HDMI sink to exchange data. The same I2C interface that is used to access EDID serves as the transport mechanism for SCDC.
read a single byte from SCDC
Parameters
Description
Reads a single byte from SCDC. This is a convenience wrapper around the drm_scdc_read() function.
Return
0 on success or a negative error code on failure.
write a single byte to SCDC
Parameters
Description
Writes a single byte to SCDC. This is a convenience wrapper around the drm_scdc_write() function.
Return
0 on success or a negative error code on failure.
enable scrambling
Parameters
Description
Writes the TMDS config register over SCDC channel, and: enables scrambling when enable = 1 disables scrambling when enable = 0
Return
True if scrambling is set/reset successfully, false otherwise.
set TMDS clock ratio
Parameters
Description
Writes to the TMDS config register over SCDC channel, and: sets TMDS clock ratio to 1/40 when set = 1 sets TMDS clock ratio to 1/10 when set = 0
Return
True if write is successful, false otherwise.
read a block of data from SCDC
Parameters
Description
Reads a block of data from SCDC, starting at a given offset.
Return
0 on success, negative error code on failure.
write a block of data to SCDC
Parameters
Description
Writes a block of data to SCDC, starting at a given offset.
Return
0 on success, negative error code on failure.
what is status of scrambling?
Parameters
Description
Reads the scrambler status over SCDC, and checks the scrambling status.
Return
True if the scrambling is enabled, false otherwise.
enable scrambling
Parameters
Description
Writes the TMDS config register over SCDC channel, and: enables scrambling when enable = 1 disables scrambling when enable = 0
Return
True if scrambling is set/reset successfully, false otherwise.
set TMDS clock ratio
Parameters
Description
TMDS clock ratio calculations go like this: TMDS character = 10 bit TMDS encoded value TMDS character rate = The rate at which TMDS characters are transmitted(Mcsc) TMDS bit rate = 10x TMDS character rate As per the spec: TMDS clock rate for pixel clock < 340 MHz = 1x the character rate
= 1/10 pixel clock rate
Writes to the TMDS config register over SCDC channel, and: sets TMDS clock ratio to 1/40 when set = 1 sets TMDS clock ratio to 1/10 when set = 0
Return
True if write is successful, false otherwise.
Utility functions to help manage rectangular areas for clipping, scaling, etc. calculations.
two dimensional rectangle
Definition
struct drm_rect {
int x1;
int y1;
int x2;
int y2;
};
Members
Parameters
Description
Change the size of rectangle r by dw in the horizontal direction, and by dh in the vertical direction, while keeping the center of r stationary.
Positive dw and dh increase the size, negative values decrease it.
Parameters
Description
Move rectangle r by dx in the horizontal direction, and by dy in the vertical direction.
Parameters
Description
Divide the coordinates of rectangle r by horz and vert.
Parameters
Return
The width of the rectangle.
Parameters
Return
The height of the rectangle.
Parameters
Return
true if the rectangle is visible, false otherwise.
determine if two rectangles are equal
Parameters
Return
true if the rectangles are equal, false otherwise.
Parameters
Description
Calculate the intersection of rectangles r1 and r2. r1 will be overwritten with the intersection.
Return
true if rectangle r1 is still visible after the operation, false otherwise.
perform a scaled clip operation
Parameters
Description
Clip rectangle dst by rectangle clip. Clip rectangle src by the same amounts multiplied by hscale and vscale.
Return
true if rectangle dst is still visible after being clipped, false otherwise
calculate the horizontal scaling factor
Parameters
Description
Calculate the horizontal scaling factor as (src width) / (dst width).
Return
The horizontal scaling factor, or errno of out of limits.
calculate the vertical scaling factor
Parameters
Description
Calculate the vertical scaling factor as (src height) / (dst height).
Return
The vertical scaling factor, or errno of out of limits.
calculate the horizontal scaling factor
Parameters
Description
Calculate the horizontal scaling factor as (src width) / (dst width).
If the calculated scaling factor is below min_vscale, decrease the height of rectangle dst to compensate.
If the calculated scaling factor is above max_vscale, decrease the height of rectangle src to compensate.
Return
The horizontal scaling factor.
calculate the vertical scaling factor
Parameters
Description
Calculate the vertical scaling factor as (src height) / (dst height).
If the calculated scaling factor is below min_vscale, decrease the height of rectangle dst to compensate.
If the calculated scaling factor is above max_vscale, decrease the height of rectangle src to compensate.
Return
The vertical scaling factor.
print the rectangle information
Parameters
Rotate the rectangle
Parameters
Description
Apply rotation to the coordinates of rectangle r.
width and height combined with rotation define the location of the new origin.
width correcsponds to the horizontal and height to the vertical axis of the untransformed coordinate space.
Inverse rotate the rectangle
Parameters
Description
Apply the inverse of rotation to the coordinates of rectangle r.
width and height combined with rotation define the location of the new origin.
width correcsponds to the horizontal and height to the vertical axis of the original untransformed coordinate space, so that you never have to flip them when doing a rotatation and its inverse. That is, if you do
drm_rotate(:c:type:`r`, width, height, rotation);
drm_rotate_inv(:c:type:`r`, width, height, rotation);
you will always get back the original rectangle.
Strictly speaking this is not a DRM helper library but generally useable by any driver interfacing with HDMI outputs like v4l or alsa drivers. But it nicely fits into the overall topic of mode setting helper libraries and hence is also included here.
overall union of all abstract infoframe representations
Definition
union hdmi_infoframe {
struct hdmi_any_infoframe any;
struct hdmi_avi_infoframe avi;
struct hdmi_spd_infoframe spd;
union hdmi_vendor_any_infoframe vendor;
struct hdmi_audio_infoframe audio;
};
Members
Description
This is used by the generic pack function. This works since all infoframes have the same header which also indicates which type of infoframe should be packed.
initialize an HDMI AVI infoframe
Parameters
Description
Returns 0 on success or a negative error code on failure.
write HDMI AVI infoframe to binary buffer
Parameters
Description
Packs the information contained in the frame structure into a binary representation that can be written into the corresponding controller registers. Also computes the checksum as required by section 5.3.5 of the HDMI 1.4 specification.
Returns the number of bytes packed into the binary buffer or a negative error code on failure.
initialize an HDMI SPD infoframe
Parameters
Description
Returns 0 on success or a negative error code on failure.
write HDMI SPD infoframe to binary buffer
Parameters
Description
Packs the information contained in the frame structure into a binary representation that can be written into the corresponding controller registers. Also computes the checksum as required by section 5.3.5 of the HDMI 1.4 specification.
Returns the number of bytes packed into the binary buffer or a negative error code on failure.
initialize an HDMI audio infoframe
Parameters
Description
Returns 0 on success or a negative error code on failure.
write HDMI audio infoframe to binary buffer
Parameters
Description
Packs the information contained in the frame structure into a binary representation that can be written into the corresponding controller registers. Also computes the checksum as required by section 5.3.5 of the HDMI 1.4 specification.
Returns the number of bytes packed into the binary buffer or a negative error code on failure.
initialize an HDMI vendor infoframe
Parameters
Description
Returns 0 on success or a negative error code on failure.
write a HDMI vendor infoframe to binary buffer
Parameters
Description
Packs the information contained in the frame structure into a binary representation that can be written into the corresponding controller registers. Also computes the checksum as required by section 5.3.5 of the HDMI 1.4 specification.
Returns the number of bytes packed into the binary buffer or a negative error code on failure.
write a HDMI infoframe to binary buffer
Parameters
Description
Packs the information contained in the frame structure into a binary representation that can be written into the corresponding controller registers. Also computes the checksum as required by section 5.3.5 of the HDMI 1.4 specification.
Returns the number of bytes packed into the binary buffer or a negative error code on failure.
log info of HDMI infoframe
Parameters
unpack binary buffer to a HDMI infoframe
Parameters
Description
Unpacks the information contained in binary buffer buffer into a structured frame of a HDMI infoframe. Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4 specification.
Returns 0 on success or a negative error code on failure.
Util to queue up work to run from work-queue context after flip/vblank. Typically this can be used to defer unref of framebuffer’s, cursor bo’s, etc until after vblank. The APIs are all thread-safe. Moreover, drm_flip_work_queue_task and drm_flip_work_queue can be called in atomic context.
flip work task
Definition
struct drm_flip_task {
struct list_head node;
void * data;
};
Members
flip work queue
Definition
struct drm_flip_work {
const char * name;
drm_flip_func_t func;
struct work_struct worker;
struct list_head queued;
struct list_head commited;
spinlock_t lock;
};
Members
allocate a flip-work task
Parameters
Description
Allocate a drm_flip_task object and attach private data to it.
queue a specific task
Parameters
Description
Queues task, that will later be run (passed back to drm_flip_func_t func) on a work queue after drm_flip_work_commit() is called.
queue work
Parameters
Description
Queues work, that will later be run (passed back to drm_flip_func_t func) on a work queue after drm_flip_work_commit() is called.
commit queued work
Parameters
Description
Trigger work previously queued by drm_flip_work_queue() to run on a workqueue. The typical usage would be to queue work (via drm_flip_work_queue()) at any point (from vblank irq and/or prior), and then from vblank irq commit the queued work.
initialize flip-work
Parameters
Description
Initializes/allocates resources for the flip-work
cleans up flip-work
Parameters
Description
Destroy resources allocated for the flip-work
This helper library has two parts. The first part has support to implement primary plane support on top of the normal CRTC configuration interface. Since the legacy drm_mode_config_funcs.set_config interface ties the primary plane together with the CRTC state this does not allow userspace to disable the primary plane itself. To avoid too much duplicated code use drm_plane_helper_check_update() which can be used to enforce the same restrictions as primary planes had thus. The default primary plane only expose XRBG8888 and ARGB8888 as valid pixel formats for the attached framebuffer.
Drivers are highly recommended to implement proper support for primary planes, and newly merged drivers must not rely upon these transitional helpers.
The second part also implements transitional helpers which allow drivers to gradually switch to the atomic helper infrastructure for plane updates. Once that switch is complete drivers shouldn’t use these any longer, instead using the proper legacy implementations for update and disable plane hooks provided by the atomic helpers.
Again drivers are strongly urged to switch to the new interfaces.
The plane helpers share the function table structures with other helpers, specifically also the atomic helpers. See struct drm_plane_helper_funcs for the details.
Check plane state for validity
Parameters
Description
Checks that a desired plane update is valid, and updates various bits of derived state (clipped coordinates etc.). Drivers that provide their own plane handling rather than helper-provided implementations may still wish to call this function to avoid duplication of error checking code.
Return
Zero if update appears valid, error code on failure
Check plane update for validity
Parameters
Description
Checks that a desired plane update is valid. Drivers that provide their own plane handling rather than helper-provided implementations may still wish to call this function to avoid duplication of error checking code.
Return
Zero if update appears valid, error code on failure
Helper for primary plane update
Parameters
Description
Provides a default plane update handler for primary planes. This is handler is called in response to a userspace SetPlane operation on the plane with a non-NULL framebuffer. We call the driver’s modeset handler to update the framebuffer.
SetPlane() on a primary plane of a disabled CRTC is not supported, and will return an error.
Note that we make some assumptions about hardware limitations that may not be true for all hardware –
Drivers for hardware that don’t have these restrictions can provide their own implementation rather than using this helper.
Return
Zero on success, error code on failure
Helper for primary plane disable
Parameters
Description
Provides a default plane disable handler for primary planes. This is handler is called in response to a userspace SetPlane operation on the plane with a NULL framebuffer parameter. It unconditionally fails the disable call with -EINVAL the only way to disable the primary plane without driver support is to disable the entire CRTC. Which does not match the plane drm_plane_funcs.disable_plane hook.
Note that some hardware may be able to disable the primary plane without disabling the whole CRTC. Drivers for such hardware should provide their own disable handler that disables just the primary plane (and they’ll likely need to provide their own update handler as well to properly re-enable a disabled primary plane).
Return
Unconditionally returns -EINVAL.
Parameters
Description
Provides a default plane destroy handler for primary planes. This handler is called during CRTC destruction. We disable the primary plane, remove it from the DRM plane list, and deallocate the plane structure.
Transitional helper for plane update
Parameters
Description
Provides a default plane update handler using the atomic plane update functions. It is fully left to the driver to check plane constraints and handle corner-cases like a fully occluded or otherwise invisible plane.
This is useful for piecewise transitioning of a driver to the atomic helpers.
Return
Zero on success, error code on failure
Parameters
Description
Provides a default plane disable handler using the atomic plane update functions. It is fully left to the driver to check plane constraints and handle corner-cases like a fully occluded or otherwise invisible plane.
This is useful for piecewise transitioning of a driver to the atomic helpers.
Return
Zero on success, error code on failure
This helper library contains various one-off functions which don’t really fit anywhere else in the DRM modeset helper library.
move panels to the front in the connector list
Parameters
Description
Some userspace presumes that the first connected connector is the main display, where it’s supposed to display e.g. the login screen. For laptops, this should be the main panel. Use this function to sort all (eDP/LVDS/DSI) panels to the front of the connector list, instead of painstakingly trying to initialize them in the right order.
fill out framebuffer metadata
Parameters
Description
This helper can be used in a drivers fb_create callback to pre-fill the fb’s metadata fields.
Legacy CRTC initialization function
Parameters
Description
Initialize a CRTC object with a default helper-provided primary plane and no cursor plane.
Return
Zero on success, error code on failure.