kernel/linux.git/include/drm/drm_modes.h, branch v4.5.4

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: 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

drm/mode: Unstatic kernel-userspace mode conversion

2015-05-22T14:18:21+00:00

Move the drm_display_mode <-> drm_mode_modeinfo conversion functions from drm_crtc.c to drm_modes.c, and make them non-static so that others can use them. Signed-off-by: Daniel Stone Tested-by: Sean Paul Signed-off-by: Daniel Vetter

drm: Fix the CRTC_STEREO_DOUBLE_ONLY define to include stero modes

2015-02-23T10:19:35+00:00

The CRTC_STEREO_DOUBLE_ONLY define was introduced in commit: commit ecb7e16bf187bc369cf6a5cd108582c01329980d Author: Gustavo Padovan Date: Mon Dec 1 15:40:09 2014 -0800 drm: add helper to get crtc timings (v5) but if we want the stereo h/v adjustments, we need to set the CRTC_STEREO_DOUBLE flag. Otherwise, we'll get the wrong h/v for frame packing stereo 3d modes. Cc: Gustavo Padovan Cc: Matt Roper Cc: Ander Conselvan de Oliveira Signed-off-by: Damien Lespiau Reviewed-by: Matt Roper Signed-off-by: Daniel Vetter

Merge tag 'imx-drm-next-2015-01-09' of git://git.pengutronix.de/git/pza/linux into drm-next

2015-01-21T00:17:16+00:00

imx-drm mode fixup support, imx-hdmi bridge conversion and imx-drm cleanup - Implement mode_fixup for a DI vertical timing limitation - Use generic DRM OF helpers in DRM core - Convert imx-hdmi to dw_hdmi drm_bridge and add rockchip driver - Add DC use counter to fix multi-display support - Simplify handling of DI clock flags - A few small fixes and cleanup * tag 'imx-drm-next-2015-01-09' of git://git.pengutronix.de/git/pza/linux: (26 commits) imx-drm: core: handling of DI clock flags to ipu_crtc_mode_set() gpu: ipu-di: Switch to DIV_ROUND_CLOSEST for DI clock divider calc gpu: ipu-v3: Use videomode in struct ipu_di_signal_cfg imx-drm: encoder prepare/mode_set must use adjusted mode imx-drm: ipuv3-crtc: Implement mode_fixup drm_modes: add drm_display_mode_to_videomode gpu: ipu-di: remove some non-functional code gpu: ipu-di: Add ipu_di_adjust_videomode() drm: rockchip: export functions needed by rockchip dw_hdmi bridge driver drm: bridge/dw_hdmi: request interrupt only after initializing the mutes drm: bridge/dw_hdmi: add rockchip rk3288 support dt-bindings: Add documentation for rockchip dw hdmi drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done drm: bridge/dw_hdmi: add mode_valid support drm: bridge/dw_hdmi: add support for multi-byte register width access dt-bindings: add document for dw_hdmi drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi drm: imx: imx-hdmi: split phy configuration to platform driver drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode ...

Merge tag 'drm-intel-next-2014-12-19' of git://anongit.freedesktop.org/drm-intel into drm-next

2015-01-09T22:46:24+00:00

- plane handling refactoring from Matt Roper and Gustavo Padovan in prep for atomic updates - fixes and more patches for the seqno to request transformation from John - docbook for fbc from Rodrigo - prep work for dual-link dsi from Gaurav Signh - crc fixes from Ville - special ggtt views infrastructure from Tvrtko Ursulin - shadow patch copying for the cmd parser from Brad Volkin - execlist and full ppgtt by default on gen8, for testing for now * tag 'drm-intel-next-2014-12-19' of git://anongit.freedesktop.org/drm-intel: (131 commits) drm/i915: Update DRIVER_DATE to 20141219 drm/i915: Hold runtime PM during plane commit drm/i915: Organize bind_vma funcs drm/i915: Organize INSTDONE report for future. drm/i915: Organize PDP regs report for future. drm/i915: Organize PPGTT init drm/i915: Organize Fence registers for future enablement. drm/i915: tame the chattermouth (v2) drm/i915: Warn about missing context state workarounds only once drm/i915: Use true PPGTT in Gen8+ when execlists are enabled drm/i915: Skip gunit save/restore for cherryview drm/i915/chv: Use timeout mode for RC6 on chv drm/i915: Add GPGPU_THREADS_DISPATCHED to the register whitelist drm/i915: Tidy up execbuffer command parsing code drm/i915: Mark shadow batch buffers as purgeable drm/i915: Use batch length instead of object size in command parser drm/i915: Use batch pools with the command parser drm/i915: Implement a framework for batch buffer pools drm/i915: fix use after free during eDP encoder destroying drm/i915/skl: Skylake also supports DP MST ...

drm_modes: add drm_display_mode_to_videomode

2015-01-07T18:15:02+00:00

Add conversion from drm_display_mode to videomode. Signed-off-by: Steve Longerbeam Signed-off-by: Philipp Zabel

drm: Perform basic sanity checks on probed modes

2014-12-17T17:29:35+00:00

Make sure the timings of probed modes at least pass some very basic sanity checks. The checks include: - clock,hdisplay,vdisplay are non zero - sync pulse fits within the blanking period - htotal,vtotal are big enough I have not checked all the drivers to see if the modes the generate might violate these constraints. I'm hoping not, because that would mean either abandoning the idea of doing this from the core code, or fixing the drivers. I'm not entirely sure about limiting the sync pulse to the blanking period. Intel hardware doesn't support such things, but some other hardware might. However at least HDMI doesn't allow having sync pulse edges within the active period, so I'm thinking the check is probably OK to have in the common code. Signed-off-by: Ville Syrjälä Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter