drm/i915: Adjust BXT HDMI port clock limits

Commit Message

Ville Syrjälä July 6, 2015, 11:44 a.m. UTC

From: Ville Syrjälä <[e-mail]>

Since
 commit e62925567c7926e78bc8ca976cde5c28ea265a49
 Author: Vandana Kannan <[e-mail]>
 Date:   Wed Jul 1 17:02:57 2015 +0530

    drm/i915/bxt: BUNs related to port PLL

BXT DPLL can now generate frequencies in the 216-223 MHz range.
Adjust the HDMI port clock checks to account for the reduced range
of invalid frequencies.

Cc: Vandana Kannan <[e-mail]>
Cc: Imre Deak <[e-mail]>
Signed-off-by: Ville Syrjälä <[e-mail]>
---
 drivers/gpu/drm/i915/intel_hdmi.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Comments

[e-mail] July 8, 2015, 9:37 a.m. UTC | #1

On 7/6/2015 5:14 PM, [e-mail] wrote:
> From: Ville Syrjälä <[e-mail]>
>
> Since
>   commit e62925567c7926e78bc8ca976cde5c28ea265a49
>   Author: Vandana Kannan <[e-mail]>
>   Date:   Wed Jul 1 17:02:57 2015 +0530
>
>      drm/i915/bxt: BUNs related to port PLL
>
> BXT DPLL can now generate frequencies in the 216-223 MHz range.
> Adjust the HDMI port clock checks to account for the reduced range
> of invalid frequencies.
>
> Cc: Vandana Kannan <[e-mail]>
> Cc: Imre Deak <[e-mail]>
> Signed-off-by: Ville Syrjälä <[e-mail]>
> ---
>   drivers/gpu/drm/i915/intel_hdmi.c | 9 ++++++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
> index c7e912b..70bad5b 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
>   	if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
>   		return MODE_CLOCK_HIGH;
>
> -	/* CHV/BXT DPLL can't generate 216-240 MHz */
> -	if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) &&
> -	    clock > 216000 && clock < 240000)
> +	/* BXT DPLL can't generate 223-240 MHz */
> +	if (IS_BROXTON(dev) && clock > 223333 && clock < 240000)
> +		return MODE_CLOCK_RANGE;
> +
BSpec needs an update based on this ?
It shows
"
HDMI/DVI link rates: 0.2 to 3.0 GHz Non-SSC*

*2.17 - 2.4 GHz not supported
"

- Vandana
> +	/* CHV DPLL can't generate 216-240 MHz */
> +	if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000)
>   		return MODE_CLOCK_RANGE;
>
>   	return MODE_OK;
>

Imre Deak July 10, 2015, 1:09 p.m. UTC | #2

On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:
> From: Ville Syrjälä <[e-mail]>
> 
> Since
>  commit e62925567c7926e78bc8ca976cde5c28ea265a49
>  Author: Vandana Kannan <[e-mail]>
>  Date:   Wed Jul 1 17:02:57 2015 +0530
> 
>     drm/i915/bxt: BUNs related to port PLL
> 
> BXT DPLL can now generate frequencies in the 216-223 MHz range.
> Adjust the HDMI port clock checks to account for the reduced range
> of invalid frequencies.
> 
> Cc: Vandana Kannan <[e-mail]>
> Cc: Imre Deak <[e-mail]>
> Signed-off-by: Ville Syrjälä <[e-mail]>

Ville wrote a tool for CHV that calculates the valid frequencies based
on the algorithm in the kernel. With the help of that I verified that
this matches the list of target frequencies bxt_find_best_dpll() will
accept, so:
Reviewed-by: Imre Deak <[e-mail]>

> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
> index c7e912b..70bad5b 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
>  	if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
>  		return MODE_CLOCK_HIGH;
>  
> -	/* CHV/BXT DPLL can't generate 216-240 MHz */
> -	if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) &&
> -	    clock > 216000 && clock < 240000)
> +	/* BXT DPLL can't generate 223-240 MHz */
> +	if (IS_BROXTON(dev) && clock > 223333 && clock < 240000)
> +		return MODE_CLOCK_RANGE;
> +
> +	/* CHV DPLL can't generate 216-240 MHz */
> +	if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000)
>  		return MODE_CLOCK_RANGE;
>  
>  	return MODE_OK;

