[Intel-gfx] [PATCH v2 1/2] drm: Create new structure for HDMI info

Jose Abreu Jose.Abreu at synopsys.com
Tue Dec 20 14:19:49 UTC 2016


Hi Shashank,


On 20-12-2016 13:47, Shashank Sharma wrote:
> This patch creates a new structure drm_hdmi_info (inspired from
> drm_display_info). Driver will parse HDMI sink's advance capabilities
> from HF-VSDB and populate this structure. This structure will be kept
> and used as a sub-class within drm_display_info.

You populate the structure but I think you should add a helper to
reset it when there is a new EDID or when the previous EDID is no
longer valid. The same applies to other fields in
drm_display_info structure. I've had problems before because of
incorrect values in this structure.

> We are adding parsing of HF-VSDB In the next patch.
>
> Cc: Thierry Reding <treding at nvidia.com>
> Cc: Daniel Vetter <daniel.vetter at intel.com>
> Cc: Jose Abreu <joabreu at synopsys.com>
> Suggested-by: Thierry Reding <thierry.reding at gmail.com>
> Signed-off-by: Shashank Sharma <shashank.sharma at intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c  |  6 ++--
>  include/drm/drm_connector.h | 79 ++++++++++++++++++++++++++++++++++++++++++---
>  2 files changed, 77 insertions(+), 8 deletions(-)
>

[snip]

>  
>  /**
> + * struct drm_hdmi_info - runtime data specific to a connected hdmi sink
> + *
> + * Describes a given hdmi display (e.g. CRT or flat panel) and its capabilities.
> + * Mostly refects the advanced features added in HDMI 2.0 specs and the deep
> + * color support. This is a sub-segment of struct drm_display_info and should be
> + * used within.
> + *
> + * For sinks which provide an EDID this can be filled out by calling
> + * drm_add_edid_modes().
> + */
> +
> +struct drm_hdmi_info {

[snip]

> +
> +	/**
> +	 * @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding.
> +	 * various sinks can support 10/12/16 bit per channel deep
> +	 * color encoding. edid_yuv420_dc_modes = 0 means sink doesn't
> +	 * support deep color yuv420 encoding.
> +	 */
> +	u8 edid_yuv420_dc_modes;
> +
> +
> +#define DRM_HFVSDB_SCDC_SUPPORT	(1<<7)
> +#define DRM_HFVSDB_SCDC_RR_CAP		(1<<6)
> +#define DRM_HFVSDB_SCRAMBLING		(1<<3)
> +#define DRM_HFVSDB_INDEPENDENT_VIEW	(1<<2)
> +#define DRM_HFVSDB_DUAL_VIEW		(1<<1)
> +#define DRM_HFVSDB_3D_OSD		(1<<0)
> +
> +	/**
> +	 * @scdc_supported: Sink supports SCDC functionality.
> +	 */
> +	bool scdc_supported;
> +
> +	/**
> +	 * @scdc_rr_cap: Sink has SCDC read request capability.
> +	 */
> +	bool scdc_rr_cap;
> +
> +	/**
> +	 * @scrambling: Sync supports scrambling for <=340 Mcsc TMDS
> +	 * char rates. Above 340 Mcsc rates, scrambling is always reqd.
> +	 */
> +	bool scrambling;
> +
> +	/**
> +	 * @independent_view_3d: Sink supports 3d independent view signaling
> +	 * in HF-VSIF.
> +	 */
> +	bool independent_view_3d;
> +
> +	/**
> +	 * @dual_view_3d: Sink supports 3d dual view signaling in HF-VSIF.
> +	 */
> +	bool dual_view_3d;
> +
> +	/**
> +	 * @osd_disparity_3d: Sink supports 3d osd disparity indication
> +	 * in HF-VSIF.
> +	 */
> +	bool osd_disparity_3d;

Maybe you should only add these fields in the second patch.

Best regards,
Jose Miguel Abreu


More information about the Intel-gfx mailing list