[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Jose Abreu]

Hi Daniel,


On 06-12-2016 08:23, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote:
>> On Mon, Dec 05, 2016 at 02:19:48PM +, Jose Abreu wrote:
>>> Hi Thierry,
>>>
>>>
>>> On 05-12-2016 11:14, Thierry Reding wrote:
 On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote:
> Hi Thierry,
>
>
> Do you think while you are at it you could implement a
> set_scrambling() callback? It should be pretty straight forward:
> you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
> again.
>
>
> I think this is an important feature that we should have.
 Yeah, agreed. I was actually thinking about going one step further and
 provide more of the polling functionality as a helper. Even if we have
 accessors that wrap the low-level functionality, most drivers would
 still have to provide their own delayed workqueue to deal with sinks
 (or sources) that don't support read requests. Having this in standard
 helpers would help reduce the boilerplate a lot further.

 Does your hardware by any chance support read requests on SCDC? It'd be
 interesting to see how that works in practice. Unfortunately Tegra does
 not seem to support it.

 Thierry
>>> Yes, my HW supports it though I don't have the setup here to test
>>> right now (but it was used before). In our controller it is
>>> pretty straight forward:
>>> 1) Enable interrupt for rr indication [source]
>>> 2) Enable update read on a rr [source]
>>> 3) Set rr flag in the sink [sink]
>>>
>>> Point 2) makes it clear: Whenever we get a rr then the source
>>> will automatically read the sink and dump the contents read in
>>> the regbank. Then the SW gets an interrupt and it should read the
>>> contents of the registers.
>> Yes, I suspect that there will be three types of setups:
>>
>>  1) fully supported and integrated RR capability (such as in your
>> case)
>>
>>  2) external I2C controller with the means of detecting the read
>> request (and signal via an interrupt)
>>
>>  3) no read request support at all, in which case a delayed work
>> queue is needed to poll periodically
>>
>>
>> For cases 1) and 3) it's probably only useful to have a helper to enable
>> scrambling. For 2) there might be some use in having a helper that can
>> setup the delayed work queue.
>>
>> Given that we don't have any implementation yet, maybe it's better to
>> defer the creation of helpers until we see common patterns emerge. The
>> helper to enable scrambling could be useful in any case, though, so I'll
>> add one.
> So no idea how this works, but how is a read request signalled? 

On HDMI this is done in the I2C line. When the sink wants the
source attention it pulses the SDA low when the bus is free. This
should be correctly handled by the I2C controller that is
connected or included in the HDMI controller.

> On the DP
> side there's just a short pulse hpd when the sink wants the source's
> attention. And iirc hdcp uses similar tricks when e.g. a downstream device
> has changed. We don't yet have it for DP, but some helper to handle hdp
> interrupts with a parameter to indicate long/short pulse is probably all
> that's really needed. But we don't yet have that for DP either :(
> -Daniel

Best regards,
Jose Miguel Abreu

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Daniel Vetter]

On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 02:19:48PM +, Jose Abreu wrote:
> > Hi Thierry,
> > 
> > 
> > On 05-12-2016 11:14, Thierry Reding wrote:
> > > On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote:
> > >> Hi Thierry,
> > >>
> > >>
> > >> Do you think while you are at it you could implement a
> > >> set_scrambling() callback? It should be pretty straight forward:
> > >> you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
> > >> again.
> > >>
> > >>
> > >> I think this is an important feature that we should have.
> > > Yeah, agreed. I was actually thinking about going one step further and
> > > provide more of the polling functionality as a helper. Even if we have
> > > accessors that wrap the low-level functionality, most drivers would
> > > still have to provide their own delayed workqueue to deal with sinks
> > > (or sources) that don't support read requests. Having this in standard
> > > helpers would help reduce the boilerplate a lot further.
> > >
> > > Does your hardware by any chance support read requests on SCDC? It'd be
> > > interesting to see how that works in practice. Unfortunately Tegra does
> > > not seem to support it.
> > >
> > > Thierry
> > 
> > Yes, my HW supports it though I don't have the setup here to test
> > right now (but it was used before). In our controller it is
> > pretty straight forward:
> > 1) Enable interrupt for rr indication [source]
> > 2) Enable update read on a rr [source]
> > 3) Set rr flag in the sink [sink]
> > 
> > Point 2) makes it clear: Whenever we get a rr then the source
> > will automatically read the sink and dump the contents read in
> > the regbank. Then the SW gets an interrupt and it should read the
> > contents of the registers.
> 
> Yes, I suspect that there will be three types of setups:
> 
>   1) fully supported and integrated RR capability (such as in your
>  case)
> 
>   2) external I2C controller with the means of detecting the read
>  request (and signal via an interrupt)
> 
>   3) no read request support at all, in which case a delayed work
>  queue is needed to poll periodically
> 
> 
> For cases 1) and 3) it's probably only useful to have a helper to enable
> scrambling. For 2) there might be some use in having a helper that can
> setup the delayed work queue.
> 
> Given that we don't have any implementation yet, maybe it's better to
> defer the creation of helpers until we see common patterns emerge. The
> helper to enable scrambling could be useful in any case, though, so I'll
> add one.