Imre Deak July 10, 2015, 1:11 p.m. UTC | #3

On ke, 2015-07-08 at 15:07 +0530, Kannan, Vandana wrote:
> 
> On 7/6/2015 5:14 PM, [e-mail] wrote:
> > From: Ville Syrjälä <[e-mail]>
> >
> > Since
> >   commit e62925567c7926e78bc8ca976cde5c28ea265a49
> >   Author: Vandana Kannan <[e-mail]>
> >   Date:   Wed Jul 1 17:02:57 2015 +0530
> >
> >      drm/i915/bxt: BUNs related to port PLL
> >
> > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > Adjust the HDMI port clock checks to account for the reduced range
> > of invalid frequencies.
> >
> > Cc: Vandana Kannan <[e-mail]>
> > Cc: Imre Deak <[e-mail]>
> > Signed-off-by: Ville Syrjälä <[e-mail]>
> > ---
> >   drivers/gpu/drm/i915/intel_hdmi.c | 9 ++++++---
> >   1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
> > index c7e912b..70bad5b 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
> >   	if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
> >   		return MODE_CLOCK_HIGH;
> >
> > -	/* CHV/BXT DPLL can't generate 216-240 MHz */
> > -	if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) &&
> > -	    clock > 216000 && clock < 240000)
> > +	/* BXT DPLL can't generate 223-240 MHz */
> > +	if (IS_BROXTON(dev) && clock > 223333 && clock < 240000)
> > +		return MODE_CLOCK_RANGE;
> > +
> BSpec needs an update based on this ?
> It shows
> "
> HDMI/DVI link rates: 0.2 to 3.0 GHz Non-SSC*
> 
> *2.17 - 2.4 GHz not supported
> "

Yes, this needs updating. Could you file a change request for it?

--Imre

> 
> - Vandana
> > +	/* CHV DPLL can't generate 216-240 MHz */
> > +	if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000)
> >   		return MODE_CLOCK_RANGE;
> >
> >   	return MODE_OK;
> >

Lespiau, Damien July 10, 2015, 1:18 p.m. UTC | #4

On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:
> On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:
> > From: Ville Syrjälä <[e-mail]>
> > 
> > Since
> >  commit e62925567c7926e78bc8ca976cde5c28ea265a49
> >  Author: Vandana Kannan <[e-mail]>
> >  Date:   Wed Jul 1 17:02:57 2015 +0530
> > 
> >     drm/i915/bxt: BUNs related to port PLL
> > 
> > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > Adjust the HDMI port clock checks to account for the reduced range
> > of invalid frequencies.
> > 
> > Cc: Vandana Kannan <[e-mail]>
> > Cc: Imre Deak <[e-mail]>
> > Signed-off-by: Ville Syrjälä <[e-mail]>
> 
> Ville wrote a tool for CHV that calculates the valid frequencies based
> on the algorithm in the kernel. With the help of that I verified that
> this matches the list of target frequencies bxt_find_best_dpll() will
> accept, so:

Could we have that tool in i-g-t?

Ville Syrjälä July 10, 2015, 1:21 p.m. UTC | #5

On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote:
> On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:
> > On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:
> > > From: Ville Syrjälä <[e-mail]>
> > > 
> > > Since
> > >  commit e62925567c7926e78bc8ca976cde5c28ea265a49
> > >  Author: Vandana Kannan <[e-mail]>
> > >  Date:   Wed Jul 1 17:02:57 2015 +0530
> > > 
> > >     drm/i915/bxt: BUNs related to port PLL
> > > 
> > > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > > Adjust the HDMI port clock checks to account for the reduced range
> > > of invalid frequencies.
> > > 
> > > Cc: Vandana Kannan <[e-mail]>
> > > Cc: Imre Deak <[e-mail]>
> > > Signed-off-by: Ville Syrjälä <[e-mail]>
> > 
> > Ville wrote a tool for CHV that calculates the valid frequencies based
> > on the algorithm in the kernel. With the help of that I verified that
> > this matches the list of target frequencies bxt_find_best_dpll() will
> > accept, so:
> 
> Could we have that tool in i-g-t?

