BMC/Intel-BMC/linux.git/include/drm/drm_modes.h, branch dev-4.17

drm/modes: Provide global mode_valid hook

2018-01-29T19:51:51+00:00

Allow drivers to provide a device wide .mode_valid() hook in addition to the already existing crtc/encoder/bridge/connector hooks. This can be used to validate device/driver wide constraings without having to add those to the other hooks. And since we call this hook also for user modes later on in the modeset we don't have to worry about anything the hook has already rejected. I also have some further ideas for this hook. Eg. we could replace the drm_mode_set_crtcinfo(HALVE_V) call in drm_mode_convert_umode()/etc. with a driver specific variant via this hook. At least on i915 we would like to pass CRTC_STEREO_DOUBLE to that function instead, and then we could safely use the crtc_ timings in all our .mode_valid() hooks, which would allow us to reuse those hooks for validating the adjusted_mode during a modeset. v2: Fix the language fails in the kernel docs (Daniel) Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-10-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter

drm/uapi: Deprecate nonsense kms mode types

2018-01-29T19:45:29+00:00

BUILTIN, CRTC_C, CLOCK_C, and DEFULT mode types are unused. Let's refuse to generate them or accept them from userspace either. A cursory check didn't reveal any userspace code that would depend on these. v2: Recommend DRIVER instead of BUILTIN (ajax) Cc: Jose Abreu Cc: Adam Jackson Cc: Keith Packard Signed-off-by: Ville Syrjälä Reviewed-by: Adam Jackson Reviewed-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20171115154504.14338-1-ville.syrjala@linux.intel.com Reviewed-by: Jose Abreu

drm/modes: Kill DRM_MODE_TYPE_CLOCK_CRTC_C define

2018-01-29T19:38:50+00:00

No idea what the DRM_MODE_TYPE_CLOCK_CRTC_C define is supposed to achieve. Totally unused so kill if off. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-8-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher

drm/modes: Fix description of DRM_MODE_TYPE_USERDEF

2018-01-29T19:35:31+00:00

These days DRM_MODE_TYPE_USERDEF is used to flag modes defined via the kernel command line. Update the docs to reflect that fact. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-6-ville.syrjala@linux.intel.com Acked-by: Alex Deucher

drm/uapi: Deprecate DRM_MODE_FLAG_BCAST

2018-01-29T19:31:25+00:00

Reject any mode with DRM_MODE_FLAG_BCAST. We have no code that even checks for this flag hence it can't possibly do any good. I think this maybe originated from fbdev where it was supposed to indicate PAL/NTSC broadcast timings. I have no idea why those would have to be identified by a flag rather than by just the timings themselves. And then I assume it got copied into xfree86 for fbdevhw, and later on it leaked into the randr protocol and kms uapi. Since kms fbdev emulation never uses the corresponding fbdev flag there should be no sane way for this to come back into kms via userspace either. Cc: Jose Abreu Cc: Adam Jackson Cc: Keith Packard Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-5-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher Reviewed-by: Jose Abreu

drm/uapi: Deprecate DRM_MODE_FLAG_PIXMUX

2018-01-29T19:31:00+00:00

Reject any mode with DRM_MODE_FLAG_PIXMUX. We have no code that even checks for this flag hence it can't possibly do any good. Looks like this flag had something to do the the controller<->ramdac interface with some ancient S3 graphics adapters. Why someone though it would be a good idea to expose it directly to users I don't know. And later on it got copied into the randr protocol and kms uapi. Cc: Jose Abreu Cc: Adam Jackson Cc: Keith Packard Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-4-ville.syrjala@linux.intel.com Reviewed-by: Alex Deucher Reviewed-by: Jose Abreu

drm: add helper functions for YCBCR420 handling

2017-07-14T18:23:54+00:00

This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 also mode. V2: Added YCBCR functions as helpers in DRM layer, instead of keeping it in I915 layer. V3: Added handling for YCBCR-420 only modes too. V4: EXPORT_SYMBOL(drm_find_hdmi_output_type) V5: Addressed review comments from Danvet: - %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type - %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output - %s/drm_can_support_this_ycbcr_output/ drm_display_supports_this_ycbcr_output - pass drm_display_info instead of drm_connector for consistency - For drm_get_highest_quality_ycbcr_supported doc, move the variable description above, and then the function description. V6: Add only YCBCR420 helpers (Ville) V7: Addressed review comments from Ville - Remove cea_vic_valid() check. - Fix indentation. - Make input parameters to helpers, const. Cc: Ville Syrjala Cc: Jose Abreu Cc: Daniel Vetter Signed-off-by: Shashank Sharma Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-9-git-send-email-shashank.sharma@intel.com [vsyrjala: Fix sparse indentation warn] Signed-off-by: Ville Syrjälä

drm: add helper to validate YCBCR420 modes

2017-07-14T18:23:54+00:00

YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This function will help pruning the YCBCR420-only modes from the connector's modelist. - A bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is capable of handling YCBCR420 output, so that no YCBCR 420 modes will be listed for sources which can't handle it. A driver should set this variable if it wants to see YCBCR420 modes in the modedb. V5: Introduced the patch in series. V6: Squashed two patches (validate YCBCR420 and add YCBCR420 identifier) V7: Addressed review comments from Vile: - Move this patch before we add 420 modes from EDID. - No need for drm_valid_cea_vic() check, function back to non-static. - Update MODE_STATUS with NO_420 condition. - Introduce y420_vdb_modes variable in this patch Cc: Ville Syrjala Signed-off-by: Shashank Sharma Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com [vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)] Signed-off-by: Ville Syrjälä

drm/doc: move printf helpers out of drmP.h

2017-05-31T07:59:41+00:00

And document them lightly. Unfortunately kernel-doc isn't the most awesome for documenting #defines that don't look like functions, it makes functions out of them :-/ Signed-off-by: Daniel Vetter Reviewed-by: Neil Armstrong Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-2-daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-3-daniel.vetter@ffwll.ch

drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/

2017-01-26T09:46:28+00:00

The function operates on modes, not CRTCs. Also move it into drm_modes.[hc]. Spotted while reviewing CRTC docs. Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-15-daniel.vetter@ffwll.ch