So no idea how this works, but how is a read request signalled? On the DP
side there's just a short pulse hpd when the sink wants the source's
attention. And iirc hdcp uses similar tricks when e.g. a downstream device
has changed. We don't yet have it for DP, but some helper to handle hdp
interrupts with a parameter to indicate long/short pulse is probably all
that's really needed. But we don't yet have that for DP either :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Thierry Reding]

On Mon, Dec 05, 2016 at 02:19:48PM +, Jose Abreu wrote:
> Hi Thierry,
> 
> 
> On 05-12-2016 11:14, Thierry Reding wrote:
> > On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote:
> >> Hi Thierry,
> >>
> >>
> >> Do you think while you are at it you could implement a
> >> set_scrambling() callback? It should be pretty straight forward:
> >> you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
> >> again.
> >>
> >>
> >> I think this is an important feature that we should have.
> > Yeah, agreed. I was actually thinking about going one step further and
> > provide more of the polling functionality as a helper. Even if we have
> > accessors that wrap the low-level functionality, most drivers would
> > still have to provide their own delayed workqueue to deal with sinks
> > (or sources) that don't support read requests. Having this in standard
> > helpers would help reduce the boilerplate a lot further.
> >
> > Does your hardware by any chance support read requests on SCDC? It'd be
> > interesting to see how that works in practice. Unfortunately Tegra does
> > not seem to support it.
> >
> > Thierry
> 
> Yes, my HW supports it though I don't have the setup here to test
> right now (but it was used before). In our controller it is
> pretty straight forward:
> 1) Enable interrupt for rr indication [source]
> 2) Enable update read on a rr [source]
> 3) Set rr flag in the sink [sink]
> 
> Point 2) makes it clear: Whenever we get a rr then the source
> will automatically read the sink and dump the contents read in
> the regbank. Then the SW gets an interrupt and it should read the
> contents of the registers.

Yes, I suspect that there will be three types of setups:

1) fully supported and integrated RR capability (such as in your
   case)

2) external I2C controller with the means of detecting the read
   request (and signal via an interrupt)

3) no read request support at all, in which case a delayed work
   queue is needed to poll periodically


For cases 1) and 3) it's probably only useful to have a helper to enable
scrambling. For 2) there might be some use in having a helper that can
setup the delayed work queue.

Given that we don't have any implementation yet, maybe it's better to
defer the creation of helpers until we see common patterns emerge. The
helper to enable scrambling could be useful in any case, though, so I'll
add one.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Jose Abreu]

Hi Thierry,


On 05-12-2016 11:14, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote:
>> Hi Thierry,
>>
>>
>> Do you think while you are at it you could implement a
>> set_scrambling() callback? It should be pretty straight forward:
>> you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
>> again.
>>
>>
>> I think this is an important feature that we should have.
> Yeah, agreed. I was actually thinking about going one step further and
> provide more of the polling functionality as a helper. Even if we have
> accessors that wrap the low-level functionality, most drivers would
> still have to provide their own delayed workqueue to deal with sinks
> (or sources) that don't support read requests. Having this in standard
> helpers would help reduce the boilerplate a lot further.
>
> Does your hardware by any chance support read requests on SCDC? It'd be
> interesting to see how that works in practice. Unfortunately Tegra does
> not seem to support it.
>
> Thierry