We could lift all the .find_dpll routines from the kernel into i-g-t.
The only real concern is that we'll forget to update the i-g-t copies
when changing the kernel. But I guess it would still be easier to just
update them slightly when noticing that rather than having to lift them
from the kernel all over again.

Lespiau, Damien July 10, 2015, 1:27 p.m. UTC | #6

On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote:
> > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:
> > > On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:
> > > > From: Ville Syrjälä <[e-mail]>
> > > > 
> > > > Since
> > > >  commit e62925567c7926e78bc8ca976cde5c28ea265a49
> > > >  Author: Vandana Kannan <[e-mail]>
> > > >  Date:   Wed Jul 1 17:02:57 2015 +0530
> > > > 
> > > >     drm/i915/bxt: BUNs related to port PLL
> > > > 
> > > > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > > > Adjust the HDMI port clock checks to account for the reduced range
> > > > of invalid frequencies.
> > > > 
> > > > Cc: Vandana Kannan <[e-mail]>
> > > > Cc: Imre Deak <[e-mail]>
> > > > Signed-off-by: Ville Syrjälä <[e-mail]>
> > > 
> > > Ville wrote a tool for CHV that calculates the valid frequencies based
> > > on the algorithm in the kernel. With the help of that I verified that
> > > this matches the list of target frequencies bxt_find_best_dpll() will
> > > accept, so:
> > 
> > Could we have that tool in i-g-t?
> 
> We could lift all the .find_dpll routines from the kernel into i-g-t.
> The only real concern is that we'll forget to update the i-g-t copies
> when changing the kernel. But I guess it would still be easier to just
> update them slightly when noticing that rather than having to lift them
> from the kernel all over again.

Right, while not ideal, I think having something in i-g-t, even if it
diverges slightly (but then we can remind the patch author to update the
i-g-t tool during review) is still better than not having that code
around at all.

Shuang He July 10, 2015, 8:22 p.m. UTC | #7

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: [e-mail])
Task id: 6726
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
ILK                                  303/303              303/303
SNB              +3                 309/316              312/316
IVB                                  343/343              343/343
BYT                                  285/285              285/285
HSW              +13                 367/381              380/381
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
*SNB  igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip      DMESG_WARN(1)      PASS(1)
*SNB  igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip      DMESG_WARN(1)      PASS(1)
*SNB  igt@pm_rpm@cursor      DMESG_WARN(1)      PASS(1)
*SNB  igt@pm_rpm@cursor-dpms      DMESG_FAIL(1)      FAIL(1)
*HSW  igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_lpsp@non-edp      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@debugfs-read      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@gem-idle      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@gem-mmap-gtt      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@gem-pread      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@i2c      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@modeset-non-lpsp      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@modeset-non-lpsp-stress-no-wait      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@pci-d3-state      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@reg-read-ioctl      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@rte      DMESG_WARN(1)      PASS(1)
*HSW  igt@pm_rpm@sysfs-read      DMESG_WARN(1)      PASS(1)
Note: You need to pay more attention to line start with '*'

Daniel Vetter July 13, 2015, 9:05 a.m. UTC | #8

On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote:
> On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote:
> > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote:
> > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:
> > > > On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:
> > > > > From: Ville Syrjälä <[e-mail]>
> > > > > 
> > > > > Since
> > > > >  commit e62925567c7926e78bc8ca976cde5c28ea265a49
> > > > >  Author: Vandana Kannan <[e-mail]>
> > > > >  Date:   Wed Jul 1 17:02:57 2015 +0530
> > > > > 
> > > > >     drm/i915/bxt: BUNs related to port PLL
> > > > > 
> > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > > > > Adjust the HDMI port clock checks to account for the reduced range
> > > > > of invalid frequencies.
> > > > > 
> > > > > Cc: Vandana Kannan <[e-mail]>
> > > > > Cc: Imre Deak <[e-mail]>
> > > > > Signed-off-by: Ville Syrjälä <[e-mail]>
> > > > 
> > > > Ville wrote a tool for CHV that calculates the valid frequencies based
> > > > on the algorithm in the kernel. With the help of that I verified that
> > > > this matches the list of target frequencies bxt_find_best_dpll() will
> > > > accept, so:
> > > 
> > > Could we have that tool in i-g-t?
> > 
> > We could lift all the .find_dpll routines from the kernel into i-g-t.
> > The only real concern is that we'll forget to update the i-g-t copies
> > when changing the kernel. But I guess it would still be easier to just
> > update them slightly when noticing that rather than having to lift them
> > from the kernel all over again.
> 
> Right, while not ideal, I think having something in i-g-t, even if it
> diverges slightly (but then we can remind the patch author to update the
> i-g-t tool during review) is still better than not having that code
> around at all.

