intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] drm/dp/i915: Fix DP link rate math
@ 2016-11-10  5:32 Dhinakaran Pandiyan
  2016-11-10  5:32 ` [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST Dhinakaran Pandiyan
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Dhinakaran Pandiyan @ 2016-11-10  5:32 UTC (permalink / raw)
  To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan

We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec are expressed in
Gbps/lane, which seems to have led to some confusion.

E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion

Using link clock frequency, like we do
Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
Because, each symbol has 8 bit of data, this is 2160000 kBps
and there is no need to account for channel encoding here.

But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps

Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * bpp * 1/8  to give the final
result in kBps

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++-------------------
 1 file changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..7a9e122 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 	return min(source_max, sink_max);
 }
 
-/*
- * The units on the numbers in the next two are... bizarre.  Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- *     270000 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000.  At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
 static int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
-	return (pixel_clock * bpp + 9) / 10;
+	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
+	return (pixel_clock * bpp + 7) / 8;
 }
 
 static int
 intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 {
-	return (max_link_clock * max_lanes * 8) / 10;
+	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+	 * link rate that is generally expressed in Gbps. Since, 8 bits data is
+	 * transmitted every LS_Clk per lane, there is no need to account for
+	 * the channel encoding that is done in the PHY layer here.
+	 */
+
+	return (max_link_clock * max_lanes);
 }
 
 static int
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
  2016-11-10  5:32 [PATCH 1/2] drm/dp/i915: Fix DP link rate math Dhinakaran Pandiyan
@ 2016-11-10  5:32 ` Dhinakaran Pandiyan
  2016-11-10 23:32   ` Manasi Navare
  2016-11-11 17:41   ` Ville Syrjälä
  2016-11-10  6:16 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp/i915: Fix DP link rate math Patchwork
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 13+ messages in thread
From: Dhinakaran Pandiyan @ 2016-11-10  5:32 UTC (permalink / raw)
  To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan

Not validating the the mode rate against link rate results not pruning
invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
support 4k @ 60Hz. But, we do not reject this mode currently.

So, make use of the helpers in intel_dp in validate mode rates against
max. data rate of a configuration.

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c     |  4 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
 drivers/gpu/drm/i915/intel_drv.h    |  2 ++
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7a9e122..7a73e43 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 	return min(source_max, sink_max);
 }
 
-static int
+int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
 	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
 	return (pixel_clock * bpp + 7) / 8;
 }
 
