From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
Currently most drivers request that any mode appearing on both the
old mode list and the new probed_modes list get their type bits ORed
together if the modes are deemed to otherwise match each other.
I don't know why anyone would want to merge in the mode type bits
from any mode left over from a previous probe. For instance, you
could never get rid of ther preferred bit if a matching non-preferred
mode is returned by the new probe. So let's not merge anything from
the stale old modes, and just replace them outright with matching new
modes.
If multiple matching modes are produced by the same probe, merging
the type bits between them would seem like a sensible thing to do.
For a bit of extra finesse if two modes are considered equal we can
pick the actual timings from the one marked as preferrred. And if
multiple preferred modes are produced by the same probe somehow, we
can just favor the first one added to the probed_modes list.
You may be asking yourself why we bother with the merging at all if
nothing from the old list survives in practice. The only answer I have
is "debug output". That is we want to print out a list of pruned modes,
which is why we still want to look for duplicates with the old modes.
There was a previous attempt to get rid of the mode type merging
entirely, but it caused some kind of regression on Daniels's G33
machine. Apparently the sdvo transcoder on said machine started to
die at around the same time and has since rotted away totally, so
it may have been a red herring. So we don't have to worry about
it anymore. The relevant commits are:
commit 3fbd6439e463 ("drm: copy mode type in drm_mode_connector_list_update()")
commit abce1ec9b08a ("Revert "drm: copy mode type in drm_mode_connector_list_update()"")
It was then decided in
commit b87577b7c768 ("drm: try harder to avoid regression when merging mode bits")
that just qxl virtio are excluded from the merging, while everyone
else does it. That is not changed, although now even qxl and virtio
will be subject to the previously mentioned logic to choose which
actual timings are picked for the new mode.
v2: Fix typos in commit message, and clarify the details on
the G33 regression from the previous attempt (Daniel)
Cc: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
Cc: Dave Airlie <airlied@xxxxxxxxxx>
Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
Cc: Adam Jackson <ajax@xxxxxxxxxx>
Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
---
drivers/gpu/drm/drm_modes.c | 34 +++++++++++++++++++++++++++-------
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 2b94a5c661b0..8c803e3af1da 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1197,13 +1197,33 @@ void drm_mode_connector_list_update(struct drm_connector *connector,
continue;
found_it = true;
- /* if equal delete the probed mode */
- mode->status = pmode->status;
- /* Merge type bits together */
- if (merge_type_bits)
- mode->type |= pmode->type;
- else
- mode->type = pmode->type;
+
+ /*
+ * If the old matching mode is stale (ie. left over
+ * from a previous probe) just replace it outright.
+ * Otherwise just merge the type bits between all
+ * equal probed modes.
+ *
+ * If two probed modes are considered equal, pick the
+ * actual timings from the one that's marked as
+ * preferred (in case the match isn't 100%). If
+ * multiple or zero preferred modes are present, favor
+ * the mode added to the probed_modes list first.
+ */
+ if (mode->status == MODE_STALE) {
+ drm_mode_copy(mode, pmode);
+ } else if ((mode->type & DRM_MODE_TYPE_PREFERRED) == 0 &&
+ (pmode->type & DRM_MODE_TYPE_PREFERRED) != 0) {
+ if (merge_type_bits)
+ pmode->type |= mode->type;
+ drm_mode_copy(mode, pmode);
+ } else {
+ if (merge_type_bits)
+ mode->type |= pmode->type;
+ else
+ mode->type = pmode->type;
+ }
+
list_del(&pmode->head);
drm_mode_destroy(connector->dev, pmode);
break;
--
2.4.10
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