Another way to check this would be to inject EDIDs with hand-rolled
timings that increment in small steps. Then we can try modesets on all the
unfiltered ones vs. just manually adding it with addmode. If any mode gets
filtered inconsistently in the mode list parsing compared to modeset code
that would be a bug.

Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira
for this idea.
-Daniel

Daniel Vetter July 13, 2015, 9:10 a.m. UTC | #9

On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:
> On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:
> > From: Ville Syrjälä <[e-mail]>
> > 
> > Since
> >  commit e62925567c7926e78bc8ca976cde5c28ea265a49
> >  Author: Vandana Kannan <[e-mail]>
> >  Date:   Wed Jul 1 17:02:57 2015 +0530
> > 
> >     drm/i915/bxt: BUNs related to port PLL
> > 
> > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > Adjust the HDMI port clock checks to account for the reduced range
> > of invalid frequencies.
> > 
> > Cc: Vandana Kannan <[e-mail]>
> > Cc: Imre Deak <[e-mail]>
> > Signed-off-by: Ville Syrjälä <[e-mail]>
> 
> Ville wrote a tool for CHV that calculates the valid frequencies based
> on the algorithm in the kernel. With the help of that I verified that
> this matches the list of target frequencies bxt_find_best_dpll() will
> accept, so:
> Reviewed-by: Imre Deak <[e-mail]>

Queued for -next, thanks for the patch.
-Daniel

Bish, Jim July 13, 2015, 5:32 p.m. UTC | #10

On Mon, 2015-07-13 at 11:05 +0200, Daniel Vetter wrote:
> On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote:

> > On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote:

> > > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote:

> > > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:

> > > > > On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:

> > > > > > From: Ville Syrjälä <[e-mail]>

> > > > > > 

> > > > > > Since

> > > > > >  commit e62925567c7926e78bc8ca976cde5c28ea265a49

> > > > > >  Author: Vandana Kannan <[e-mail]>

> > > > > >  Date:   Wed Jul 1 17:02:57 2015 +0530

> > > > > > 

> > > > > >     drm/i915/bxt: BUNs related to port PLL

> > > > > > 

> > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range.

> > > > > > Adjust the HDMI port clock checks to account for the reduced range

> > > > > > of invalid frequencies.

> > > > > > 

> > > > > > Cc: Vandana Kannan <[e-mail]>

> > > > > > Cc: Imre Deak <[e-mail]>

> > > > > > Signed-off-by: Ville Syrjälä <[e-mail]>

> > > > > 

> > > > > Ville wrote a tool for CHV that calculates the valid frequencies based

> > > > > on the algorithm in the kernel. With the help of that I verified that

> > > > > this matches the list of target frequencies bxt_find_best_dpll() will

> > > > > accept, so:

> > > > 

> > > > Could we have that tool in i-g-t?

> > > 

> > > We could lift all the .find_dpll routines from the kernel into i-g-t.

> > > The only real concern is that we'll forget to update the i-g-t copies

> > > when changing the kernel. But I guess it would still be easier to just

> > > update them slightly when noticing that rather than having to lift them

> > > from the kernel all over again.

> > 

> > Right, while not ideal, I think having something in i-g-t, even if it

> > diverges slightly (but then we can remind the patch author to update the

> > i-g-t tool during review) is still better than not having that code