-static int
+int
 intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 {
 	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..38d2ce0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -335,7 +335,17 @@ static enum drm_mode_status
 intel_dp_mst_mode_valid(struct drm_connector *connector,
 			struct drm_display_mode *mode)
 {
+	struct intel_connector *intel_connector = to_intel_connector(connector);
+	struct intel_dp *intel_dp = intel_connector->mst_port;
 	int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+	int link_clock = intel_dp_max_link_rate(intel_dp);
+	int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+	int bpp = 24; /* MST uses fixed bpp */
+	int mode_rate;
+	int link_max_data_rate;
+
+	link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
+	mode_rate = intel_dp_link_required(mode->clock, bpp);
 
 	/* TODO - validate mode against available PBN for link */
 	if (mode->clock < 10000)
@@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
 	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
 		return MODE_H_ILLEGAL;
 
-	if (mode->clock > max_dotclk)
+	if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
 		return MODE_CLOCK_HIGH;
 
 	return MODE_OK;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2f3863..313419d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
 bool __intel_dp_read_desc(struct intel_dp *intel_dp,
 			  struct intel_dp_desc *desc);
 bool intel_dp_read_desc(struct intel_dp *intel_dp);
+int intel_dp_link_required(int pixel_clock, int bpp);
+int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
 
 /* intel_dp_aux_backlight.c */
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp/i915: Fix DP link rate math
  2016-11-10  5:32 [PATCH 1/2] drm/dp/i915: Fix DP link rate math Dhinakaran Pandiyan
  2016-11-10  5:32 ` [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST Dhinakaran Pandiyan
@ 2016-11-10  6:16 ` Patchwork
  2016-11-10 23:55 ` [PATCH 1/2] " Manasi Navare
  2016-11-11 13:39 ` Ville Syrjälä
  3 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2016-11-10  6:16 UTC (permalink / raw)
  To: Pandiyan, Dhinakaran; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/2] drm/dp/i915: Fix DP link rate math
URL   : https://patchwork.freedesktop.org/series/15084/
State : success

== Summary ==

Series 15084v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/15084/revisions/1/mbox/

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-a:
                fail       -> PASS       (fi-ivb-3520m)
        Subgroup suspend-read-crc-pipe-b:
                fail       -> PASS       (fi-ivb-3520m)
        Subgroup suspend-read-crc-pipe-c:
                fail       -> PASS       (fi-ivb-3520m)

fi-bdw-5557u     total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050     total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700     total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900     total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820     total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770      total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r     total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650       total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m     total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770      total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u     total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u     total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hq    total:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k     total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-snb-2520m     total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600      total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

1afd351596b6deaead14d5812f0d6850379e30ad drm-intel-nightly: 2016y-11m-09d-21h-03m-31s UTC integration manifest
6b5ad35 drm/i915/dp: Validate mode against max. link data rate for DP MST
e9bed5e drm/dp/i915: Fix DP link rate math

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2951/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
  2016-11-10  5:32 ` [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST Dhinakaran Pandiyan
@ 2016-11-10 23:32   ` Manasi Navare
  2016-11-14 21:35     ` Pandiyan, Dhinakaran
  2016-11-11 17:41   ` Ville Syrjälä
  1 sibling, 1 reply; 13+ messages in thread
From: Manasi Navare @ 2016-11-10 23:32 UTC (permalink / raw)
  To: Dhinakaran Pandiyan; +Cc: jani.nikula, intel-gfx

On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> Not validating the the mode rate against link rate results not pruning
> invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> support 4k @ 60Hz. But, we do not reject this mode currently.
> 
> So, make use of the helpers in intel_dp in validate mode rates against
> max. data rate of a configuration.
> 
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c     |  4 ++--
>  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
>  drivers/gpu/drm/i915/intel_drv.h    |  2 ++
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 7a9e122..7a73e43 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
>  	return min(source_max, sink_max);
>  }
>  
> -static int
> +int
>  intel_dp_link_required(int pixel_clock, int bpp)
>  {
>  	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
>  	return (pixel_clock * bpp + 7) / 8;
>  }
>  
> -static int
> +int
>  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>  {
>  	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..38d2ce0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -335,7 +335,17 @@ static enum drm_mode_status
>  intel_dp_mst_mode_valid(struct drm_connector *connector,
>  			struct drm_display_mode *mode)
>  {
> +	struct intel_connector *intel_connector = to_intel_connector(connector);
> +	struct intel_dp *intel_dp = intel_connector->mst_port;
>  	int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> +	int link_clock = intel_dp_max_link_rate(intel_dp);
> +	int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> +	int bpp = 24; /* MST uses fixed bpp */
> +	int mode_rate;
> +	int link_max_data_rate;

In the SST equivalent mode_valid function, this variable is named as
max_rate, I think you should name it as max_rate as well for consistency.
Other than that this looks good, we definitely need this for mode validation
at an early stage.

Regards
Manasi

> +
> +	link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> +	mode_rate = intel_dp_link_required(mode->clock, bpp);
>  
>  	/* TODO - validate mode against available PBN for link */
>  	if (mode->clock < 10000)
> @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
>  	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>  		return MODE_H_ILLEGAL;
>  
> -	if (mode->clock > max_dotclk)
> +	if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
>  		return MODE_CLOCK_HIGH;
>  
>  	return MODE_OK;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index c2f3863..313419d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
>  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
>  			  struct intel_dp_desc *desc);
>  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> +int intel_dp_link_required(int pixel_clock, int bpp);
> +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>  
>  /* intel_dp_aux_backlight.c */
>  int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] drm/dp/i915: Fix DP link rate math
  2016-11-10  5:32 [PATCH 1/2] drm/dp/i915: Fix DP link rate math Dhinakaran Pandiyan
  2016-11-10  5:32 ` [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST Dhinakaran Pandiyan
  2016-11-10  6:16 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp/i915: Fix DP link rate math Patchwork
@ 2016-11-10 23:55 ` Manasi Navare
  2016-11-11  3:03   ` Pandiyan, Dhinakaran
  2016-11-11 13:39 ` Ville Syrjälä
  3 siblings, 1 reply; 13+ messages in thread
From: Manasi Navare @ 2016-11-10 23:55 UTC (permalink / raw)
  To: Dhinakaran Pandiyan; +Cc: jani.nikula, intel-gfx

