From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
At leat on Intel GPUs it is best to allocate CRTCs bottom up
as it will generally lead to lower power consumption. Recommend
userspace does so.
Not sure if this is strictly the best order for other hardware,
but drivers could always rearrange the CRTC list into some kind
of priority order to make it work. Should that turn out to be
insufficient we might need some kind of more complex priority
scheme.
Probably the ideal solution would be to have the driver be
responsible for resource allocation entirely. Ie. the CRTCs
visible via uapi would be virtual and the driver could make
the final choice on which hardware CRTC to use for each.
Unfortunately the kms uapi is geared towards exposing hardware
directly. Eg. when CRTCs are non-uniform in hardware there is
no good way to expose their capabilities. The virtual CRTCs
would more or less either have to expose a superset or a subset
of the capabilities across all hardware CRTCs. Also the
crtc->encoder->connector routing information exposed in the
uapi is all about the actual hardware signal routing. I think
robust virtualized CRTCs would require some new form of uapi
where userspace could declare ahead of time which features
wants on the CRTC (even if not enabling all of them from
the start), and the driver would then have enough information
to make the optimal choice.
Cc: Simon Ser <contact@xxxxxxxxxxx>
Cc: Daniel Stone <daniels@xxxxxxxxxxxxx>
Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
---
include/uapi/drm/drm_mode.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fe5e210396b2..aa90f11950d6 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -386,6 +386,9 @@ struct drm_mode_get_encoder {
/**
* @possible_crtcs: Bitmask of CRTCs compatible with the encoder.
+ * If multiple CRTCs are possible userspace should generally try
+ * to utilize CRTCs bottom up as that may result in lower power
+ * consumption on some systems.
* CRTCs are created and they receive an index, which corresponds
* to their position in the bitmask. Bit N corresponds to
* :ref:`CRTC index<crtc_index>` N.
--
2.44.2