Yes, my HW supports it though I don't have the setup here to test
right now (but it was used before). In our controller it is
pretty straight forward:
1) Enable interrupt for rr indication [source]
2) Enable update read on a rr [source]
3) Set rr flag in the sink [sink]

Point 2) makes it clear: Whenever we get a rr then the source
will automatically read the sink and dump the contents read in
the regbank. Then the SW gets an interrupt and it should read the
contents of the registers.

>
>> On 02-12-2016 19:24, Thierry Reding wrote:
>>> From: Thierry Reding 
>>>
>>> Sinks that support SCDC can optionally have the capability to initiate
>>> read requests, which are a mechanism by which a sink can notify its
>>> source that it should read the Update Flags. If either the sink or the
>>> source are not Read Request capable, polling of the Update Flags shall
>>> be employed.
>>>
>>> Signed-off-by: Thierry Reding 
>>> ---
>>> Changes in v2:
>>> - new patch
>>>
>>>  drivers/gpu/drm/drm_edid.c | 36 
>>>  include/drm/drm_edid.h |  1 +
>>>  2 files changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 369961597ee5..8211cce3e09e 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -3736,6 +3736,42 @@ bool drm_detect_hdmi_scdc(struct edid *edid)
>>>  EXPORT_SYMBOL(drm_detect_hdmi_scdc);
>>>  
>>>  /**
>>> + * drm_detect_hdmi_scdc_rr_capable - detect whether an HDMI sink is 
>>> capable of
>>> + *initiating an SCDC Read Request
>>> + * @edid: sink EDID information
>>> + *
>>> + * Parse the CEA extension according to CEA-861-B to find an HF-VSDB as
>>> + * defined in HDMI 2.0, section 10.3.2 "HDMI Forum Vendor Specific Data
>>> + * Block" and checks if the RR_Capable bit (bit 6 of byte 6) is set.
>>> + *
>>> + * Returns:
>>> + * True if the sink is capable of initiating an SCDC Read Request, false
>>> + * otherwise.
>>> + */
>>> +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid)
>>> +{
>>> +   unsigned int start, end, i;
>>> +   const u8 *cea;
>>> +
>>> +   cea = drm_find_cea_extension(edid);
>>> +   if (!cea)
>>> +   return false;
>>> +
>>> +   if (cea_db_offsets(cea, , ))
>>> +   return false;
>>> +
>>> +   for_each_cea_db(cea, i, start, end) {
>>> +   if (cea_db_is_hdmi_forum_vsdb([i])) {
>>> +   if (cea[i + 6] & 0x40)
>>> +   return true;
>>> +   }
>>> +   }
>>> +
>>> +   return false;
>>> +}
>>> +EXPORT_SYMBOL(drm_detect_hdmi_scdc_rr_capable);
>>> +
>>> +/**
>>>   * drm_detect_monitor_audio - check monitor audio capability
>>>   * @edid: EDID block to scan
>>>   *
>>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>>> index 7ea7e90846d8..d1c29586035e 100644
>>> --- a/include/drm/drm_edid.h
>>> +++ b/include/drm/drm_edid.h
>>> @@ -441,6 +441,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
>>> *to_match);
>>>  enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
>>>  bool drm_detect_hdmi_monitor(struct edid *edid);
>>>  bool drm_detect_hdmi_scdc(struct edid *edid);
>>> +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid);
>>>  bool drm_detect_monitor_audio(struct edid *edid);
>>>  bool drm_rgb_quant_range_selectable(struct edid *edid);
>>>  int drm_add_modes_noedid(struct drm_connector *connector,

Best regards,
Jose Miguel Abreu

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Thierry Reding]

On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote:
> Hi Thierry,
> 
> 
> Do you think while you are at it you could implement a
> set_scrambling() callback? It should be pretty straight forward:
> you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
> again.
> 
> 
> I think this is an important feature that we should have.

Yeah, agreed. I was actually thinking about going one step further and
provide more of the polling functionality as a helper. Even if we have
accessors that wrap the low-level functionality, most drivers would
still have to provide their own delayed workqueue to deal with sinks
(or sources) that don't support read requests. Having this in standard
helpers would help reduce the boilerplate a lot further.

Does your hardware by any chance support read requests on SCDC? It'd be
interesting to see how that works in practice. Unfortunately Tegra does
not seem to support it.

Thierry

> On 02-12-2016 19:24, Thierry Reding wrote:
> > From: Thierry Reding 
> >
> > Sinks that support SCDC can optionally have the capability to initiate
> > read requests, which are a mechanism by which a sink can notify its
> > source that it should read the Update Flags. If either the sink or the
> > source are not Read Request capable, polling of the Update Flags shall
> > be employed.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> > Changes in v2:
> > - new patch
> >
> >  drivers/gpu/drm/drm_edid.c | 36 
> >  include/drm/drm_edid.h |  1 +
> >  2 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 369961597ee5..8211cce3e09e 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3736,6 +3736,42 @@ bool drm_detect_hdmi_scdc(struct edid *edid)
> >  EXPORT_SYMBOL(drm_detect_hdmi_scdc);
> >  
> >  /**
> > + * drm_detect_hdmi_scdc_rr_capable - detect whether an HDMI sink is 
> > capable of
> > + *initiating an SCDC Read Request
> > + * @edid: sink EDID information
> > + *
> > + * Parse the CEA extension according to CEA-861-B to find an HF-VSDB as
> > + * defined in HDMI 2.0, section 10.3.2 "HDMI Forum Vendor Specific Data
> > + * Block" and checks if the RR_Capable bit (bit 6 of byte 6) is set.
> > + *
> > + * Returns:
> > + * True if the sink is capable of initiating an SCDC Read Request, false
> > + * otherwise.
> > + */
> > +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid)
> > +{
> > +   unsigned int start, end, i;
> > +   const u8 *cea;
> > +
> > +   cea = drm_find_cea_extension(edid);
> > +   if (!cea)
> > +   return false;
> > +
> > +   if (cea_db_offsets(cea, , ))
> > +   return false;
> > +
> > +   for_each_cea_db(cea, i, start, end) {
> > +   if (cea_db_is_hdmi_forum_vsdb([i])) {
> > +   if (cea[i + 6] & 0x40)
> > +   return true;
> > +   }
> > +   }
> > +
> > +   return false;
> > +}
> > +EXPORT_SYMBOL(drm_detect_hdmi_scdc_rr_capable);
> > +
> > +/**
> >   * drm_detect_monitor_audio - check monitor audio capability
> >   * @edid: EDID block to scan
> >   *
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 7ea7e90846d8..d1c29586035e 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -441,6 +441,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> > *to_match);
> >  enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
> >  bool drm_detect_hdmi_monitor(struct edid *edid);
> >  bool drm_detect_hdmi_scdc(struct edid *edid);
> > +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid);
> >  bool drm_detect_monitor_audio(struct edid *edid);
> >  bool drm_rgb_quant_range_selectable(struct edid *edid);
> >  int drm_add_modes_noedid(struct drm_connector *connector,
> 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Jose Abreu]

Hi Thierry,


Do you think while you are at it you could implement a
set_scrambling() callback? It should be pretty straight forward:
you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
again.


I think this is an important feature that we should have.


Best regards,

Jose Miguel Abreu


On 02-12-2016 19:24, Thierry Reding wrote:
> From: Thierry Reding 
>
> Sinks that support SCDC can optionally have the capability to initiate
> read requests, which are a mechanism by which a sink can notify its
> source that it should read the Update Flags. If either the sink or the
> source are not Read Request capable, polling of the Update Flags shall
> be employed.
>
> Signed-off-by: Thierry Reding 
> ---
> Changes in v2:
> - new patch
>
>  drivers/gpu/drm/drm_edid.c | 36 
>  include/drm/drm_edid.h |  1 +
>  2 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 369961597ee5..8211cce3e09e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3736,6 +3736,42 @@ bool drm_detect_hdmi_scdc(struct edid *edid)
>  EXPORT_SYMBOL(drm_detect_hdmi_scdc);
>  
>  /**
> + * drm_detect_hdmi_scdc_rr_capable - detect whether an HDMI sink is capable 
> of
> + *initiating an SCDC Read Request
> + * @edid: sink EDID information
> + *
> + * Parse the CEA extension according to CEA-861-B to find an HF-VSDB as
> + * defined in HDMI 2.0, section 10.3.2 "HDMI Forum Vendor Specific Data
> + * Block" and checks if the RR_Capable bit (bit 6 of byte 6) is set.
> + *
> + * Returns:
> + * True if the sink is capable of initiating an SCDC Read Request, false
> + * otherwise.
> + */
> +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid)
> +{
> + unsigned int start, end, i;
> + const u8 *cea;
> +
> + cea = drm_find_cea_extension(edid);
> + if (!cea)
> + return false;
> +
> + if (cea_db_offsets(cea, , ))
> + return false;
> +
> + for_each_cea_db(cea, i, start, end) {
> + if (cea_db_is_hdmi_forum_vsdb([i])) {
> + if (cea[i + 6] & 0x40)
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +EXPORT_SYMBOL(drm_detect_hdmi_scdc_rr_capable);
> +
> +/**
>   * drm_detect_monitor_audio - check monitor audio capability
>   * @edid: EDID block to scan
>   *
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7ea7e90846d8..d1c29586035e 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -441,6 +441,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match);
>  enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
>  bool drm_detect_hdmi_monitor(struct edid *edid);
>  bool drm_detect_hdmi_scdc(struct edid *edid);
> +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid);
>  bool drm_detect_monitor_audio(struct edid *edid);
>  bool drm_rgb_quant_range_selectable(struct edid *edid);
>  int drm_add_modes_noedid(struct drm_connector *connector,

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Thierry Reding]

From: Thierry Reding 

Sinks that support SCDC can optionally have the capability to initiate
read requests, which are a mechanism by which a sink can notify its
source that it should read the Update Flags. If either the sink or the
source are not Read Request capable, polling of the Update Flags shall
be employed.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 drivers/gpu/drm/drm_edid.c | 36 
 include/drm/drm_edid.h |  1 +
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 369961597ee5..8211cce3e09e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3736,6 +3736,42 @@ bool drm_detect_hdmi_scdc(struct edid *edid)
 EXPORT_SYMBOL(drm_detect_hdmi_scdc);

 /**
+ * drm_detect_hdmi_scdc_rr_capable - detect whether an HDMI sink is capable of
+ *initiating an SCDC Read Request
+ * @edid: sink EDID information
+ *
+ * Parse the CEA extension according to CEA-861-B to find an HF-VSDB as
+ * defined in HDMI 2.0, section 10.3.2 "HDMI Forum Vendor Specific Data
+ * Block" and checks if the RR_Capable bit (bit 6 of byte 6) is set.
+ *
+ * Returns:
+ * True if the sink is capable of initiating an SCDC Read Request, false
+ * otherwise.
+ */
+bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid)
+{
+   unsigned int start, end, i;
+   const u8 *cea;
+
+   cea = drm_find_cea_extension(edid);
+   if (!cea)
+   return false;
+
+   if (cea_db_offsets(cea, , ))
+   return false;
+
+   for_each_cea_db(cea, i, start, end) {
+   if (cea_db_is_hdmi_forum_vsdb([i])) {
+   if (cea[i + 6] & 0x40)
+   return true;
+   }
+   }
+
+   return false;
+}
+EXPORT_SYMBOL(drm_detect_hdmi_scdc_rr_capable);
+
+/**
  * drm_detect_monitor_audio - check monitor audio capability
  * @edid: EDID block to scan
  *
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 7ea7e90846d8..d1c29586035e 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -441,6 +441,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match);
 enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
 bool drm_detect_hdmi_monitor(struct edid *edid);
 bool drm_detect_hdmi_scdc(struct edid *edid);
+bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid);
 bool drm_detect_monitor_audio(struct edid *edid);
 bool drm_rgb_quant_range_selectable(struct edid *edid);
 int drm_add_modes_noedid(struct drm_connector *connector,
-- 
2.10.2