On Wed, Nov 09, 2016 at 09:32:29PM -0800, Dhinakaran Pandiyan wrote:
> We store DP link rates as link clock frequencies in kHz, just like all
> other clock values. But, DP link rates in the DP Spec are expressed in
> Gbps/lane, which seems to have led to some confusion.
> 
> E.g., for HBR2
> Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
> where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
> 
> Using link clock frequency, like we do
> Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
> Because, each symbol has 8 bit of data, this is 2160000 kBps
> and there is no need to account for channel encoding here.
> 
> But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
> 
> Similarly, while computing the required link bandwidth for a mode,
> there is a mysterious 1/10 term.
> This should simply be pixel_clock kHz * bpp * 1/8  to give the final
> result in kBps
> 
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++-------------------
>  1 file changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8f313c1..7a9e122 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
>  	return min(source_max, sink_max);
>  }
>  
> -/*
> - * The units on the numbers in the next two are... bizarre.  Examples will
> - * make it clearer; this one parallels an example in the eDP spec.
> - *
> - * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
> - *
> - *     270000 * 1 * 8 / 10 == 216000
> - *
> - * The actual data capacity of that configuration is 2.16Gbit/s, so the
> - * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
> - * or equivalently, kilopixels per second - so for 1680x1050R it'd be
> - * 119000.  At 18bpp that's 2142000 kilobits per second.
> - *
> - * Thus the strange-looking division by 10 in intel_dp_link_required, to
> - * get the result in decakilobits instead of kilobits.
> - */
> -
>  static int
>  intel_dp_link_required(int pixel_clock, int bpp)
>  {
> -	return (pixel_clock * bpp + 9) / 10;
> +	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> +	return (pixel_clock * bpp + 7) / 8;
>  }
>  
>  static int
>  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>  {
> -	return (max_link_clock * max_lanes * 8) / 10;
> +	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> +	 * link rate that is generally expressed in Gbps. Since, 8 bits data is
> +	 * transmitted every LS_Clk per lane, there is no need to account for
> +	 * the channel encoding that is done in the PHY layer here.
> +	 */
> +

Max Link is the max link rate for the actual physical link of the DP cable.
So eventually PHY layer is going to encode the bits and generate 10 bits
for every 8 bits, so the code rate will be 8/10 and the useful net rate (sending
useful bits) will be link_rate * code rate = link_rate * 8/10. 
So the max available link rate at the link layer should be this useful net rate
and so IMHO we should consider this channel encoding into account.

Manasi
> +	return (max_link_clock * max_lanes);
>  }
>  
>  static int
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] drm/dp/i915: Fix DP link rate math
  2016-11-10 23:55 ` [PATCH 1/2] " Manasi Navare
@ 2016-11-11  3:03   ` Pandiyan, Dhinakaran
  0 siblings, 0 replies; 13+ messages in thread
From: Pandiyan, Dhinakaran @ 2016-11-11  3:03 UTC (permalink / raw)
  To: Navare, Manasi D; +Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org

On Thu, 2016-11-10 at 15:55 -0800, Manasi Navare wrote:
> On Wed, Nov 09, 2016 at 09:32:29PM -0800, Dhinakaran Pandiyan wrote:
> > We store DP link rates as link clock frequencies in kHz, just like all
> > other clock values. But, DP link rates in the DP Spec are expressed in
> > Gbps/lane, which seems to have led to some confusion.
> > 
> > E.g., for HBR2
> > Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
> > where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
> > 
> > Using link clock frequency, like we do
> > Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
> > Because, each symbol has 8 bit of data, this is 2160000 kBps
> > and there is no need to account for channel encoding here.
> > 
> > But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
> > 
> > Similarly, while computing the required link bandwidth for a mode,
> > there is a mysterious 1/10 term.
> > This should simply be pixel_clock kHz * bpp * 1/8  to give the final
> > result in kBps
> > 
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++-------------------
> >  1 file changed, 9 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 8f313c1..7a9e122 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> >  	return min(source_max, sink_max);
> >  }
> >  
> > -/*
> > - * The units on the numbers in the next two are... bizarre.  Examples will
> > - * make it clearer; this one parallels an example in the eDP spec.
> > - *
> > - * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
> > - *
> > - *     270000 * 1 * 8 / 10 == 216000
> > - *
> > - * The actual data capacity of that configuration is 2.16Gbit/s, so the
> > - * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
> > - * or equivalently, kilopixels per second - so for 1680x1050R it'd be
> > - * 119000.  At 18bpp that's 2142000 kilobits per second.
> > - *
> > - * Thus the strange-looking division by 10 in intel_dp_link_required, to
> > - * get the result in decakilobits instead of kilobits.
> > - */
> > -
> >  static int
> >  intel_dp_link_required(int pixel_clock, int bpp)
> >  {
> > -	return (pixel_clock * bpp + 9) / 10;
> > +	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > +	return (pixel_clock * bpp + 7) / 8;
> >  }
> >  
> >  static int
> >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> >  {
> > -	return (max_link_clock * max_lanes * 8) / 10;
> > +	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > +	 * link rate that is generally expressed in Gbps. Since, 8 bits data is
> > +	 * transmitted every LS_Clk per lane, there is no need to account for
> > +	 * the channel encoding that is done in the PHY layer here.
> > +	 */
> > +
> 
> Max Link is the max link rate for the actual physical link of the DP cable.

The units are quite a mess, as the existing comments indicate.
For e.g., see
1. intel_dp_link_required()
""* The units on the numbers in the next two are... bizarre. ..."
2. intel_read_sink_rates()
" /* Value read is in kHz while drm clock is saved in deca-kHz */"

This has led to confusing /10's to just match the units to deca Hz and
deca kHz.


I believe, the confusion is due to the fact that,
1. eDP DPCD registers have link rates that have to be multiplied with
200kHz to get the final value in kHz. This is NOT the link symbol clock.
	e.g., DPCD SUPPORTED_LINK_RATES
	for HBR2, the value will be 27000 or 6978h (from DP Spec)

	To get the bit rate capacity
	= Link rate * Num. lanes * 8/10
	= 27000*200kHz * 4 * 8/10 = 17280000 kbits per second or 
	= 2160000 kBytes per second

	But, we arbitrarily divide by 10 in intel_edp_init_dpcd()
	"/* Value read is in kHz while drm clock is saved in deca-kHz */
 	intel_dp->sink_rates[i] = (val * 200) / 10; "


2. Let's look at source rates.

static const int bxt_rates[] = { 162000, 216000, 243000, 270000,
                                  324000, 432000, 540000 };
static const int skl_rates[] = { 162000, 216000, 270000,
                                  324000, 432000, 540000 };
static const int default_rates[] = { 162000, 270000, 540000 };


These cannot be link rates in Gbps nor link rate expressed in kHz.
If it is the link rate, HBR2 should be
5400000 Gbps or 54000000 kHz
But, the value is 540000. That's because, this is the Link Symbol Clock
(LS_Clk) in kHz

If you look at 

commit a4fc5ed69817c73e32571ad7837bb707f9890009
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Apr 7 16:16:42 2009 -0700

    drm/i915: Add Display Port support


you will see that the units all make sense, but somewhere in between we
have messed up the conversions.

To check if a mode is valid, the comparison should be between,
mode_clock(kHz)*bpp/8  and link_clock(kHz)*lanes , the units being kBps 
since 1 symbol corresponds to 1 byte of data.


-DK

> So eventually PHY layer is going to encode the bits and generate 10 bits
> for every 8 bits, so the code rate will be 8/10 and the useful net rate (sending
> useful bits) will be link_rate * code rate = link_rate * 8/10. 
> So the max available link rate at the link layer should be this useful net rate
> and so IMHO we should consider this channel encoding into account.
> 
> Manasi
> > +	return (max_link_clock * max_lanes);
> >  }
> >  
> >  static int
> > -- 
> > 2.7.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] drm/dp/i915: Fix DP link rate math
  2016-11-10  5:32 [PATCH 1/2] drm/dp/i915: Fix DP link rate math Dhinakaran Pandiyan
                   ` (2 preceding siblings ...)
  2016-11-10 23:55 ` [PATCH 1/2] " Manasi Navare