> > around at all.

> 

> Another way to check this would be to inject EDIDs with hand-rolled

> timings that increment in small steps. Then we can try modesets on all the

> unfiltered ones vs. just manually adding it with addmode. If any mode gets

> filtered inconsistently in the mode list parsing compared to modeset code

> that would be a bug.

> 

> Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira

> for this idea.

> -Daniel


if you have dr. HDMI device you can set custom EDID in slots 6 and 7 -
works great for this type of exercise with no additional necessary to
try out.

Jim

Daniel Vetter July 14, 2015, 7:53 a.m. UTC | #11

On Mon, Jul 13, 2015 at 05:32:14PM +0000, Bish, Jim wrote:
> On Mon, 2015-07-13 at 11:05 +0200, Daniel Vetter wrote:
> > On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote:
> > > On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote:
> > > > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:
> > > > > > On ma, 2015-07-06 at 14:44 +0300, [e-mail] wrote:
> > > > > > > From: Ville Syrjälä <[e-mail]>
> > > > > > > 
> > > > > > > Since
> > > > > > >  commit e62925567c7926e78bc8ca976cde5c28ea265a49
> > > > > > >  Author: Vandana Kannan <[e-mail]>
> > > > > > >  Date:   Wed Jul 1 17:02:57 2015 +0530
> > > > > > > 
> > > > > > >     drm/i915/bxt: BUNs related to port PLL
> > > > > > > 
> > > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > > > > > > Adjust the HDMI port clock checks to account for the reduced range
> > > > > > > of invalid frequencies.
> > > > > > > 
> > > > > > > Cc: Vandana Kannan <[e-mail]>
> > > > > > > Cc: Imre Deak <[e-mail]>
> > > > > > > Signed-off-by: Ville Syrjälä <[e-mail]>
> > > > > > 
> > > > > > Ville wrote a tool for CHV that calculates the valid frequencies based
> > > > > > on the algorithm in the kernel. With the help of that I verified that
> > > > > > this matches the list of target frequencies bxt_find_best_dpll() will
> > > > > > accept, so:
> > > > > 
> > > > > Could we have that tool in i-g-t?
> > > > 
> > > > We could lift all the .find_dpll routines from the kernel into i-g-t.
> > > > The only real concern is that we'll forget to update the i-g-t copies
> > > > when changing the kernel. But I guess it would still be easier to just
> > > > update them slightly when noticing that rather than having to lift them
> > > > from the kernel all over again.
> > > 
> > > Right, while not ideal, I think having something in i-g-t, even if it
> > > diverges slightly (but then we can remind the patch author to update the
> > > i-g-t tool during review) is still better than not having that code
> > > around at all.
> > 
> > Another way to check this would be to inject EDIDs with hand-rolled
> > timings that increment in small steps. Then we can try modesets on all the
> > unfiltered ones vs. just manually adding it with addmode. If any mode gets
> > filtered inconsistently in the mode list parsing compared to modeset code
> > that would be a bug.
> > 
> > Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira
> > for this idea.
> > -Daniel
> 
> if you have dr. HDMI device you can set custom EDID in slots 6 and 7 -
> works great for this type of exercise with no additional necessary to
> try out.

The idea is to be able to run the testsuite with bare-bones machines and
no need to send each developer a special piece of hw for each type of
output. I know that there are tons of hw solutions for these testing
problems, they don't seem to scale well enough.
-Daniel

Patch

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index c7e912b..70bad5b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1174,9 +1174,12 @@  hdmi_port_clock_valid(struct intel_hdmi *hdmi,
 	if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
 		return MODE_CLOCK_HIGH;
 
-	/* CHV/BXT DPLL can't generate 216-240 MHz */
-	if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) &&
-	    clock > 216000 && clock < 240000)
+	/* BXT DPLL can't generate 223-240 MHz */
+	if (IS_BROXTON(dev) && clock > 223333 && clock < 240000)
+		return MODE_CLOCK_RANGE;
+
+	/* CHV DPLL can't generate 216-240 MHz */
+	if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000)
 		return MODE_CLOCK_RANGE;
 
 	return MODE_OK;