diff mbox

[v5,02/17] drm: add YCBCR 420 capability identifier

Message ID 1499177524-26292-3-git-send-email-shashank.sharma@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Sharma, Shashank July 4, 2017, 2:11 p.m. UTC
This patch adds 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 YCBCR 420 outputs or not, so that
a lot of work can be done/bypassed based on this information. One such
example is adding YCBCR420 only modes.

If the driver knows that this source is not HDMI 2.0 capable, it will
not add YCBCR420-only modes while adding EDID modes, and will prevent
any runtime modeset failures.

This variable will be initialized from I915 driver in the next patch
and will be used in the EDID handling for HDMI 2.0 specific features,
in this same series.

V3: introduced the new variable
V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville)
V4: adding r-b from Neil.

Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 include/drm/drm_connector.h | 9 +++++++++
 1 file changed, 9 insertions(+)

Comments

Ville Syrjala July 4, 2017, 3:55 p.m. UTC | #1
On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote:
> This patch adds 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 YCBCR 420 outputs or not, so that
> a lot of work can be done/bypassed based on this information. One such
> example is adding YCBCR420 only modes.
> 
> If the driver knows that this source is not HDMI 2.0 capable, it will
> not add YCBCR420-only modes while adding EDID modes, and will prevent
> any runtime modeset failures.
> 
> This variable will be initialized from I915 driver in the next patch
> and will be used in the EDID handling for HDMI 2.0 specific features,
> in this same series.
> 
> V3: introduced the new variable
> V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville)
> V4: adding r-b from Neil.
> 
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> ---
>  include/drm/drm_connector.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ae5b7dc..8a78aaa 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -726,6 +726,15 @@ struct drm_connector {
>  	bool interlace_allowed;
>  	bool doublescan_allowed;
>  	bool stereo_allowed;
> +
> +	/**
> +	 * @ycbcr_420_allowed : This bool indicates if this connector is
> +	 * capable of handling YCBCR 420 output. While parsing the EDID
> +	 * blocks, its very helpful to know, if the source is capable of
> +	 * handling YCBCR 420 outputs.
> +	 */
> +	bool ycbcr_420_allowed;
> +

This patch should be squashed with the patch that actually needs this flag.

>  	/**
>  	 * @registered: Is this connector exposed (registered) with userspace?
>  	 * Protected by @mutex.
> -- 
> 2.7.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Sharma, Shashank July 5, 2017, 3:15 a.m. UTC | #2
Regards

Shashank


On 7/4/2017 9:25 PM, Ville Syrjälä wrote:
> On Tue, Jul 04, 2017 at 07:41:49PM +0530, Shashank Sharma wrote:
>> This patch adds 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 YCBCR 420 outputs or not, so that
>> a lot of work can be done/bypassed based on this information. One such
>> example is adding YCBCR420 only modes.
>>
>> If the driver knows that this source is not HDMI 2.0 capable, it will
>> not add YCBCR420-only modes while adding EDID modes, and will prevent
>> any runtime modeset failures.
>>
>> This variable will be initialized from I915 driver in the next patch
>> and will be used in the EDID handling for HDMI 2.0 specific features,
>> in this same series.
>>
>> V3: introduced the new variable
>> V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville)
>> V4: adding r-b from Neil.
>>
>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>> ---
>>   include/drm/drm_connector.h | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index ae5b7dc..8a78aaa 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -726,6 +726,15 @@ struct drm_connector {
>>   	bool interlace_allowed;
>>   	bool doublescan_allowed;
>>   	bool stereo_allowed;
>> +
>> +	/**
>> +	 * @ycbcr_420_allowed : This bool indicates if this connector is
>> +	 * capable of handling YCBCR 420 output. While parsing the EDID
>> +	 * blocks, its very helpful to know, if the source is capable of
>> +	 * handling YCBCR 420 outputs.
>> +	 */
>> +	bool ycbcr_420_allowed;
>> +
> This patch should be squashed with the patch that actually needs this flag.
This is used in patch 4, to filter out 420_only modes. So I should merge 
it there right ?
- Shashank
>>   	/**
>>   	 * @registered: Is this connector exposed (registered) with userspace?
>>   	 * Protected by @mutex.
>> -- 
>> 2.7.4
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
diff mbox

Patch

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ae5b7dc..8a78aaa 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -726,6 +726,15 @@  struct drm_connector {
 	bool interlace_allowed;
 	bool doublescan_allowed;
 	bool stereo_allowed;
+
+	/**
+	 * @ycbcr_420_allowed : This bool indicates if this connector is
+	 * capable of handling YCBCR 420 output. While parsing the EDID
+	 * blocks, its very helpful to know, if the source is capable of
+	 * handling YCBCR 420 outputs.
+	 */
+	bool ycbcr_420_allowed;
+
 	/**
 	 * @registered: Is this connector exposed (registered) with userspace?
 	 * Protected by @mutex.