@ 2016-11-11 13:39 ` Ville Syrjälä
  2016-11-11 20:28   ` Pandiyan, Dhinakaran
  3 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2016-11-11 13:39 UTC (permalink / raw)
  To: Dhinakaran Pandiyan; +Cc: jani.nikula, intel-gfx

On Wed, Nov 09, 2016 at 09:32:29PM -0800, Dhinakaran Pandiyan wrote:
> We store DP link rates as link clock frequencies in kHz, just like all
> other clock values. But, DP link rates in the DP Spec are expressed in
> Gbps/lane, which seems to have led to some confusion.
> 
> E.g., for HBR2
> Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
> where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
> 
> Using link clock frequency, like we do
> Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
> Because, each symbol has 8 bit of data, this is 2160000 kBps
> and there is no need to account for channel encoding here.
> 
> But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
> 
> Similarly, while computing the required link bandwidth for a mode,
> there is a mysterious 1/10 term.
> This should simply be pixel_clock kHz * bpp * 1/8  to give the final
> result in kBps
> 
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++-------------------
>  1 file changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8f313c1..7a9e122 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
>  	return min(source_max, sink_max);
>  }
>  
> -/*
> - * The units on the numbers in the next two are... bizarre.  Examples will
> - * make it clearer; this one parallels an example in the eDP spec.
> - *
> - * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
> - *
> - *     270000 * 1 * 8 / 10 == 216000
> - *
> - * The actual data capacity of that configuration is 2.16Gbit/s, so the
> - * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
> - * or equivalently, kilopixels per second - so for 1680x1050R it'd be
> - * 119000.  At 18bpp that's 2142000 kilobits per second.
> - *
> - * Thus the strange-looking division by 10 in intel_dp_link_required, to
> - * get the result in decakilobits instead of kilobits.
> - */
> -
>  static int
>  intel_dp_link_required(int pixel_clock, int bpp)
>  {
> -	return (pixel_clock * bpp + 9) / 10;
> +	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/

Probably best not to mix in the kBps unit here and instead just talk
in terms of the symbol clock.

> +	return (pixel_clock * bpp + 7) / 8;

DIV_ROUND_UP()

>  }
>  
>  static int
>  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>  {
> -	return (max_link_clock * max_lanes * 8) / 10;
> +	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> +	 * link rate that is generally expressed in Gbps. Since, 8 bits data is
> +	 * transmitted every LS_Clk per lane, there is no need to account for
> +	 * the channel encoding that is done in the PHY layer here.
> +	 */
> +
> +	return (max_link_clock * max_lanes);

Useless parens.


>  }
>  
>  static int
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
  2016-11-10  5:32 ` [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST Dhinakaran Pandiyan
  2016-11-10 23:32   ` Manasi Navare
