* [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
* 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 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
* 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 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
* ✓ 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 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 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
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).