linux-stable.git/drivers/gpu/drm/drm_modes.c, branch linux-4.6.y

drm: add missing drm_mode_set_crtcinfo call

2016-07-27T15:42:18+00:00

commit b201e743f42d143f4bcdcb14587caf7cb1d99229 upstream.

When setting mode via MODE_ID property,
drm_atomic_set_mode_prop_for_crtc() does not call
drm_mode_set_crtcinfo() which possibly causes:

"[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't
calculate constants, dotclock = 0!"

Whether the error is seen depends on the previous data in state->mode,
as state->mode is not cleared when setting new mode.

This patch adds drm_mode_set_crtcinfo() call to
drm_mode_convert_umode(), which is called in both legacy and atomic
paths. This should be fine as there's no reason to call
drm_mode_convert_umode() without also setting the crtc related fields.

drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as
that is no longer needed.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm: modes: add missing [drm] to message printing

2016-02-09T15:34:44+00:00

The warning message in drm_mode_parse_command_line_for_connector miss
the [drm] at beginning.
This patch add it and take the opportunity to convert
printk(KERN_WARNING to pr_warn()

Signed-off-by: LABBE Corentin 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1454594633-15100-1-git-send-email-clabbe.montjoie@gmail.com

drm/doc: Convert to markdown

2015-12-15T09:22:26+00:00

DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.

* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
  drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore

* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
  to look pretty bad on html. Fixed by using proper code markup.

* drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make
  a proper markup list.

* drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables,
  it doesn't support table cell spanning. But we can use fixed-width
  for those special cases.

* include/drm/drm_vma_manager.h: Another code example that should be
  proper indented with four spaces.

v2 (Daniel): Adjust name to gpu.xml due to rename.

v3 (Daniel):
Split out the actual enabling in the Makefile - this way we can merge
the conversion, while just keeping the enabling in a drm-private tree.

Signed-off-by: Danilo Cesar Lemes de Paula  (v1)
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
Acked-by: Dave Airlie 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1448471279-19748-2-git-send-email-daniel.vetter@ffwll.ch

drm: modes: Revert cc344980c767 "replace simple_strtoul by kstrtouint"

2015-12-11T16:13:06+00:00

My latest commit introduce some case where a valid mode, could be
rejected.
simple_strtox functions stop at first non-digit character, but kstrtox
not.
So args like "video=HDMI-A-1:720x480-16@60" will be reject when checking
16@.

Discussions about this change comes to the conclusion that the best
solution is to revert my commit cc344980c76748e57c9c03100c2a14d36ab00334.

Signed-off-by: LABBE Corentin 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449838739-29969-1-git-send-email-clabbe.montjoie@gmail.com

drm: Drop drm_helper_probe_single_connector_modes_nomerge()

2015-12-11T08:32:53+00:00

Now that the mode type bit merge logic is fixed to only merge
between new probed modes, hopefully we can eliminat the special
case for qxl and virtio. That is make the merge the mode type
bits from all matching new probed modes, just like every other
driver.

qxl and virtio got excluded from the merging in
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()"")
commit b87577b7c768 ("drm: try harder to avoid regression when merging mode bits")

Cc: Marc-André Lureau 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
[danvet: Resolve conflicts with doc updates.]
Signed-off-by: Daniel Vetter

drm: Only merge mode type bits between new probed modes

2015-12-11T08:27:07+00:00

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 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449234781-22332-1-git-send-email-ville.syrjala@linux.intel.com

drm: Flatten drm_mode_connector_list_update() a bit

2015-12-11T08:26:59+00:00

Use 'continue' to eliminate one indent level from
drm_mode_connector_list_update(). And while at it,
make 'found_it' bool.

Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-5-git-send-email-ville.syrjala@linux.intel.com

drm: Rename MODE_UNVERIFIED to MODE_STALE

2015-12-11T08:26:47+00:00

MODE_UNVERIFIED actually means that the mode came from a previous probe,
and if the new probe doesn't produce a matching mode it will get pruned
from the list. Rename the flag to MODE_STALE to better convey the
meaning.

v2: Rebased due to conflicts with Daniel's doc stuff

Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449779948-10906-1-git-send-email-ville.syrjala@linux.intel.com

drm: Move drm_display_mode an related docs into kerneldoc

2015-12-09T08:29:36+00:00

This was in the documentation for modeset helper hooks, where it is a
bit misplaced.

v2: Reindent the drm_mode_status enum, inspired by Ville.

v3: Suggestions from Ville and Thierry.

v4: Small fixup that 0day spotted.

v5: Slight change to avoid accidental headings in kerneldoc output.

Cc: ville.syrjala@linux.intel.com
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-27-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Ville Syrjälä  (v3)
Reviewed-by: Thierry Reding  (v3)

drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference

2015-12-01T06:57:14+00:00

Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
in detailed timings.

drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
which only allows smaller errors for lower clocks (eg. for 25200 it
won't allow any error) and a bigger error for higher clocks (eg. for
297000 it actually matches 296913-297000). So it doesn't really match
what we want for the fixup. Using the explicit +-5kHz is much better
for this use case.

Not sure if we should change the normal mode matching to also use
something else besides KHZ2PICOS() since it allows a different
proportion of error depending on the clock. I believe VESA CVT
allows a maximum deviation of .5%, so using that for normal mode
matching might be a good idea?

Cc: Adam Jackson 
Tested-by: nathan.d.ciobanu@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
Fixes: fa3a7340eaa1 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: Ville Syrjälä 
Reviewed-by: Adam Jackson 
Signed-off-by: Daniel Vetter