@ 2016-11-11 17:41   ` Ville Syrjälä
  2016-11-11 20:34     ` Pandiyan, Dhinakaran
  1 sibling, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2016-11-11 17:41 UTC (permalink / raw)
  To: Dhinakaran Pandiyan; +Cc: jani.nikula, intel-gfx

On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> Not validating the the mode rate against link rate results not pruning
> invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> support 4k @ 60Hz. But, we do not reject this mode currently.
> 
> So, make use of the helpers in intel_dp in validate mode rates against
> max. data rate of a configuration.
> 
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c     |  4 ++--
>  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
>  drivers/gpu/drm/i915/intel_drv.h    |  2 ++
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 7a9e122..7a73e43 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
>  	return min(source_max, sink_max);
>  }
>  
> -static int
> +int
>  intel_dp_link_required(int pixel_clock, int bpp)
>  {
>  	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
>  	return (pixel_clock * bpp + 7) / 8;
>  }
>  
> -static int
> +int
>  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>  {
>  	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..38d2ce0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -335,7 +335,17 @@ static enum drm_mode_status
>  intel_dp_mst_mode_valid(struct drm_connector *connector,
>  			struct drm_display_mode *mode)
>  {
> +	struct intel_connector *intel_connector = to_intel_connector(connector);
> +	struct intel_dp *intel_dp = intel_connector->mst_port;
>  	int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> +	int link_clock = intel_dp_max_link_rate(intel_dp);
> +	int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> +	int bpp = 24; /* MST uses fixed bpp */
> +	int mode_rate;
> +	int link_max_data_rate;
> +
> +	link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> +	mode_rate = intel_dp_link_required(mode->clock, bpp);
>  
>  	/* TODO - validate mode against available PBN for link */
>  	if (mode->clock < 10000)
> @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
>  	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>  		return MODE_H_ILLEGAL;
>  
> -	if (mode->clock > max_dotclk)
> +	if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
>  		return MODE_CLOCK_HIGH;
>  
>  	return MODE_OK;

You'll also want to fix intel_dp_mst_compute_config(). Actually that one
should check against the remaining link bw, but we don't track that
sufficiently well. Well, actually the topology manager does track it,
but just not atomically so it's not good enough in its current form.

But as a first step just checking against the total link bw would be an
improvement.

> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index c2f3863..313419d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
>  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
>  			  struct intel_dp_desc *desc);
>  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> +int intel_dp_link_required(int pixel_clock, int bpp);
> +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>  
>  /* intel_dp_aux_backlight.c */
>  int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] drm/dp/i915: Fix DP link rate math
  2016-11-11 13:39 ` Ville Syrjälä
@ 2016-11-11 20:28   ` Pandiyan, Dhinakaran
  0 siblings, 0 replies; 13+ messages in thread
From: Pandiyan, Dhinakaran @ 2016-11-11 20:28 UTC (permalink / raw)
  To: ville.syrjala@linux.intel.com
  Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org

On Fri, 2016-11-11 at 15:39 +0200, Ville Syrjälä wrote:
> On Wed, Nov 09, 2016 at 09:32:29PM -0800, Dhinakaran Pandiyan wrote:
> > We store DP link rates as link clock frequencies in kHz, just like all
> > other clock values. But, DP link rates in the DP Spec are expressed in
> > Gbps/lane, which seems to have led to some confusion.
> > 
> > E.g., for HBR2
> > Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
> > where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
> > 
> > Using link clock frequency, like we do
> > Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
> > Because, each symbol has 8 bit of data, this is 2160000 kBps
> > and there is no need to account for channel encoding here.
> > 
> > But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
> > 
> > Similarly, while computing the required link bandwidth for a mode,
> > there is a mysterious 1/10 term.
> > This should simply be pixel_clock kHz * bpp * 1/8  to give the final
> > result in kBps
> > 
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++-------------------
> >  1 file changed, 9 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 8f313c1..7a9e122 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> >  	return min(source_max, sink_max);
> >  }
> >  
> > -/*
> > - * The units on the numbers in the next two are... bizarre.  Examples will
> > - * make it clearer; this one parallels an example in the eDP spec.
> > - *
> > - * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
> > - *
> > - *     270000 * 1 * 8 / 10 == 216000
> > - *
> > - * The actual data capacity of that configuration is 2.16Gbit/s, so the
> > - * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
> > - * or equivalently, kilopixels per second - so for 1680x1050R it'd be
> > - * 119000.  At 18bpp that's 2142000 kilobits per second.
> > - *
> > - * Thus the strange-looking division by 10 in intel_dp_link_required, to
> > - * get the result in decakilobits instead of kilobits.
> > - */
> > -
> >  static int
> >  intel_dp_link_required(int pixel_clock, int bpp)
> >  {
> > -	return (pixel_clock * bpp + 9) / 10;
> > +	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> 
> Probably best not to mix in the kBps unit here and instead just talk
> in terms of the symbol clock.
> 
> > +	return (pixel_clock * bpp + 7) / 8;
> 
> DIV_ROUND_UP()
> 
> >  }
> >  
> >  static int
> >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> >  {
> > -	return (max_link_clock * max_lanes * 8) / 10;
> > +	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > +	 * link rate that is generally expressed in Gbps. Since, 8 bits data is
> > +	 * transmitted every LS_Clk per lane, there is no need to account for
> > +	 * the channel encoding that is done in the PHY layer here.
> > +	 */
> > +
> > +	return (max_link_clock * max_lanes);
> 
> Useless parens.
> 
> 

Thanks for the review, will fix these two lines.

-DK
> >  }
> >  
> >  static int
> > -- 
> > 2.7.4
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
  2016-11-11 17:41   ` Ville Syrjälä
@ 2016-11-11 20:34     ` Pandiyan, Dhinakaran
  0 siblings, 0 replies; 13+ messages in thread
From: Pandiyan, Dhinakaran @ 2016-11-11 20:34 UTC (permalink / raw)
  To: ville.syrjala@linux.intel.com
  Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org

On Fri, 2016-11-11 at 19:41 +0200, Ville Syrjälä wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. But, we do not reject this mode currently.
> > 
> > So, make use of the helpers in intel_dp in validate mode rates against
> > max. data rate of a configuration.
> > 
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c     |  4 ++--
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
> >  drivers/gpu/drm/i915/intel_drv.h    |  2 ++
> >  3 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 7a9e122..7a73e43 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> >  	return min(source_max, sink_max);
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_link_required(int pixel_clock, int bpp)
> >  {
> >  	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> >  	return (pixel_clock * bpp + 7) / 8;
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> >  {
> >  	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..38d2ce0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -335,7 +335,17 @@ static enum drm_mode_status
> >  intel_dp_mst_mode_valid(struct drm_connector *connector,
> >  			struct drm_display_mode *mode)
> >  {
> > +	struct intel_connector *intel_connector = to_intel_connector(connector);
> > +	struct intel_dp *intel_dp = intel_connector->mst_port;
> >  	int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > +	int link_clock = intel_dp_max_link_rate(intel_dp);
> > +	int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > +	int bpp = 24; /* MST uses fixed bpp */
> > +	int mode_rate;
> > +	int link_max_data_rate;
> > +
> > +	link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > +	mode_rate = intel_dp_link_required(mode->clock, bpp);
> >  
> >  	/* TODO - validate mode against available PBN for link */
> >  	if (mode->clock < 10000)
> > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> >  	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> >  		return MODE_H_ILLEGAL;
> >  
> > -	if (mode->clock > max_dotclk)
> > +	if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> >  		return MODE_CLOCK_HIGH;
> >  
> >  	return MODE_OK;
> 
> You'll also want to fix intel_dp_mst_compute_config(). Actually that one
> should check against the remaining link bw, but we don't track that
> sufficiently well. Well, actually the topology manager does track it,
> but just not atomically so it's not good enough in its current form.
> 
> But as a first step just checking against the total link bw would be an
> improvement.
> 

I am trying to understand why drm_dp_find_vcpi_slots() returns a value
greater than 64  in the 2 lane HBR2, 4k@60Hz config. Will send out this
patch once that is clear.

-DK


> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index c2f3863..313419d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> >  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> >  			  struct intel_dp_desc *desc);
> >  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > +int intel_dp_link_required(int pixel_clock, int bpp);
> > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >  
> >  /* intel_dp_aux_backlight.c */
> >  int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> > -- 
> > 2.7.4
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
  2016-11-10 23:32   ` Manasi Navare
@ 2016-11-14 21:35     ` Pandiyan, Dhinakaran
  2016-11-15 18:59       ` Ville Syrjälä
  0 siblings, 1 reply; 13+ messages in thread
From: Pandiyan, Dhinakaran @ 2016-11-14 21:35 UTC (permalink / raw)
  To: Navare, Manasi D; +Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org

On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. But, we do not reject this mode currently.
> > 
> > So, make use of the helpers in intel_dp in validate mode rates against
> > max. data rate of a configuration.
> > 
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c     |  4 ++--
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
> >  drivers/gpu/drm/i915/intel_drv.h    |  2 ++
> >  3 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 7a9e122..7a73e43 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> >  	return min(source_max, sink_max);
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_link_required(int pixel_clock, int bpp)
> >  {
> >  	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> >  	return (pixel_clock * bpp + 7) / 8;
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> >  {
> >  	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..38d2ce0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -335,7 +335,17 @@ static enum drm_mode_status
> >  intel_dp_mst_mode_valid(struct drm_connector *connector,
> >  			struct drm_display_mode *mode)
> >  {
> > +	struct intel_connector *intel_connector = to_intel_connector(connector);
> > +	struct intel_dp *intel_dp = intel_connector->mst_port;
> >  	int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > +	int link_clock = intel_dp_max_link_rate(intel_dp);
> > +	int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > +	int bpp = 24; /* MST uses fixed bpp */
> > +	int mode_rate;
> > +	int link_max_data_rate;
> 
> In the SST equivalent mode_valid function, this variable is named as
> max_rate, I think you should name it as max_rate as well for consistency.
> Other than that this looks good, we definitely need this for mode validation
> at an early stage.
> 
> Regards
> Manasi
> 

Well, one of the goals of Patch 1/2 is to reduce ambiguity that has led
to some confusing hacks. I prefer clarity over consistency and anyway
this variable is local to this function :)

-DK

> > +
> > +	link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > +	mode_rate = intel_dp_link_required(mode->clock, bpp);
> >  
> >  	/* TODO - validate mode against available PBN for link */
> >  	if (mode->clock < 10000)
> > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> >  	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> >  		return MODE_H_ILLEGAL;
> >  
> > -	if (mode->clock > max_dotclk)
> > +	if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> >  		return MODE_CLOCK_HIGH;
> >  
> >  	return MODE_OK;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index c2f3863..313419d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> >  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> >  			  struct intel_dp_desc *desc);
> >  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > +int intel_dp_link_required(int pixel_clock, int bpp);
> > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >  
> >  /* intel_dp_aux_backlight.c */
> >  int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> > -- 
> > 2.7.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
  2016-11-14 21:35     ` Pandiyan, Dhinakaran
@ 2016-11-15 18:59       ` Ville Syrjälä
  2016-11-15 20:57         ` Pandiyan, Dhinakaran
  0 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2016-11-15 18:59 UTC (permalink / raw)
  To: Pandiyan, Dhinakaran; +Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org

On Mon, Nov 14, 2016 at 09:35:30PM +0000, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> > On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > > Not validating the the mode rate against link rate results not pruning
> > > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > > support 4k @ 60Hz. But, we do not reject this mode currently.
> > > 
> > > So, make use of the helpers in intel_dp in validate mode rates against
> > > max. data rate of a configuration.
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c     |  4 ++--
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
> > >  drivers/gpu/drm/i915/intel_drv.h    |  2 ++
> > >  3 files changed, 15 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > index 7a9e122..7a73e43 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > >  	return min(source_max, sink_max);
> > >  }
> > >  
> > > -static int
> > > +int
> > >  intel_dp_link_required(int pixel_clock, int bpp)
> > >  {
> > >  	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > >  	return (pixel_clock * bpp + 7) / 8;
> > >  }
> > >  
> > > -static int
> > > +int
> > >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> > >  {
> > >  	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 3ffbd69..38d2ce0 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -335,7 +335,17 @@ static enum drm_mode_status
> > >  intel_dp_mst_mode_valid(struct drm_connector *connector,
> > >  			struct drm_display_mode *mode)
> > >  {
> > > +	struct intel_connector *intel_connector = to_intel_connector(connector);
> > > +	struct intel_dp *intel_dp = intel_connector->mst_port;
> > >  	int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > > +	int link_clock = intel_dp_max_link_rate(intel_dp);
> > > +	int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > > +	int bpp = 24; /* MST uses fixed bpp */
> > > +	int mode_rate;
> > > +	int link_max_data_rate;
> > 
> > In the SST equivalent mode_valid function, this variable is named as
> > max_rate, I think you should name it as max_rate as well for consistency.
> > Other than that this looks good, we definitely need this for mode validation
> > at an early stage.
> > 
> > Regards
> > Manasi
> > 
> 
> Well, one of the goals of Patch 1/2 is to reduce ambiguity that has led
> to some confusing hacks. I prefer clarity over consistency and anyway
> this variable is local to this function :)

I'm with Manasi on this one. Consistency wins. We have far too many
things we call by many names, and that always causes confusion. If you
think the name isn't good enough, then you should rename it across the
board.

> 
> -DK
> 
> > > +
> > > +	link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > > +	mode_rate = intel_dp_link_required(mode->clock, bpp);
> > >  
> > >  	/* TODO - validate mode against available PBN for link */
> > >  	if (mode->clock < 10000)
> > > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> > >  	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > >  		return MODE_H_ILLEGAL;
> > >  
> > > -	if (mode->clock > max_dotclk)
> > > +	if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> > >  		return MODE_CLOCK_HIGH;
> > >  
> > >  	return MODE_OK;
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > index c2f3863..313419d 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > >  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> > >  			  struct intel_dp_desc *desc);
> > >  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > > +int intel_dp_link_required(int pixel_clock, int bpp);
> > > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > >  
> > >  /* intel_dp_aux_backlight.c */
> > >  int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> > > -- 
> > > 2.7.4
> > > 
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
  2016-11-15 18:59       ` Ville Syrjälä
@ 2016-11-15 20:57         ` Pandiyan, Dhinakaran
  0 siblings, 0 replies; 13+ messages in thread
From: Pandiyan, Dhinakaran @ 2016-11-15 20:57 UTC (permalink / raw)
  To: ville.syrjala@linux.intel.com, Navare, Manasi D
  Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org

On Tue, 2016-11-15 at 20:59 +0200, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 09:35:30PM +0000, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> > > On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > > > Not validating the the mode rate against link rate results not pruning
> > > > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > > > support 4k @ 60Hz. But, we do not reject this mode currently.
> > > > 
> > > > So, make use of the helpers in intel_dp in validate mode rates against
> > > > max. data rate of a configuration.
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c     |  4 ++--
> > > >  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
> > > >  drivers/gpu/drm/i915/intel_drv.h    |  2 ++
> > > >  3 files changed, 15 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 7a9e122..7a73e43 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > > >  	return min(source_max, sink_max);
> > > >  }
> > > >  
> > > > -static int
> > > > +int
> > > >  intel_dp_link_required(int pixel_clock, int bpp)
> > > >  {
> > > >  	/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > > >  	return (pixel_clock * bpp + 7) / 8;
> > > >  }
> > > >  
> > > > -static int
> > > > +int
> > > >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> > > >  {
> > > >  	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > index 3ffbd69..38d2ce0 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > > @@ -335,7 +335,17 @@ static enum drm_mode_status
> > > >  intel_dp_mst_mode_valid(struct drm_connector *connector,
> > > >  			struct drm_display_mode *mode)
> > > >  {
> > > > +	struct intel_connector *intel_connector = to_intel_connector(connector);
> > > > +	struct intel_dp *intel_dp = intel_connector->mst_port;
> > > >  	int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > > > +	int link_clock = intel_dp_max_link_rate(intel_dp);
> > > > +	int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > > > +	int bpp = 24; /* MST uses fixed bpp */
> > > > +	int mode_rate;
> > > > +	int link_max_data_rate;
> > > 
> > > In the SST equivalent mode_valid function, this variable is named as
> > > max_rate, I think you should name it as max_rate as well for consistency.
> > > Other than that this looks good, we definitely need this for mode validation
> > > at an early stage.
> > > 
> > > Regards
> > > Manasi
> > > 
> > 
> > Well, one of the goals of Patch 1/2 is to reduce ambiguity that has led
> > to some confusing hacks. I prefer clarity over consistency and anyway
> > this variable is local to this function :)
> 
> I'm with Manasi on this one. Consistency wins. We have far too many
> things we call by many names, and that always causes confusion. If you
> think the name isn't good enough, then you should rename it across the
> board.
> 

Alright then, I don't want to bikeshed the variable naming anymore.
Sending another version.


> > 
> > -DK
> > 
> > > > +
> > > > +	link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > > > +	mode_rate = intel_dp_link_required(mode->clock, bpp);
> > > >  
> > > >  	/* TODO - validate mode against available PBN for link */
> > > >  	if (mode->clock < 10000)
> > > > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> > > >  	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > > >  		return MODE_H_ILLEGAL;
> > > >  
> > > > -	if (mode->clock > max_dotclk)
> > > > +	if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> > > >  		return MODE_CLOCK_HIGH;
> > > >  
> > > >  	return MODE_OK;
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > > index c2f3863..313419d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > >  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> > > >  			  struct intel_dp_desc *desc);
> > > >  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > > > +int intel_dp_link_required(int pixel_clock, int bpp);
> > > > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > >  
> > > >  /* intel_dp_aux_backlight.c */
> > > >  int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> > > > -- 
> > > > 2.7.4
> > > > 
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2016-11-15 20:57 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-10  5:32 [PATCH 1/2] drm/dp/i915: Fix DP link rate math Dhinakaran Pandiyan
2016-11-10  5:32 ` [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST Dhinakaran Pandiyan
2016-11-10 23:32   ` Manasi Navare
2016-11-14 21:35     ` Pandiyan, Dhinakaran
2016-11-15 18:59       ` Ville Syrjälä
2016-11-15 20:57         ` Pandiyan, Dhinakaran
2016-11-11 17:41   ` Ville Syrjälä
2016-11-11 20:34     ` Pandiyan, Dhinakaran
2016-11-10  6:16 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp/i915: Fix DP link rate math Patchwork
2016-11-10 23:55 ` [PATCH 1/2] " Manasi Navare
2016-11-11  3:03   ` Pandiyan, Dhinakaran
2016-11-11 13:39 ` Ville Syrjälä
2016-11-11 20:28   ` Pandiyan, Dhinakaran

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).