Re: [Intel-gfx] [RFC 4/8] drm/i915: Group gen 10 display.

[Jani Nikula]

On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> Continuing with the goal of use less platform codenames:
> let's group platforms who has gen10 display.

Ahah, so this answers my question in the previous patch. ;)

So we already have HAS_GMCH_DISPLAY().

If we're going to make gen10 display a thing, should we not generalize
this to have an actual display gen in device info? Of course for most
platforms it's going to be identical to the gem gen.

The question becomes, is display gen accurate enough? It's not enough to
cover all of Geminilake I believe. Which makes me think, should we just
add tons more device info flags to cover features at a detailed level? I
think that's what Joonas advocates. Perhaps it bloats the device info,
and causes increase in the number of device info blocks. But my gut
feeling says together with truly immutable device info, there are
compiler optimization benefits to be had.

Also, currently we "inherit" device info using truly obnoxious macro
layering where you have to work hard to trace the macros to find out
what is set for a given platform. It doesn't have to be that way. We
could move parts of it to separate but shared features structs, and add
pointers to them.

Anyway, thanks for rolling this series as a starting point for
discussion. Even if I'm not buying the changes as-is. ;)


BR,
Jani.

>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
>  drivers/gpu/drm/i915/intel_cdclk.c   | 2 +-
>  drivers/gpu/drm/i915/intel_color.c   | 2 +-
>  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>  drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
>  5 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d19b38ef145b..6436fedfe561 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2637,6 +2637,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define SUPPORTS_TV(dev_priv)((dev_priv)->info.supports_tv)
>  #define I915_HAS_HOTPLUG(dev_priv)   ((dev_priv)->info.has_hotplug)
>  
> +#define HAS_DISPLAY_10(dev_priv) (IS_GEN10(dev_priv) || 
> IS_GEMINILAKE(dev_priv))
> +
>  #define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2)
>  #define HAS_FBC(dev_priv)((dev_priv)->info.has_fbc)
>  #define HAS_CUR_FBC(dev_priv)(!HAS_GMCH_DISPLAY(dev_priv) && 
> INTEL_GEN(dev_priv) >= 7)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 4aa6500604cc..b315b70fd49c 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -2181,7 +2181,7 @@ int intel_crtc_compute_min_cdclk(const struct 
> intel_crtc_state *crtc_state)
>   crtc_state->has_audio &&
>   crtc_state->port_clock >= 54 &&
>   crtc_state->lane_count == 4) {
> - if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
> + if (HAS_DISPLAY_10(dev_priv)) {
>   /* Display WA #1145: glk,cnl */
>   min_cdclk = max(316800, min_cdclk);
>   } else if (IS_GEN9(dev_priv) || IS_BROADWELL(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/intel_color.c 
> b/drivers/gpu/drm/i915/intel_color.c
> index 5127da286a2b..d5f67b9c9698 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -659,7 +659,7 @@ void intel_color_init(struct drm_crtc *crtc)
>  IS_BROXTON(dev_priv)) {
>   dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
>   dev_priv->display.load_luts = broadwell_load_luts;
> - } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> + } else if (HAS_DISPLAY_10(dev_priv)) {
>   dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
>   dev_priv->display.load_luts = glk_load_luts;
>   } else {
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7b04b8436b6d..1abf79a4ee91 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5730,7 +5730,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   intel_crtc->active = true;
>  
>   /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
> - psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> + psl_clkgate_wa = (HAS_DISPLAY_10(dev_priv)) &&
>pipe_config->pch_pfit.enabled;
>   if (psl_clkgate_wa)
>   glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
> @@ -15565,7 +15565,7 @@ get_encoder_power_domains(struct drm_i915_private 
> *dev_priv)
>  static void intel_early_display_was(struct drm_i915_private *dev_priv)
>  {
>   /* Display WA #1185 WaDisableDARBFClkGating:cnl,glk */
> - if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> + if (HAS_DISPLAY_10(dev_priv))
>   

Re: [Intel-gfx] [RFC 5/8] drm/i915/gen11+: Prefer gen over platform codename.

[Jani Nikula]

On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> Also let's always consider next platform follows
> the most recent one. Like we have done for transitioning
> gen9 to gen10 and gent10 to gen11.
>
> Let's use same approach for gen11+ and only introduce
> changes later as needed.

Same worry as with Geminilake. The gen is essentially the gem gen, not
display gen.

BR,
Jani.

>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c  |  6 +++---
>  drivers/gpu/drm/i915/intel_ddi.c| 18 +-
>  drivers/gpu/drm/i915/intel_display.c|  8 
>  drivers/gpu/drm/i915/intel_dpll_mgr.c   |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c   |  2 +-
>  drivers/gpu/drm/i915/intel_mocs.c   |  3 +--
>  drivers/gpu/drm/i915/intel_pm.c |  4 ++--
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  6 +++---
>  8 files changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index b315b70fd49c..915e2c93412b 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -2572,7 +2572,7 @@ static int intel_compute_max_dotclk(struct 
> drm_i915_private *dev_priv)
>   */
>  void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
>  {
> - if (IS_ICELAKE(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 11) {
>   if (dev_priv->cdclk.hw.ref == 24000)
>   dev_priv->max_cdclk_freq = 648000;
>   else
> @@ -2801,12 +2801,12 @@ void intel_init_cdclk_hooks(struct drm_i915_private 
> *dev_priv)
>   dev_priv->display.set_cdclk = cnl_set_cdclk;
>   dev_priv->display.modeset_calc_cdclk =
>   cnl_modeset_calc_cdclk;
> - } else if (IS_ICELAKE(dev_priv)) {
> + } else if (INTEL_GEN(dev_priv) >= 11) {
>   dev_priv->display.set_cdclk = icl_set_cdclk;
>   dev_priv->display.modeset_calc_cdclk = icl_modeset_calc_cdclk;
>   }
>  
> - if (IS_ICELAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 11)
>   dev_priv->display.get_cdclk = icl_get_cdclk;
>   else if (IS_GEN10(dev_priv))
>   dev_priv->display.get_cdclk = cnl_get_cdclk;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cd627851f2a5..10b5314f266c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -915,7 +915,7 @@ static int intel_ddi_hdmi_level(struct drm_i915_private 
> *dev_priv, enum port por
>  
>   level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
>  
> - if (IS_ICELAKE(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 11) {
>   if (intel_port_is_combophy(dev_priv, port))
>   icl_get_combo_buf_trans(dev_priv, port,
>   INTEL_OUTPUT_HDMI, _entries);
> @@ -1745,7 +1745,7 @@ static void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>   bxt_ddi_clock_get(encoder, pipe_config);
>   else if (IS_GEN10(dev_priv))
>   cnl_ddi_clock_get(encoder, pipe_config);
> - else if (IS_ICELAKE(dev_priv))
> + else if (INTEL_GEN(dev_priv) >= 11)
>   icl_ddi_clock_get(encoder, pipe_config);
>  }
>  
> @@ -2241,7 +2241,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder 
> *encoder)
>   enum port port = encoder->port;
>   int n_entries;
>  
> - if (IS_ICELAKE(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 11) {
>   if (intel_port_is_combophy(dev_priv, port))
>   icl_get_combo_buf_trans(dev_priv, port, encoder->type,
>   _entries);
> @@ -2716,7 +2716,7 @@ u32 bxt_signal_levels(struct intel_dp *intel_dp)
>   struct intel_encoder *encoder = >base;
>   int level = intel_ddi_dp_level(intel_dp);
>  
> - if (IS_ICELAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 11)
>   icl_ddi_vswing_sequence(encoder, intel_dp->link_rate,
>   level, encoder->type);
>   else if (IS_GEN10(dev_priv))
> @@ -2833,7 +2833,7 @@ static void intel_ddi_clk_select(struct intel_encoder 
> *encoder,
>  
>   mutex_lock(_priv->dpll_lock);
>  
> - if (IS_ICELAKE(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 11) {
>   if (!intel_port_is_combophy(dev_priv, port))
>   I915_WRITE(DDI_CLK_SEL(port),
>  icl_pll_to_ddi_pll_sel(encoder, crtc_state));
> @@ -2875,7 +2875,7 @@ static void intel_ddi_clk_disable(struct intel_encoder 
> *encoder)
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = encoder->port;
>  
> - if (IS_ICELAKE(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 11) {
>   if (!intel_port_is_combophy(dev_priv, port))
>   I915_WRITE(DDI_CLK_SEL(port), DDI_CLK_SEL_NONE);
>   } else if 

Re: [Intel-gfx] [RFC 7/8] drm/i915: Sort platform if cases from newer-to-older.

[Jani Nikula]

On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> Let's use this whenever it makes sense and code gets
> easier to read.

Ack on this general direction.

BR,
Jani.


>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c| 18 +-
>  drivers/gpu/drm/i915/intel_dp.c | 24 +---
>  drivers/gpu/drm/i915/intel_pm.c |  6 +++---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
>  drivers/gpu/drm/i915/intel_uncore.c |  2 +-
>  5 files changed, 32 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 10b5314f266c..498521a3bc21 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1737,16 +1737,16 @@ static void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>  
> - if (INTEL_GEN(dev_priv) <= 8)
> - hsw_ddi_clock_get(encoder, pipe_config);
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_ddi_clock_get(encoder, pipe_config);
> + else if (IS_GEN10(dev_priv))
> + cnl_ddi_clock_get(encoder, pipe_config);
>   else if (IS_GEN9_BC(dev_priv))
>   skl_ddi_clock_get(encoder, pipe_config);
>   else if (IS_GEN9_LP(dev_priv))
>   bxt_ddi_clock_get(encoder, pipe_config);
> - else if (IS_GEN10(dev_priv))
> - cnl_ddi_clock_get(encoder, pipe_config);
> - else if (INTEL_GEN(dev_priv) >= 11)
> - icl_ddi_clock_get(encoder, pipe_config);
> + else if (INTEL_GEN(dev_priv) <= 8)
> + hsw_ddi_clock_get(encoder, pipe_config);
>  }
>  
>  void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
> @@ -3373,10 +3373,10 @@ static bool intel_ddi_is_audio_enabled(struct 
> drm_i915_private *dev_priv,
>  void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
>struct intel_crtc_state *crtc_state)
>  {
> - if (IS_GEN10(dev_priv) && crtc_state->port_clock > 594000)
> - crtc_state->min_voltage_level = 2;
> - else if (INTEL_GEN(dev_priv) >= 11 && crtc_state->port_clock > 594000)
> + if (INTEL_GEN(dev_priv) >= 11 && crtc_state->port_clock > 594000)
>   crtc_state->min_voltage_level = 1;
> + else if (IS_GEN10(dev_priv) && crtc_state->port_clock > 594000)
> + crtc_state->min_voltage_level = 2;
>  }
>  
>  void intel_ddi_get_config(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0ea0414ccef4..3c13a49b4a7a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5035,20 +5035,22 @@ bool intel_digital_port_connected(struct 
> intel_encoder *encoder)
>   return g4x_digital_port_connected(encoder);
>   }
>  
> - if (IS_GEN5(dev_priv))
> - return ilk_digital_port_connected(encoder);
> - else if (IS_GEN6(dev_priv))
> - return snb_digital_port_connected(encoder);
> - else if (IS_GEN7(dev_priv))
> - return ivb_digital_port_connected(encoder);
> - else if (IS_GEN8(dev_priv))
> - return bdw_digital_port_connected(encoder);
> + if (INTEL_GEN(dev_priv) >= 11)
> + return icl_digital_port_connected(encoder);
> + else if (IS_GEN10(dev_priv) || IS_GEN9_BC(dev_priv))
> + return spt_digital_port_connected(encoder);
>   else if (IS_GEN9_LP(dev_priv))
>   return bxt_digital_port_connected(encoder);
> - else if (IS_GEN9_BC(dev_priv) || IS_GEN10(dev_priv))
> - return spt_digital_port_connected(encoder);
> + else if (IS_GEN8(dev_priv))
> + return bdw_digital_port_connected(encoder);
> + else if (IS_GEN7(dev_priv))
> + return ivb_digital_port_connected(encoder);
> + else if (IS_GEN6(dev_priv))
> + return snb_digital_port_connected(encoder);
> + else if (IS_GEN5(dev_priv))
> + return ilk_digital_port_connected(encoder);
>   else
> - return icl_digital_port_connected(encoder);
> + return false;
>  }
>  
>  static struct edid *
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f4b7fd132173..5663b7059467 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3724,12 +3724,12 @@ bool intel_can_enable_sagv(struct drm_atomic_state 
> *state)
>   if (!intel_has_sagv(dev_priv))
>   return false;
>  
> - if (IS_GEN9(dev_priv))
> - sagv_block_time_us = 30;
> + if (INTEL_GEN(dev_priv) >= 11)
> + sagv_block_time_us = 10;
>   else if (IS_GEN10(dev_priv))
>   sagv_block_time_us = 20;
>   else
> - sagv_block_time_us = 10;
> + sagv_block_time_us = 30;
>  
>   

Re: [Intel-gfx] [RFC 8/8] drm/i915: Simplify intel_has_sagv function.

[Jani Nikula]

On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> Let's just handle SKL as special case instead of listing
> platform by platform.
>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5663b7059467..97f191b081e0 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3612,15 +3612,11 @@ static bool skl_needs_memory_bw_wa(struct 
> intel_atomic_state *state)
>  static bool
>  intel_has_sagv(struct drm_i915_private *dev_priv)
>  {
> - if (INTEL_GEN(dev_priv) >= 10 ||
> - IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
> - return true;
> -
>   if (IS_SKYLAKE(dev_priv) &&
>   dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED)
>   return true;
>  
> - return false;
> + return IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10;
>  }

You can go one step further and remove the Skylake special case even for
I915_SAGV_NOT_CONTROLLED:

return (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) && 
dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;

dev_priv->sagv_status == I915_SAGV_NOT_CONTROLLED only on SKL, but this
function doesn't have to know that.

BR,
Jani.

>  
>  /*

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] GuC firmware versioning change

[Daniel Vetter]

On Thu, Oct 18, 2018 at 03:48:04PM -0700, Jeff McGee wrote:
> On Thu, Oct 18, 2018 at 11:12:21AM -0700, Rodrigo Vivi wrote:
> > On Thu, Oct 18, 2018 at 10:32:37AM -0700, Jeff McGee wrote:
> > > On Thu, Oct 18, 2018 at 11:57:06AM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 12, 2018 at 11:45 PM Jeff McGee  
> > > > wrote:
> > > > >
> > > > > On Fri, Oct 12, 2018 at 02:33:26PM -0700, Jeff McGee wrote:
> > > > > > On Fri, Oct 12, 2018 at 01:51:46PM -0700, Rodrigo Vivi wrote:
> > > > > > > On Fri, Oct 12, 2018 at 01:24:30PM -0700, Jeff McGee wrote:
> > > > > > > > The GuC firmware team is proposing a change to the firmware 
> > > > > > > > versioning scheme.
> > > > > > > > The goal is to more accurately track the firmware interface to 
> > > > > > > > help users
> > > > > > > > manage dependencies on that interface. The proposed scheme is 
> > > > > > > > based on
> > > > > > > > semver.org with some additions to handle branching.
> > > > > > > >
> > > > > > > > The proposed version number would have 4 fields: 
> > > > > > > > BASE.MAJOR.MINOR.PATCH.
> > > > > > > > Contrast this with the 2 fields in the current version number: 
> > > > > > > > MAJOR.MINOR.
> > > > > > > > Side note, the current firmware encodes a BRANCH and CLIENT 
> > > > > > > > number as well, but
> > > > > > > > they have not been needed by i915. So a firmware released with 
> > > > > > > > the proposed
> > > > > > > > scheme would be named 
> > > > > > > > _guc_ver___.bin
> > > > > > > > (ex: skl_guc_ver1_5_4_7.bin) instead of the current
> > > > > > > > _guc_ver_.bin (ex: skl_guc_ver9_33.bin).
> > > > > > > >
> > > > > > > > The BASE number is an ID that is used to identify a set of 
> > > > > > > > releases in which
> > > > > > > > the MAJOR.MINOR.PATCH semantics are consistent. In other words, 
> > > > > > > > two releases
> > > > > > > > from the same BASE can be compared via their MAJOR.MINOR.PATCH 
> > > > > > > > to infer their
> > > > > > > > relationship as described below. Two releases from a different 
> > > > > > > > BASE cannot be
> > > > > > > > reliably compared. The BASE number facilitates arbitrary 
> > > > > > > > branching which can
> > > > > > > > create duplicate and/or disconnected MAJOR.MINOR.PATCH 
> > > > > > > > versions. This type of
> > > > > > > > branching is expected to be rare, and so BASE will rarely 
> > > > > > > > change. When a new
> > > > > > > > BASE is created, the MAJOR.MINOR.PATCH reset to starting values.
> > > > > > >
> > > > > > > Could you please clarify a bit what BASE means?
> > > > > > > What would be a different BASE?
> > > > > > >
> > > > > >
> > > > > > The BASE number supports general branching that would cause version 
> > > > > > number
> > > > > > conflicts. Branching for firmware releases is not desirable, but it 
> > > > > > is a
> > > > > > practical reality. Therefore the versioning scheme must accomodate 
> > > > > > it. Let's
> > > > > > say that a high-priority request is made to put specific updates on 
> > > > > > an old
> > > > > > release that said customer is locked on. Those updates could 
> > > > > > include any sort
> > > > > > of change including interface change. Then we have a sequence like 
> > > > > > below:
> > > > > >
> > > > > > v1.1.0.0   v1.1.0.1   v1.1.0.2   v1.1.0.3   v1.1.1.0
> > > > > > O--O--O--O--O
> > > > > >\
> > > > > > \
> > > > > >  \
> > > > > >   O--O
> > > > > >   v2.1.1.0   v2.1.1.1
> > > > > >
> > > > > > You can see that if we don't have a BASE number that changes from 1 
> > > > > > to 2, then
> > > > > > we end up with duplicated v1.1.0 along the different branches which 
> > > > > > are not the
> > > > > > same. As I wrote, this should be a very rare scenario, but it can 
> > > > > > happen. Maybe
> > > > > > upstream will always be supplied with releases from the "main" 
> > > > > > BASE, and you
> > > > > > can ignore this field, but it needs to be there for other firmware
> > > > > > distributions.
> > > > 
> > > > The way this is usually solved in semver is to not prepend a BASE, but
> > > > postfix a branch-specific version, while keeping the mainline version
> > > > unchanged. So
> > > > 
> > > > v2.1.1.0 becomes v1.1.0.1-branch1-0
> > > > v2.1.1.1 becomes v1.1.0.1-branch1-1
> > 
> > +1. This would be much cleaner.
> > 
> > 
> > > > 
> > > > With the rule that branches are explicitly unsorted (that's denoted by
> > > > the - - around them, instead o using dots), so not comparable. Bonus
> > > > points if you name the branch points by the customers (could be the
> > > > product, or internal customer group or whatever) to make these names
> > > > slightly more meaningful.
> > 
> > +1 for meaningful names.
> > 
> > > > 
> > > I don't see any mention of branch handling on semver.org.
> > 
> > Also I don't see an extra field for base on semver.org.
> > So 

Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbdev: Use an ordinary worker to avoid async deadlock

[Daniel Vetter]

On Mon, Oct 15, 2018 at 12:17:39PM +0100, Chris Wilson wrote:
> We try to avoid a deadlock of synchronizing the async fbdev task by
> skipping the synchronisation from the async worker, but that prevents us
> from using an async worker for the device probe. As we have our own
> barrier and do not rely on the global async flush, we can simply replace
> the async task with an explicit worker.
> 
> References: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
> Signed-off-by: Chris Wilson 

Does this now mean that fbdev setup lags behind module load? Afaiui that
will annoy userspace, which assumes that once the kms driver is loaded,
fbdev works. Or at least I have vague memories of pains in this area.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_drv.h   |  3 +--
>  drivers/gpu/drm/i915/intel_fbdev.c | 35 +++---
>  2 files changed, 18 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3dea7a1bda7f..15bbf604724d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -25,7 +25,6 @@
>  #ifndef __INTEL_DRV_H__
>  #define __INTEL_DRV_H__
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -207,8 +206,8 @@ struct intel_fbdev {
>   struct intel_framebuffer *fb;
>   struct i915_vma *vma;
>   unsigned long vma_flags;
> - async_cookie_t cookie;
>   int preferred_bpp;
> + struct work_struct work;
>  };
>  
>  struct intel_encoder {
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 2480c7d6edee..265cc947aede 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -24,7 +24,6 @@
>   * David Airlie
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -666,6 +665,16 @@ static void intel_fbdev_suspend_worker(struct 
> work_struct *work)
>   true);
>  }
>  
> +static void intel_fbdev_initial_config(struct work_struct *work)
> +{
> + struct intel_fbdev *ifbdev = container_of(work, typeof(*ifbdev), work);
> +
> + /* Due to peculiar init order wrt to hpd handling this is separate. */
> + if (drm_fb_helper_initial_config(>helper,
> +  ifbdev->preferred_bpp))
> + intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
> +}
> +
>  int intel_fbdev_init(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -679,6 +688,8 @@ int intel_fbdev_init(struct drm_device *dev)
>   if (ifbdev == NULL)
>   return -ENOMEM;
>  
> + INIT_WORK(>work, intel_fbdev_initial_config);
> +
>   drm_fb_helper_prepare(dev, >helper, _fb_helper_funcs);
>  
>   if (!intel_fbdev_init_bios(dev, ifbdev))
> @@ -698,16 +709,6 @@ int intel_fbdev_init(struct drm_device *dev)
>   return 0;
>  }
>  
> -static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
> -{
> - struct intel_fbdev *ifbdev = data;
> -
> - /* Due to peculiar init order wrt to hpd handling this is separate. */
> - if (drm_fb_helper_initial_config(>helper,
> -  ifbdev->preferred_bpp))
> - intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
> -}
> -
>  void intel_fbdev_initial_config_async(struct drm_device *dev)
>  {
>   struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
> @@ -715,17 +716,16 @@ void intel_fbdev_initial_config_async(struct drm_device 
> *dev)
>   if (!ifbdev)
>   return;
>  
> - ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
> + schedule_work(>work);
>  }
>  
>  static void intel_fbdev_sync(struct intel_fbdev *ifbdev)
>  {
> - if (!ifbdev->cookie)
> + if (!READ_ONCE(ifbdev->work.func))
>   return;
>  
> - /* Only serialises with all preceding async calls, hence +1 */
> - async_synchronize_cookie(ifbdev->cookie + 1);
> - ifbdev->cookie = 0;
> + flush_work(>work);
> + ifbdev->work.func = NULL;
>  }
>  
>  void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
> @@ -736,8 +736,7 @@ void intel_fbdev_unregister(struct drm_i915_private 
> *dev_priv)
>   return;
>  
>   cancel_work_sync(_priv->fbdev_suspend_work);
> - if (!current_is_async())
> - intel_fbdev_sync(ifbdev);
> + intel_fbdev_sync(ifbdev);
>  
>   drm_fb_helper_unregister_fbi(>helper);
>  }
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 4/8] drm/i915: Group gen 10 display.

[Daniel Vetter]

On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > Continuing with the goal of use less platform codenames:
> > let's group platforms who has gen10 display.
> 
> Ahah, so this answers my question in the previous patch. ;)
> 
> So we already have HAS_GMCH_DISPLAY().

We also have HAS_DDI, which I guess you could call gen8 display :-)

> If we're going to make gen10 display a thing, should we not generalize
> this to have an actual display gen in device info? Of course for most
> platforms it's going to be identical to the gem gen.
> 
> The question becomes, is display gen accurate enough? It's not enough to
> cover all of Geminilake I believe. Which makes me think, should we just
> add tons more device info flags to cover features at a detailed level? I
> think that's what Joonas advocates. Perhaps it bloats the device info,
> and causes increase in the number of device info blocks. But my gut
> feeling says together with truly immutable device info, there are
> compiler optimization benefits to be had.
> 
> Also, currently we "inherit" device info using truly obnoxious macro
> layering where you have to work hard to trace the macros to find out
> what is set for a given platform. It doesn't have to be that way. We
> could move parts of it to separate but shared features structs, and add
> pointers to them.
> 
> Anyway, thanks for rolling this series as a starting point for
> discussion. Even if I'm not buying the changes as-is. ;)

Yeah, stuffing this into intel_info imo makes sense. As long as it's
booleans they should be fairly cheap.
-Daniel
> 
> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
> >  drivers/gpu/drm/i915/intel_cdclk.c   | 2 +-
> >  drivers/gpu/drm/i915/intel_color.c   | 2 +-
> >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> >  drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
> >  5 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index d19b38ef145b..6436fedfe561 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2637,6 +2637,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  #define SUPPORTS_TV(dev_priv)  ((dev_priv)->info.supports_tv)
> >  #define I915_HAS_HOTPLUG(dev_priv) ((dev_priv)->info.has_hotplug)
> >  
> > +#define HAS_DISPLAY_10(dev_priv) (IS_GEN10(dev_priv) || 
> > IS_GEMINILAKE(dev_priv))
> > +
> >  #define HAS_FW_BLC(dev_priv)   (INTEL_GEN(dev_priv) > 2)
> >  #define HAS_FBC(dev_priv)  ((dev_priv)->info.has_fbc)
> >  #define HAS_CUR_FBC(dev_priv)  (!HAS_GMCH_DISPLAY(dev_priv) && 
> > INTEL_GEN(dev_priv) >= 7)
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 4aa6500604cc..b315b70fd49c 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -2181,7 +2181,7 @@ int intel_crtc_compute_min_cdclk(const struct 
> > intel_crtc_state *crtc_state)
> > crtc_state->has_audio &&
> > crtc_state->port_clock >= 54 &&
> > crtc_state->lane_count == 4) {
> > -   if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
> > +   if (HAS_DISPLAY_10(dev_priv)) {
> > /* Display WA #1145: glk,cnl */
> > min_cdclk = max(316800, min_cdclk);
> > } else if (IS_GEN9(dev_priv) || IS_BROADWELL(dev_priv)) {
> > diff --git a/drivers/gpu/drm/i915/intel_color.c 
> > b/drivers/gpu/drm/i915/intel_color.c
> > index 5127da286a2b..d5f67b9c9698 100644
> > --- a/drivers/gpu/drm/i915/intel_color.c
> > +++ b/drivers/gpu/drm/i915/intel_color.c
> > @@ -659,7 +659,7 @@ void intel_color_init(struct drm_crtc *crtc)
> >IS_BROXTON(dev_priv)) {
> > dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
> > dev_priv->display.load_luts = broadwell_load_luts;
> > -   } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> > +   } else if (HAS_DISPLAY_10(dev_priv)) {
> > dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
> > dev_priv->display.load_luts = glk_load_luts;
> > } else {
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7b04b8436b6d..1abf79a4ee91 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5730,7 +5730,7 @@ static void haswell_crtc_enable(struct 
> > intel_crtc_state *pipe_config,
> > intel_crtc->active = true;
> >  
> > /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
> > -   psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> > +   psl_clkgate_wa = (HAS_DISPLAY_10(dev_priv)) &&
> >  pipe_config->pch_pfit.enabled;
> > if (psl_clkgate_wa)
> > 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Disable displays at the user's request

[Chris Wilson]

Quoting Daniel Vetter (2018-10-19 09:22:15)
> On Mon, Oct 15, 2018 at 12:17:41PM +0100, Chris Wilson wrote:
> > If the user passes i915.disable_display=1 we want to disable all the
> > displays and associated HW like the powerwells on their behalf. Instead
> > of short circuiting the HW probe, let it run and setup all the
> > bookkeeping for the known HW. Afterwards, instead of taking over the
> > BIOS fb and installing the fbcon, we shutdown all the outputs and
> > teardown the bookkeeping, leaving us with no attached outputs or crtcs,
> > and all the HW powered down.
> > 
> > Open: wq flushes should be required but seem to deadlock the modprobe
> > under CI.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Imre Deak 
> > Cc: Ville Syrjälä 
> 
> i915.disable_display was for those server chips where doing all the init
> resulted in a dead machine. So not sure we want this.

For those server chips, we don't use i915.disable_display but detect when
the fuses are lies and directly set num_pipes == 0. If we had such a
machine in CI, you would already have seen a lot of the fun with KMS being
allowed without any backing hw. Hence why Ville suggested we disable KMS
for machines without pipes to avoid having to add a lot of defense
around the driver.

> What's the issue with power wells still being on and all that? On real hw
> without display they won't exist, and I don't understand why we'd care for
> testing.

For testing. We do use .disable_display and expect rpm to still work, and
to not get random display related failures interfering in displayless
tests.

Quite clearly we haven't been testing the displayless setups at all.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] RFC: Make igts for cross-driver stuff mandatory?

[Daniel Vetter]

Hi all,

This is just to collect feedback on this idea, and see whether the
overall dri-devel community stands on all this. I think the past few
cross-vendor uapi extensions all came with igts attached, and
personally I think there's lots of value in having them: A
cross-vendor interface isn't useful if every driver implements it
slightly differently.

I think there's 2 questions here:

- Do we want to make such testcases mandatory?

- If yes, are we there yet, or is there something crucially missing
  still?

And of course there's a bunch of details to figure out. Like we
probably want to also recommend the selftests/unit-tests in
drivers/gpu/drm/selftest, since fairly often that's a much more
effective approach to checking the details than from userspace.

Feedback and thoughts very much appreciated.

Cheers, Daniel
---
 Documentation/gpu/drm-uapi.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 4b4bf2c5eac5..91cf6e4b6303 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -238,6 +238,13 @@ DRM specific patterns. Note that ENOTTY has the slightly 
unintuitive meaning of
 Testing and validation
 ==
 
+Testing Requirements for userspace API
+--
+
+New cross-driver userspace interface extensions, like new IOCTL, new KMS
+properties, new files in sysfs or anything else that constitutes an API change
+need to have driver-agnostic testcases in IGT for that feature.
+
 Validating changes with IGT
 ---
 
-- 
2.19.1

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Disable displays at the user's request

[Daniel Vetter]

On Mon, Oct 15, 2018 at 12:17:41PM +0100, Chris Wilson wrote:
> If the user passes i915.disable_display=1 we want to disable all the
> displays and associated HW like the powerwells on their behalf. Instead
> of short circuiting the HW probe, let it run and setup all the
> bookkeeping for the known HW. Afterwards, instead of taking over the
> BIOS fb and installing the fbcon, we shutdown all the outputs and
> teardown the bookkeeping, leaving us with no attached outputs or crtcs,
> and all the HW powered down.
> 
> Open: wq flushes should be required but seem to deadlock the modprobe
> under CI.
> 
> Signed-off-by: Chris Wilson 
> Cc: Imre Deak 
> Cc: Ville Syrjälä 

i915.disable_display was for those server chips where doing all the init
resulted in a dead machine. So not sure we want this.

What's the issue with power wells still being on and all that? On real hw
without display they won't exist, and I don't understand why we'd care for
testing.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.c  | 53 +---
>  drivers/gpu/drm/i915/intel_device_info.c |  9 ++--
>  drivers/gpu/drm/i915/intel_fbdev.c   |  2 +-
>  3 files changed, 43 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c14855f167b9..d71add64948b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -689,22 +689,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
>  
>   intel_setup_overlay(dev_priv);
>  
> - if (INTEL_INFO(dev_priv)->num_pipes == 0)
> - return 0;
> -
> - ret = intel_fbdev_init(dev_priv);
> - if (ret)
> - goto cleanup_gem;
> -
> - /* Only enable hotplug handling once the fbdev is fully set up. */
> - intel_hpd_init(dev_priv);
> -
>   return 0;
>  
> -cleanup_gem:
> - if (i915_gem_suspend(dev_priv))
> - DRM_ERROR("failed to idle hardware; continuing to unload!\n");
> - i915_gem_fini(dev_priv);
>  cleanup_modeset:
>   intel_modeset_cleanup(dev);
>  cleanup_irq:
> @@ -1667,6 +1653,17 @@ static void i915_driver_destroy(struct 
> drm_i915_private *i915)
>   pci_set_drvdata(pdev, NULL);
>  }
>  
> +static void disable_display(struct drm_i915_private *i915)
> +{
> + drm_atomic_helper_shutdown(>drm);
> +
> +#if 0 /* XXX flushes deadlock under modprobe??? */
> + flush_workqueue(i915->modeset_wq);
> + flush_work(>atomic_helper.free_work);
> + flush_scheduled_work();
> +#endif
> +}
> +
>  /**
>   * i915_driver_load - setup chip and create an initial config
>   * @pdev: PCI device
> @@ -1727,6 +1724,34 @@ int i915_driver_load(struct pci_dev *pdev, const 
> struct pci_device_id *ent)
>   if (ret < 0)
>   goto out_cleanup_hw;
>  
> + /*
> +  * After completing our HW probe; tear it all down again (at the
> +  * user's request)!
> +  *
> +  * Along side the CRTCs and connectors, there is a medley of
> +  * auxiliary HW which control various powerwells and interact with
> +  * other state (such as the BIOS framebuffer occupying a portion
> +  * of reserved memory). If the user tells us to run without any
> +  * displays enabled, we still need to register all the display and
> +  * auxiliary HW in order to safely disable them.
> +  */
> + if (i915_modparams.disable_display) {
> + DRM_INFO("Display disabled (module parameter)\n");
> + disable_display(dev_priv);
> + mkwrite_device_info(dev_priv)->num_pipes = 0;
> + }
> +
> + if (INTEL_INFO(dev_priv)->num_pipes == 0) {
> + drm_mode_config_cleanup(_priv->drm);
> + dev_priv->drm.driver_features &=
> + ~(DRIVER_MODESET | DRIVER_ATOMIC);
> + dev_priv->psr.sink_support = false;
> + }
> +
> + /* Only enable hotplug handling once the fbdev is fully set up. */
> + if (intel_fbdev_init(dev_priv) == 0)
> + intel_hpd_init(dev_priv);
> +
>   i915_driver_register(dev_priv);
>  
>   intel_init_ipc(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 03df4e33763d..5f6b12986ce9 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -775,12 +775,9 @@ void intel_device_info_runtime_init(struct 
> intel_device_info *info)
>   info->num_sprites[pipe] = 1;
>   }
>  
> - if (i915_modparams.disable_display) {
> - DRM_INFO("Display disabled (module parameter)\n");
> - info->num_pipes = 0;
> - } else if (info->num_pipes > 0 &&
> -(IS_GEN7(dev_priv) || IS_GEN8(dev_priv)) &&
> -HAS_PCH_SPLIT(dev_priv)) {
> + if (info->num_pipes > 0 &&
> + (IS_GEN7(dev_priv) || IS_GEN8(dev_priv)) &&
> + HAS_PCH_SPLIT(dev_priv)) {
>   u32 fuse_strap = 

Re: [Intel-gfx] [RFC 2/8] drm/i915: Use the ddi_ports info to kill ugly CNL_WITH_PORT_F.

[Daniel Vetter]

On Fri, Oct 19, 2018 at 10:39:46AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > Now that we have the number of ddi ports information available
> > let's use it instead of that ugly platform macro.
> >
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 10 ++
> >  drivers/gpu/drm/i915/i915_drv.h |  2 --
> >  drivers/gpu/drm/i915/i915_irq.c |  5 ++---
> >  drivers/gpu/drm/i915/intel_dp.c |  2 +-
> >  drivers/gpu/drm/i915/intel_hotplug.c|  2 +-
> >  drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +-
> >  6 files changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index baac35f698f9..83ab325c6675 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -239,6 +239,14 @@ intel_virt_detect_pch(const struct drm_i915_private 
> > *dev_priv)
> > return id;
> >  }
> >  
> > +static void intel_adjust_skus_differences(struct drm_i915_private 
> > *dev_priv)
> > +{
> > +   /* Some Cannonlake SKUs have Port F */
> > +   if (IS_CANNONLAKE(dev_priv) &&
> > +   (INTEL_DEVID(dev_priv) & 0x0004) == 0x0004)
> > +   mkwrite_device_info(dev_priv)->ddi_ports = 6;
> > +}
> 
> I'd like reduce the amount of device info stuff we adjust at probe, not
> increase.
> 
> Long term, I'd like to make dev_priv->info a const pointer to the const
> data in i915_pci.c, and make it truly immutable. We could have an
> additional runtime device info to complement that, but this approach
> calls for a more concrete split in const and non-const data, not "mostly
> const but sometimes mutable".
> 
> I think I've chatted about this with Chris too.

This should be easy to fix since it's encoded in the pci id. Just need a
new separate entry just for this one.
-Daniel

> 
> BR,
> Jani.
> 
> > +
> >  static void intel_detect_pch(struct drm_i915_private *dev_priv)
> >  {
> > struct pci_dev *pch = NULL;
> > @@ -904,6 +912,8 @@ static int i915_driver_init_early(struct 
> > drm_i915_private *dev_priv)
> > if (ret < 0)
> > goto err_workqueues;
> >  
> > +   intel_adjust_skus_differences(dev_priv);
> > +
> > /* This must be called before any calls to HAS_PCH_* */
> > intel_detect_pch(dev_priv);
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 7ad232849268..99e42df79ed8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2485,8 +2485,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  (dev_priv)->info.gt == 2)
> >  #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
> >  (dev_priv)->info.gt == 3)
> > -#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> > -   (INTEL_DEVID(dev_priv) & 0x0004) == 
> > 0x0004)
> >  
> >  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 5d1f53723388..63d676de3840 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2782,8 +2782,7 @@ gen8_de_irq_handler(struct drm_i915_private 
> > *dev_priv, u32 master_ctl)
> > if (INTEL_GEN(dev_priv) >= 11)
> > tmp_mask |= ICL_AUX_CHANNEL_E;
> >  
> > -   if (IS_CNL_WITH_PORT_F(dev_priv) ||
> > -   INTEL_GEN(dev_priv) >= 11)
> > +   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
> > tmp_mask |= CNL_AUX_CHANNEL_F;
> >  
> > if (iir & tmp_mask) {
> > @@ -4220,7 +4219,7 @@ static void gen8_de_irq_postinstall(struct 
> > drm_i915_private *dev_priv)
> > if (INTEL_GEN(dev_priv) >= 11)
> > de_port_masked |= ICL_AUX_CHANNEL_E;
> >  
> > -   if (IS_CNL_WITH_PORT_F(dev_priv) || INTEL_GEN(dev_priv) >= 11)
> > +   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
> > de_port_masked |= CNL_AUX_CHANNEL_F;
> >  
> > de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 3384a9bbdafd..0ea0414ccef4 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -402,7 +402,7 @@ static int cnl_max_source_rate(struct intel_dp 
> > *intel_dp)
> > return 54;
> >  
> > /* For this SKU 8.1G is supported in all ports */
> > -   if (IS_CNL_WITH_PORT_F(dev_priv))
> > +   if (INTEL_INFO(dev_priv)->ddi_ports == 6)
> > return 81;
> >  
> > /* For other SKUs, max rate on ports A and D is 5.4G */
> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> > b/drivers/gpu/drm/i915/intel_hotplug.c
> > index 648a13c6043c..05d1faf77048 100644
> 

Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbdev: Use an ordinary worker to avoid async deadlock

[Chris Wilson]

Quoting Daniel Vetter (2018-10-19 09:23:54)
> On Mon, Oct 15, 2018 at 12:17:39PM +0100, Chris Wilson wrote:
> > We try to avoid a deadlock of synchronizing the async fbdev task by
> > skipping the synchronisation from the async worker, but that prevents us
> > from using an async worker for the device probe. As we have our own
> > barrier and do not rely on the global async flush, we can simply replace
> > the async task with an explicit worker.
> > 
> > References: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization 
> > fails")
> > Signed-off-by: Chris Wilson 
> 
> Does this now mean that fbdev setup lags behind module load? Afaiui that
> will annoy userspace, which assumes that once the kms driver is loaded,
> fbdev works. Or at least I have vague memories of pains in this area.

I have no idea what pain you remember, I just ask wtf is fbdev.

Since we register the driver before module load completes, there's a
race window for third parties who can make that same assumption, so
what's the difference: fbdev is available as soon as it is registered
and not before.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/intel_dsi: Read back pclk set by GOP and use that as pclk v2

[Jani Nikula]

On Wed, 17 Oct 2018, Hans de Goede  wrote:
> On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
> different frequency then the pclk which we've calculated.
>
> This commit makes the DSI code read-back the pclk set by the GOP and
> if that is within a reasonable margin of the calculated pclk, uses
> that instead.
>
> This fixes the first modeset being a full modeset instead of a
> fast modeset on systems where the GOP pclk is different.

I assume we don't do the fast path because intel_pipe_config_compare()
returns false due to crtc_clock and port_clock mismatch. The dmesg
should tell you the reason with drm.debugs enabled.

Now, the clock checks are already "fuzzy", and should account for slight
variations. I think the goal was the same as here, plus IIUC we may lose
some accuracy on the hardware roundtrip.

Please try adding more tolerance in intel_fuzzy_clock_check() and see if
that helps. The code looks like it allows 5% diff, but it's 2.5%.

Regardless of whether we end up changing the tolerance or adjusting the
state based on the hardware readout or what, I think doing the
adjustment in intel_dsi_vbt.c init is the wrong place. We shouldn't have
anything that depends on accessing the hardware there. I believe that's
what Ville was trying to say in [1].

BR,
Jani.


[1] http://mid.mail-archive.com/20180706141652.GK5565@intel.com


>
> Changes in v2:
> -Use intel_encoder_current_mode() to get the pclk setup by the GOP
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index ac83d6b89ae0..3387b187105c 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -506,6 +506,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
> panel_id)
>   struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
>   struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
>   struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
> + struct drm_display_mode *curr;
>   u32 bpp;
>   u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
>   u32 ui_num, ui_den;
> @@ -583,6 +584,23 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
> panel_id)
>   } else
>   burst_mode_ratio = 100;
>  
> + /*
> +  * On BYT / CRC the GOP sometimes picks a slightly different pclk,
> +  * read back the GOP configured pclk and prefer it over ours.
> +  */
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> + curr = intel_encoder_current_mode(_dsi->base);
> + if (curr) {
> + DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n",
> +   pclk, curr->clock);
> + if (curr->clock >= (pclk * 9 / 10) &&
> + curr->clock <= (pclk * 11 / 10))
> + pclk = curr->clock;
> +
> + kfree(curr);
> + }
> + }
> +
>   intel_dsi->burst_mode_ratio = burst_mode_ratio;
>   intel_dsi->pclk = pclk;

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] drm-intel-next-fixes

[Daniel Vetter]

On Fri, Oct 19, 2018 at 8:59 AM Joonas Lahtinen
 wrote:
>
> Quoting Daniel Vetter (2018-10-18 22:32:00)
> > On Thu, Oct 18, 2018 at 6:57 PM Joonas Lahtinen
> >  wrote:
> > >
> > > Hi Dave,
> > >
> > > Here comes the final set of fixes under -next-fixes umbrella.
> > > Next one will be then from -fixes, assuming a release next Sun.
> > >
> > > Fixes for bunch of display related issues reported by users, then the
> > > MST fixes that were dropped from Rodrigos PR + further Icelake fixes
> > > and proactive improvements picked by tooling.
> > >
> > > Excuse for the slight accumulation as I skipped last week due to
> > > travel like I warned.
> > >
> > > Regards, Joonas
> > >
> > > ***
> > >
> > > drm-intel-next-fixes-2018-10-18:
> > > - Fix GPU hang on MacBook2,1 when booting in EFI mode (Bugzilla #105637)
> > > - Fix garbled console on Y tiled BIOS framebuffer configs (Bugzilla 
> > > #108264)
> > > - Fix black screen on certain eDP panels eg. Dell XPS 9350 (Bugzilla 
> > > #107489 and #105338)
> > > - MST fixes that Rodrigo dropped from drm-intel-fixes and bunch of 
> > > Icelake fixes
> >
> > This won't work because it doesn't contain Lyude's core fix (+ the 2
> > fixups). You either need to cherry-pick all of them (and then probably
> > include the nouveau one), or none of them. Did the cherry-pick script
> > not propose them, or something else? They're all cc: stable.
>
> cherry-pick-next-fixes did not propose more. I did specifically ask
> Rodrigo to drop the relevant stuff from drm-intel-fixes so that the
> tooling would pick it up. What is there that is missing?

dim cherry-pick-branch is limited to drivers/gpu/drm/i915 :-(

Remove that (well at least only filter drm/) and you should see them.
Ideally you put the core patch + 2 core fixups before the i915/nouveau
patches.

I guess putting core patches that are bugfixes through drm-intel.git
really isn't a good idea with our process ...
-Daniel

>
> Regards, Joonas
>
> > -Daniel
> >
> > > - Then assorted proactive code fixes caught by CI or developers
> > >
> > > The following changes since commit 
> > > ca4b869240d5810ebac6b1570ad7beffcfbac2f5:
> > >
> > >   Merge branch 'drm-next-4.20' of 
> > > git://people.freedesktop.org/~agd5f/linux into drm-next (2018-10-11 
> > > 14:53:45 +1000)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://anongit.freedesktop.org/drm/drm-intel 
> > > tags/drm-intel-next-fixes-2018-10-18
> > >
> > > for you to fetch changes up to 835fe6d75d14c1513910ed7f5665127fee12acc8:
> > >
> > >   firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake. 
> > > (2018-10-18 10:36:10 +0300)
> > >
> > > 
> > > - Fix GPU hang on MacBook2,1 when booting in EFI mode (Bugzilla #105637)
> > > - Fix garbled console on Y tiled BIOS framebuffer configs (Bugzilla 
> > > #108264)
> > > - Fix black screen on certain eDP panels eg. Dell XPS 9350 (Bugzilla 
> > > #107489 and #105338)
> > > - MST fixes that Rodrigo dropped from drm-intel-fixes and bunch of 
> > > Icelake fixes
> > > - Then assorted proactive code fixes caught by CI or developers
> > >
> > > 
> > > Anusha Srivatsa (1):
> > >   firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake.
> > >
> > > Chris Wilson (3):
> > >   drm/i915: Only reset seqno if actually idle
> > >   drm/i915/selftests: Disable shrinker across mmap-exhaustion
> > >   drm/i915: Large page offsets for pread/pwrite
> > >
> > > Imre Deak (1):
> > >   drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
> > >
> > > Lyude Paul (3):
> > >   drm/i915: Don't unset intel_connector->mst_port
> > >   drm/i915: Skip vcpi allocation for MSTB ports that are gone
> > >   drm/i915: Fix intel_dp_mst_best_encoder()
> > >
> > > Mahesh Kumar (2):
> > >   drm/i915/icl: create function to identify combophy port
> > >   drm/i915/icl: Fix DDI/TC port clk_off bits
> > >
> > > Manasi Navare (1):
> > >   drm/i915/dp: Link train Fallback on eDP only if fallback link BW 
> > > can fit panel's native mode
> > >
> > > Rodrigo Vivi (1):
> > >   drm/i915/icl: Fix signal_levels
> > >
> > > Ville Syrjälä (3):
> > >   drm/i915: Check fb stride against plane max stride
> > >   drm/i915: Restore vblank interrupts earlier
> > >   drm/i915: Use the correct crtc when sanitizing plane mapping
> > >
> > >  drivers/gpu/drm/i915/i915_debugfs.c  |   2 +-
> > >  drivers/gpu/drm/i915/i915_gem.c  |  12 +-
> > >  drivers/gpu/drm/i915/i915_reg.h  |   3 +
> > >  drivers/gpu/drm/i915/intel_csr.c |   1 +
> > >  drivers/gpu/drm/i915/intel_ddi.c |  36 --
> > >  drivers/gpu/drm/i915/intel_display.c | 151 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c  |  32 -
> > >  drivers/gpu/drm/i915/intel_dp_link_training.c|  26 

[Intel-gfx] [PATCH v2 0/5] i915 pvmmio to improve GVTg performance

[Xiaolin Zhang]

To improve GVTg performance, it could reduce the mmio access trap
numbers within guest driver in some certain scenarios since mmio
access trap will introuduce vm exit/vm enter cost.

the solution in this patch set is to setup a shared memory region
which accessed both by guest and GVTg without trap cost. the shared
memory region is allocated by guest driver and guest driver will
pass the region's memory guest physical address to GVTg through
PVINFO register and later GVTg can access this region directly without
trap cost to achieve data exchange purpose between guest and GVTg.

in this patch set, 3 kind of pvmmio optimization implemented which is
controlled by enable_pvmmio PVINO register with different level flag.
1. workload submission (context submission): reduce 4 traps to 1 trap.
2. master irq: reduce 2 traps to 1 trap. 
3. ppgtt update: eliminate the cost of ppgtt write protection. 

based on the experiment, the performance was gained 4 percent (average)
improvment with regard to both media and 3D workload benchmarks.

based on the pvmmio framework, it could achive more sceneario optimization
such as globle GTT update, display plane and water mark update with guest.

v0: RFC patch set
v1: addressed RFC review comments
v2: addressed v1 review comments, added pv callbacks for pv operations

Xiaolin Zhang (5):
  drm/i915: introduced pv capability for vgpu
  drm/i915: get ready of memory for pvmmio
  drm/i915: context submission pvmmio optimization
  drm/i915: master irq pvmmio optimization
  drm/i915: ppgtt update pvmmio optimization

 drivers/gpu/drm/i915/i915_drv.c |  2 +
 drivers/gpu/drm/i915/i915_drv.h | 15 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c | 67 +
 drivers/gpu/drm/i915/i915_irq.c | 82 --
 drivers/gpu/drm/i915/i915_pvinfo.h  | 43 +++-
 drivers/gpu/drm/i915/i915_vgpu.c| 44 -
 drivers/gpu/drm/i915/intel_lrc.c| 88 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 ++
 8 files changed, 333 insertions(+), 11 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v2 4/5] drm/i915: master irq pvmmio optimization

[Xiaolin Zhang]

Master irq register is accessed twice every irq handling, then trapped
to SOS very frequently. Optimize it by moving master irq register
to share page, writing don't need be trapped.

When need enable irq to let SOS inject irq timely, use another pvmmio
register to achieve this purpose. So avoid one trap when we disable
master irq.

Use PVMMIO_MASTER_IRQ to control this level of pvmmio optimization.

v0: RFC
v1: rebase
v2: added pv version callbacks for irq_{irq_handler, irq_preinstall,
irq_postinstall}

Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: He, Min 
Cc: Jiang, Fei 
Cc: Gong, Zhipeng 
Cc: Yuan, Hang 
Cc: Zhiyuan Lv 
Signed-off-by: Xiaolin Zhang 
---
 drivers/gpu/drm/i915/i915_irq.c| 82 --
 drivers/gpu/drm/i915/i915_pvinfo.h |  3 +-
 drivers/gpu/drm/i915/i915_vgpu.c   |  2 +-
 3 files changed, 81 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5d1f537..95ed2e7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2938,6 +2938,40 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static irqreturn_t gen8_irq_handler_pv(int irq, void *arg)
+{
+   struct drm_i915_private *dev_priv = to_i915(arg);
+   u32 master_ctl;
+   u32 gt_iir[4];
+
+   if (!intel_irqs_enabled(dev_priv))
+   return IRQ_NONE;
+
+   master_ctl = I915_READ_FW(GEN8_MASTER_IRQ);
+   master_ctl &= ~GEN8_MASTER_IRQ_CONTROL;
+   if (!master_ctl)
+   return IRQ_NONE;
+
+   dev_priv->vgpu.shared_page->disable_irq = 1;
+
+   /* Find, clear, then process each source of interrupt */
+   gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
+
+   /* IRQs are synced during runtime_suspend, we don't require a wakeref */
+   if (master_ctl & ~GEN8_GT_IRQS) {
+   disable_rpm_wakeref_asserts(dev_priv);
+   gen8_de_irq_handler(dev_priv, master_ctl);
+   enable_rpm_wakeref_asserts(dev_priv);
+   }
+
+   dev_priv->vgpu.shared_page->disable_irq = 0;
+   __raw_i915_write32(dev_priv, vgtif_reg(check_pending_irq), 1);
+
+   gen8_gt_irq_handler(dev_priv, master_ctl, gt_iir);
+
+   return IRQ_HANDLED;
+}
+
 struct wedge_me {
struct delayed_work work;
struct drm_i915_private *i915;
@@ -3626,13 +3660,11 @@ static void gen8_gt_irq_reset(struct drm_i915_private 
*dev_priv)
GEN8_IRQ_RESET_NDX(GT, 3);
 }
 
-static void gen8_irq_reset(struct drm_device *dev)
+static void gen8_irq_reset_common(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
int pipe;
 
-   gen8_master_intr_disable(dev_priv->regs);
-
gen8_gt_irq_reset(dev_priv);
 
I915_WRITE(EDP_PSR_IMR, 0x);
@@ -3651,6 +3683,22 @@ static void gen8_irq_reset(struct drm_device *dev)
ibx_irq_reset(dev_priv);
 }
 
+static void gen8_irq_reset(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   gen8_master_intr_disable(dev_priv->regs);
+   gen8_irq_reset_common(dev);
+}
+
+static void gen8_irq_reset_pv(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   dev_priv->vgpu.shared_page->disable_irq = 1;
+   gen8_irq_reset_common(dev);
+}
+
 static void gen11_gt_irq_reset(struct drm_i915_private *dev_priv)
 {
/* Disable RCS, BCS, VCS and VECS class engines. */
@@ -4262,7 +4310,7 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
}
 }
 
-static int gen8_irq_postinstall(struct drm_device *dev)
+static int gen8_irq_postinstall_common(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
@@ -4275,11 +4323,32 @@ static int gen8_irq_postinstall(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev_priv))
ibx_irq_postinstall(dev);
 
+   return 0;
+}
+
+static int gen8_irq_postinstall(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   gen8_irq_postinstall_common(dev);
+
gen8_master_intr_enable(dev_priv->regs);
 
return 0;
 }
 
+static int gen8_irq_postinstall_pv(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   gen8_irq_postinstall_common(dev);
+
+   dev_priv->vgpu.shared_page->disable_irq = 0;
+   __raw_i915_write32(dev_priv, vgtif_reg(check_pending_irq), 1);
+
+   return 0;
+}
+
 static void gen11_gt_irq_postinstall(struct drm_i915_private *dev_priv)
 {
const u32 irqs = GT_RENDER_USER_INTERRUPT | GT_CONTEXT_SWITCH_INTERRUPT;
@@ -4895,6 +4964,11 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->irq_handler = gen8_irq_handler;
dev->driver->irq_preinstall = gen8_irq_reset;
dev->driver->irq_postinstall = gen8_irq_postinstall;
+   

[Intel-gfx] [PATCH v2 2/5] drm/i915: get ready of memory for pvmmio

[Xiaolin Zhang]

To enable pvmmio feature, we need to prepare one 4K shared page
which will be accessed by both guest and backend i915 driver.

guest i915 allocate one page memory and then the guest physical address is
passed to backend i915 driver through PVINFO register so that backend i915
driver can access this shared page without hypeviser trap cost for shared
data exchagne via hyperviser read_gpa functionality.

v0: RFC
v1: addressed RFC comment to move both shared_page_lock and shared_page
to i915_virtual_gpu structure
v2: packed i915_virtual_gpu structure

Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: He, Min 
Cc: Jiang, Fei 
Cc: Gong, Zhipeng 
Cc: Yuan, Hang 
Cc: Zhiyuan Lv 
Signed-off-by: Xiaolin Zhang 
---
 drivers/gpu/drm/i915/i915_drv.c|  2 ++
 drivers/gpu/drm/i915/i915_drv.h|  4 +++-
 drivers/gpu/drm/i915/i915_pvinfo.h | 24 +++-
 drivers/gpu/drm/i915/i915_vgpu.c   | 24 +++-
 4 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index baac35f..557ab67 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -987,6 +987,8 @@ static void i915_mmio_cleanup(struct drm_i915_private 
*dev_priv)
 
intel_teardown_mchbar(dev_priv);
pci_iounmap(pdev, dev_priv->regs);
+   if (intel_vgpu_active(dev_priv) && dev_priv->vgpu.shared_page)
+   free_page((unsigned long)dev_priv->vgpu.shared_page);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b2d7cb..d7a972f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1345,7 +1345,9 @@ struct i915_virtual_gpu {
bool active;
u32 caps;
u32 pv_caps;
-};
+   spinlock_t shared_page_lock;
+   struct gvt_shared_page *shared_page;
+} __packed;
 
 /* used in computing the new watermarks state */
 struct intel_wm_config {
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 26709e8..179d558 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -49,6 +49,24 @@ enum vgt_g2v_type {
VGT_G2V_MAX,
 };
 
+struct pv_ppgtt_update {
+   u64 pdp;
+   u64 start;
+   u64 length;
+   u32 cache_level;
+};
+
+/*
+ * shared page(4KB) between gvt and VM, could be allocated by guest driver
+ * or a fixed location in PCI bar 0 region
+ */
+struct gvt_shared_page {
+   u32 elsp_data[4];
+   u32 reg_addr;
+   u32 disable_irq;
+   struct pv_ppgtt_update pv_ppgtt;
+};
+
 #define VGPU_PVMMIO(vgpu) vgpu_vreg_t(vgpu, vgtif_reg(enable_pvmmio))
 
 /*
@@ -121,8 +139,12 @@ struct vgt_if {
u32 execlist_context_descriptor_lo;
u32 execlist_context_descriptor_hi;
u32 enable_pvmmio;
+   struct {
+   u32 lo;
+   u32 hi;
+   } shared_page_gpa;
 
-   u32  rsv7[0x200 - 25];/* pad to one page */
+   u32  rsv7[0x200 - 27];/* pad to one page */
 } __packed;
 
 #define vgtif_reg(x) \
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 907bbd2..cb409d5 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -62,6 +62,7 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
 {
u64 magic;
u16 version_major;
+   u64 gpa;
 
BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
 
@@ -91,7 +92,28 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
dev_priv->vgpu.pv_caps);
dev_priv->vgpu.pv_caps = __raw_i915_read32(dev_priv,
vgtif_reg(enable_pvmmio));
-
+   if (intel_vgpu_active(dev_priv) && dev_priv->vgpu.pv_caps) {
+   dev_priv->vgpu.shared_page =  (struct gvt_shared_page *)
+   get_zeroed_page(GFP_KERNEL);
+   if (!dev_priv->vgpu.shared_page) {
+   DRM_ERROR("out of memory for shared page memory\n");
+   return;
+   }
+   gpa = __pa(dev_priv->vgpu.shared_page);
+   __raw_i915_write32(dev_priv, vgtif_reg(shared_page_gpa.lo),
+   lower_32_bits(gpa));
+   __raw_i915_write32(dev_priv, vgtif_reg(shared_page_gpa.hi),
+   upper_32_bits(gpa));
+   if (gpa != __raw_i915_read64(dev_priv,
+   vgtif_reg(shared_page_gpa))) {
+   DRM_ERROR("vgpu: passed shared_page_gpa failed\n");
+   free_page((unsigned long)dev_priv->vgpu.shared_page);
+   dev_priv->vgpu.pv_caps = 0;
+   return;
+   }
+   spin_lock_init(_priv->vgpu.shared_page_lock);
+   DRM_INFO("VGPU shared page enabled\n");
+   }
DRM_INFO("Virtual GPU for Intel GVT-g 

[Intel-gfx] [PATCH v2 1/5] drm/i915: introduced pv capability for vgpu

[Xiaolin Zhang]

This u32 pv_caps field is used to control the different
level pvmmio feature for MMIO emulation in GVT.

This field is default zero, no pvmmio feature enabled.

it also add VGT_CAPS_PVMMIO capability BIT for guest to check GVTg
can support PV feature or not.

v0: RFC, introudced enable_pvmmio module parameter.
v1: addressed RFC comment to remove enable_pvmmio module parameter
by pv capability check.
v2: rebase

Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: He, Min 
Cc: Jiang, Fei 
Cc: Gong, Zhipeng 
Cc: Yuan, Hang 
Cc: Zhiyuan Lv 
Signed-off-by: Xiaolin Zhang 
---
 drivers/gpu/drm/i915/i915_drv.h| 11 +++
 drivers/gpu/drm/i915/i915_pvinfo.h | 17 -
 drivers/gpu/drm/i915/i915_vgpu.c   | 19 +--
 3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef0..7b2d7cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,6 +56,7 @@
 
 #include "i915_params.h"
 #include "i915_reg.h"
+#include "i915_pvinfo.h"
 #include "i915_utils.h"
 
 #include "intel_bios.h"
@@ -1343,6 +1344,7 @@ struct i915_workarounds {
 struct i915_virtual_gpu {
bool active;
u32 caps;
+   u32 pv_caps;
 };
 
 /* used in computing the new watermarks state */
@@ -2853,6 +2855,11 @@ static inline bool intel_vgpu_active(struct 
drm_i915_private *dev_priv)
return dev_priv->vgpu.active;
 }
 
+static inline bool intel_vgpu_has_pvmmio(struct drm_i915_private *dev_priv)
+{
+   return dev_priv->vgpu.caps & VGT_CAPS_PVMMIO;
+}
+
 u32 i915_pipestat_enable_mask(struct drm_i915_private *dev_priv,
  enum pipe pipe);
 void
@@ -3878,4 +3885,8 @@ static inline int intel_hws_csb_write_index(struct 
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
 }
 
+#define PVMMIO_LEVEL_ENABLE(dev_priv, level)   \
+   (intel_vgpu_active(dev_priv) && intel_vgpu_has_pvmmio(dev_priv) \
+   && (dev_priv->vgpu.pv_caps & level))
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
index eeaa3d5..26709e8 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -49,12 +49,26 @@ enum vgt_g2v_type {
VGT_G2V_MAX,
 };
 
+#define VGPU_PVMMIO(vgpu) vgpu_vreg_t(vgpu, vgtif_reg(enable_pvmmio))
+
 /*
  * VGT capabilities type
  */
 #define VGT_CAPS_FULL_48BIT_PPGTT  BIT(2)
 #define VGT_CAPS_HWSP_EMULATIONBIT(3)
 #define VGT_CAPS_HUGE_GTT  BIT(4)
+#define VGT_CAPS_PVMMIOBIT(5)
+
+/*
+ * define different levels of PVMMIO optimization
+ */
+enum pvmmio_levels {
+   PVMMIO_ELSP_SUBMIT = 0x1,
+   PVMMIO_PLANE_UPDATE = 0x2,
+   PVMMIO_PLANE_WM_UPDATE = 0x4,
+   PVMMIO_MASTER_IRQ = 0x8,
+   PVMMIO_PPGTT_UPDATE = 0x10,
+};
 
 struct vgt_if {
u64 magic;  /* VGT_MAGIC */
@@ -106,8 +120,9 @@ struct vgt_if {
 
u32 execlist_context_descriptor_lo;
u32 execlist_context_descriptor_hi;
+   u32 enable_pvmmio;
 
-   u32  rsv7[0x200 - 24];/* pad to one page */
+   u32  rsv7[0x200 - 25];/* pad to one page */
 } __packed;
 
 #define vgtif_reg(x) \
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 869cf4a..907bbd2 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -76,9 +76,24 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
}
 
dev_priv->vgpu.caps = __raw_i915_read32(dev_priv, vgtif_reg(vgt_caps));
-
dev_priv->vgpu.active = true;
-   DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
+
+   if (!intel_vgpu_has_pvmmio(dev_priv)) {
+   DRM_INFO("Virtual GPU for Intel GVT-g detected\n");
+   return;
+   }
+
+   /* If guest wants to enable pvmmio, it needs to enable it explicitly
+* through vgt_if interface, and then read back the enable state from
+* gvt layer.
+*/
+   __raw_i915_write32(dev_priv, vgtif_reg(enable_pvmmio),
+   dev_priv->vgpu.pv_caps);
+   dev_priv->vgpu.pv_caps = __raw_i915_read32(dev_priv,
+   vgtif_reg(enable_pvmmio));
+
+   DRM_INFO("Virtual GPU for Intel GVT-g detected with pvmmio 0x%x\n",
+   dev_priv->vgpu.pv_caps);
 }
 
 bool intel_vgpu_has_full_48bit_ppgtt(struct drm_i915_private *dev_priv)
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 5/5] drm/i915: ppgtt update pvmmio optimization

[Xiaolin Zhang]

This patch extends g2v notification to notify host GVT-g of
ppgtt update from guest, including alloc_4lvl, clear_4lv4 and
insert_4lvl. It uses shared page to pass the additional params.
This patch also add one new pvmmio level to control ppgtt update.

Use PVMMIO_PPGTT_UPDATE to control this level of pvmmio optimization.

v0: RFC
v1: rebase
v2: added pv callbacks for vm.{allocate_va_range, insert_entries,
clear_range} within ppgtt.

Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: He, Min 
Cc: Jiang, Fei 
Cc: Gong, Zhipeng 
Cc: Yuan, Hang 
Cc: Zhiyuan Lv 
Signed-off-by: Xiaolin Zhang 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 67 +
 drivers/gpu/drm/i915/i915_pvinfo.h  |  3 ++
 drivers/gpu/drm/i915/i915_vgpu.c|  3 +-
 3 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 98d9a1e..b529f53 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -956,6 +956,25 @@ static void gen8_ppgtt_clear_4lvl(struct 
i915_address_space *vm,
}
 }
 
+static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm,
+ u64 start, u64 length)
+{
+   struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+   struct i915_pml4 *pml4 = >pml4;
+   struct drm_i915_private *dev_priv = vm->i915;
+   struct pv_ppgtt_update *pv_ppgtt =
+   _priv->vgpu.shared_page->pv_ppgtt;
+   u64 orig_start = start;
+   u64 orig_length = length;
+
+   gen8_ppgtt_clear_4lvl(vm, start, length);
+
+   pv_ppgtt->pdp = px_dma(pml4);
+   pv_ppgtt->start = orig_start;
+   pv_ppgtt->length = orig_length;
+   I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_CLEAR);
+}
+
 static inline struct sgt_dma {
struct scatterlist *sg;
dma_addr_t dma, max;
@@ -1197,6 +1216,25 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
}
 }
 
+static void gen8_ppgtt_insert_4lvl_pv(struct i915_address_space *vm,
+  struct i915_vma *vma,
+  enum i915_cache_level cache_level,
+  u32 flags)
+{
+   struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+   struct drm_i915_private *dev_priv = vm->i915;
+   struct pv_ppgtt_update *pv_ppgtt =
+   _priv->vgpu.shared_page->pv_ppgtt;
+
+   gen8_ppgtt_insert_4lvl(vm, vma, cache_level, flags);
+
+   pv_ppgtt->pdp = px_dma(>pml4);
+   pv_ppgtt->start = vma->node.start;
+   pv_ppgtt->length = vma->node.size;
+   pv_ppgtt->cache_level = cache_level;
+   I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_INSERT);
+}
+
 static void gen8_free_page_tables(struct i915_address_space *vm,
  struct i915_page_directory *pd)
 {
@@ -1466,6 +1504,30 @@ static int gen8_ppgtt_alloc_4lvl(struct 
i915_address_space *vm,
return -ENOMEM;
 }
 
+static int gen8_ppgtt_alloc_4lvl_pv(struct i915_address_space *vm,
+u64 start, u64 length)
+{
+   struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+   struct i915_pml4 *pml4 = >pml4;
+   struct drm_i915_private *dev_priv = vm->i915;
+   struct pv_ppgtt_update *pv_ppgtt =
+   _priv->vgpu.shared_page->pv_ppgtt;
+   int ret;
+   u64 orig_start = start;
+   u64 orig_length = length;
+
+   ret = gen8_ppgtt_alloc_4lvl(vm, start, length);
+   if (ret)
+   return ret;
+
+   pv_ppgtt->pdp = px_dma(pml4);
+   pv_ppgtt->start = orig_start;
+   pv_ppgtt->length = orig_length;
+   I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_ALLOC);
+
+   return 0;
+}
+
 static void gen8_dump_pdp(struct i915_hw_ppgtt *ppgtt,
  struct i915_page_directory_pointer *pdp,
  u64 start, u64 length,
@@ -1631,6 +1693,11 @@ static struct i915_hw_ppgtt *gen8_ppgtt_create(struct 
drm_i915_private *i915)
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc_4lvl;
ppgtt->vm.insert_entries = gen8_ppgtt_insert_4lvl;
ppgtt->vm.clear_range = gen8_ppgtt_clear_4lvl;
+   if (PVMMIO_LEVEL_ENABLE(i915, PVMMIO_PPGTT_UPDATE)) {
+   ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc_4lvl_pv;
+   ppgtt->vm.insert_entries = gen8_ppgtt_insert_4lvl_pv;
+   ppgtt->vm.clear_range = gen8_ppgtt_clear_4lvl_pv;
+   }
} else {
err = __pdp_init(>vm, >pdp);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 1e24c45..790db50 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -46,6 +46,9 @@ enum vgt_g2v_type {
VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,

[Intel-gfx] [PATCH v2 3/5] drm/i915: context submission pvmmio optimization

[Xiaolin Zhang]

It is performance optimization to reduce mmio trap numbers from 4 to
1 durning ELSP porting writing (context submission).

When context subission, to cache elsp_data[4] values in
the shared page, the last elsp_data[0] port writing will be trapped
to gvt for real context submission.

Use PVMMIO_ELSP_SUBMIT to control this level of pvmmio optimization.

v0: RFC
v1: rebase
v2: added pv ops for pv context submission. to maximize code resuse,
introduced 2 more ops (submit_ports & preempt_context) instead of 1 op
(set_default_submission) in engine structure. pv version of
submit_ports and preempt_context implemented.

Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: He, Min 
Cc: Jiang, Fei 
Cc: Gong, Zhipeng 
Cc: Yuan, Hang 
Cc: Zhiyuan Lv 
Signed-off-by: Xiaolin Zhang 
---
 drivers/gpu/drm/i915/i915_vgpu.c|  2 +
 drivers/gpu/drm/i915/intel_lrc.c| 88 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 ++
 3 files changed, 90 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index cb409d5..9870ea6 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -66,6 +66,8 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
 
BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
 
+   dev_priv->vgpu.pv_caps = PVMMIO_ELSP_SUBMIT;
+
magic = __raw_i915_read64(dev_priv, vgtif_reg(magic));
if (magic != VGT_MAGIC)
return;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 22b57b8..9e6ccf9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -460,6 +460,60 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
 }
 
+static void execlists_submit_ports_pv(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = >execlists;
+   struct execlist_port *port = execlists->port;
+   u32 __iomem *elsp =
+   engine->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));
+   u32 *elsp_data;
+   unsigned int n;
+   u32 descs[4];
+   int i = 0;
+
+   /*
+* ELSQ note: the submit queue is not cleared after being submitted
+* to the HW so we need to make sure we always clean it up. This is
+* currently ensured by the fact that we always write the same number
+* of elsq entries, keep this in mind before changing the loop below.
+*/
+   for (n = execlists_num_ports(execlists); n--; ) {
+   struct i915_request *rq;
+   unsigned int count;
+   u64 desc;
+
+   rq = port_unpack([n], );
+   if (rq) {
+   GEM_BUG_ON(count > !n);
+   if (!count++)
+   execlists_context_schedule_in(rq);
+   port_set([n], port_pack(rq, count));
+   desc = execlists_update_context(rq);
+   } else {
+   GEM_BUG_ON(!n);
+   desc = 0;
+   }
+   GEM_BUG_ON(i >= 4);
+   descs[i] = upper_32_bits(desc);
+   descs[i + 1] = lower_32_bits(desc);
+   i += 2;
+   }
+
+   spin_lock(>i915->vgpu.shared_page_lock);
+   elsp_data = engine->i915->vgpu.shared_page->elsp_data;
+   *elsp_data = descs[0];
+   *(elsp_data + 1) = descs[1];
+   *(elsp_data + 2) = descs[2];
+   writel(descs[3], elsp);
+   spin_unlock(>i915->vgpu.shared_page_lock);
+
+   /* we need to manually load the submit queue */
+   if (execlists->ctrl_reg)
+   writel(EL_CTRL_LOAD, execlists->ctrl_reg);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+}
+
 static bool ctx_single_port_submission(const struct intel_context *ce)
 {
return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
@@ -497,7 +551,6 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
 
GEM_BUG_ON(execlists->preempt_complete_status !=
   upper_32_bits(ce->lrc_desc));
-
/*
 * Switch to our empty preempt context so
 * the state of the GPU is known (idle).
@@ -516,6 +569,27 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
 }
 
+static void inject_preempt_context_pv(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = >execlists;
+   struct intel_context *ce =
+   to_intel_context(engine->i915->preempt_context, engine);
+   u32 __iomem *elsp =
+   engine->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));
+   u32 *elsp_data;
+
+   GEM_BUG_ON(execlists->preempt_complete_status !=
+  

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of KVMGT (Intel GVT-g for KVM)

[Xu, Terrence]

Hi all,



We are pleased to announce an update of Intel GVT-g for KVM.



Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core(TM) processors 
with Intel processor graphics.  A virtual GPU instance is maintained for each 
VM, with part of performance critical resources directly assigned. The 
capability of running native graphics driver inside a VM, without hypervisor 
intervention in performance critical paths, achieves a good balance among 
performance, feature, and sharing capability.





Repositories:

-Kernel: https://github.com/01org/gvt-linux  (tag: 2018-q3-gvt-stable-4.17)

-Qemu: https://github.com/01org/igvtg-qemu  (tag: 2018-q3-stable-2.12.0)



Platform Support:

-Server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with Intel 
Graphics processor

-Client platforms: Intel(r) Core(tm) 5th generation (code name: Broadwell), 
6th generation (code name: Skylake), 7th generation (code name: Kabylake) and 
7th SoC generation (code name: Broxton), the Broxton is new supported platform



Guest Operation System Validated:

-Windows7 32-bit, Window7 64-bit, Windows8.1 64-bit, Windows10 64-bit

-Ubuntu 18.04 64-bit



Major Changes since Q1'2018 Release:

-This update is based on kernel version 4.17 and Qemu version 2.12.

-Add the Broxton platform preliminary support for KVMGT.

-Improve stability of dma-buf feature with some GPU reset issues be fixed.

-More bug fixing and code refinement, please refer to git log.



Limitation or known issues:

-Due to graphics hardware resource limitation, the maximum number of 
Windows VM is 7.

-The pre-defined type 1, 2 or 4 of vGPU must be created for VM to install 
Windows 7 32-bit. vGPU type 8 is not allocated to have enough graphics resource 
to support Windows 7 32-bit.

-Some 3rd party applications/tools like GPU_Z, Passmark 9.0 running in 
Windows VM may meet BSOD error. The workaround is to add "kvm.ignore_msrs=1" in 
host kernel's command line to avoid this.

-There are still instability issues about Guest VM stability while the 
IOMMU feature is enabled on a few Broadwell and Kabylake machines. The 
workaround is to turn off IOMMU on Intel graphics device by adding 
"intel_iommu=igfx_off"  in Host kernel's command line.
-For Broxton, only Linux guest is currently supported, and the Linux guest 
kernel must be the same as the host kernel.





Useful links:

-Setup guide:

https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide



-New upstream architecture design introduction:

https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction



-Please subscribe to join the mailing list if you want to learn more about 
GVT-g project:

https://lists.01.org/mailman/listinfo/igvt-g



-Please subscribe to join the mailing list if you want to contribute/review 
latest GVT-g upstream patches:

https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev



-Official GVT-g portal:

https://01.org/igvt-g



-More information about background, architecture and others about Intel 
GVT-g, can be found at:

http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf

https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian





Important Note:

The KVMGT project should be considered a work in progress. As such it is not a 
complete product nor should it be considered one. Extra care should be taken 
when testing and configuring a system to use the KVMGT project.







Thanks

Terrence

Tel: +86-21-6116 5390

MP: +86-1356 4367 024

Mail: terrence...@intel.com



___

GVT-g mailing list

igv...@lists.01.org

https://lists.01.org/mailman/listinfo/igvt-g

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

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of XenGT (Intel GVT-g for Xen)

[Xu, Terrence]

Hi all,



We are pleased to announce an update of Intel GVT-g for Xen.



Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
starting from 4th generation Intel Core(TM) processors with Intel processor 
graphics. A virtual GPU instance is maintained for each VM, with part of 
performance critical resources directly assigned. The capability of running 
native graphics driver inside a VM, without hypervisor intervention in 
performance critical paths, achieves a good balance among performance, feature, 
and sharing capability. GVT-g for Xen hypervisor is XenGT.





Repositories

-Kernel: https://github.com/01org/gvt-linux (tag: 2018-q3-gvt-stable-4.17)

-Qemu: https://github.com/01org/igvtg-qemu (tag: 2018-q3-stable-2.12.0)

-Xen :  https://github.com/01org/igvtg-xen (tag: 2018-q1-xengt-stable-4.10)



Platform Support

-Server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with Intel 
Graphics processor

-Client platforms: Intel(r) Core(tm) 5th generation (code name: Broadwell), 
6th generation (code name: Skylake) and 7th generation (code name: Kabylake)



Guest Operation System Validated

-Windows7 32-bit, Window7 64-bit, Windows8.1 64-bit, Windows10 64-bit

-Ubuntu 18.04 64-bit



Major Changes since Q1'2018 Release

-This update is based on kernel version 4.17 and Qemu version 2.12.

-More bug fixing and code refinement, please refer to git log.



Limitation or known issues:

-Windows gfx driver 25.20.100.6326 is preferred for Windows 10 VM.

-Due to graphics hardware resource limitation, the maximum number of 
Windows VM is 7.

-The pre-defined type vgt_low_gm_sz=128/256/512 of option into HVM file 
must be created for VM to install Windows 7 32-bit. vGPU type 8 is not 
allocated to have enough graphics resource to support Windows 7 32-bit.

-If the default 1024x768 vm screen resolution couldn't satisfy your need, 
please add vgt_log_gm_sz=128/256/512 option into HVM file.

-There's corner case that Guest Windows 7 32bit VM may be killed 
automatically by Xen when Guest VM runs into TDR. This issues happens only on 
Broadwell platform. The workaround is to disable part of viridian feature in 
Guest VM hvm file by adding viridian=["all", "!apic_assist"].





Useful links:

-Setup guide:

https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide



-New upstream architecture design introduction:

https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction



-Please subscribe to join the mailing list if you want to learn more about 
GVT-g project:

https://lists.01.org/mailman/listinfo/igvt-g



-Please subscribe to join the mailing list if you want to contribute/review 
latest GVT-g upstream patches:

https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev



-Official GVT-g portal:

https://01.org/igvt-g



-More information about background, architecture and others about Intel 
GVT-g, can be found at:

https://01.org/igvt-g

https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-REWRITE%203RD%20v4.pdf

https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt





Important Note:

The XenGT project should be considered a work in progress. As such it is not a 
complete product nor should it be considered one. Extra care should be taken 
when testing and configuring a system to use the XenGT project.







Thanks

Terrence

Tel: +86-21-6116 5390

MP: +86-1356 4367 024

Mail: terrence...@intel.com



___

GVT-g mailing list

igv...@lists.01.org
https://lists.01.org/mailman/listinfo/igvt-g
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 2/8] drm/i915: Use the ddi_ports info to kill ugly CNL_WITH_PORT_F.

[Jani Nikula]

On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> Now that we have the number of ddi ports information available
> let's use it instead of that ugly platform macro.
>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 10 ++
>  drivers/gpu/drm/i915/i915_drv.h |  2 --
>  drivers/gpu/drm/i915/i915_irq.c |  5 ++---
>  drivers/gpu/drm/i915/intel_dp.c |  2 +-
>  drivers/gpu/drm/i915/intel_hotplug.c|  2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +-
>  6 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index baac35f698f9..83ab325c6675 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -239,6 +239,14 @@ intel_virt_detect_pch(const struct drm_i915_private 
> *dev_priv)
>   return id;
>  }
>  
> +static void intel_adjust_skus_differences(struct drm_i915_private *dev_priv)
> +{
> + /* Some Cannonlake SKUs have Port F */
> + if (IS_CANNONLAKE(dev_priv) &&
> + (INTEL_DEVID(dev_priv) & 0x0004) == 0x0004)
> + mkwrite_device_info(dev_priv)->ddi_ports = 6;
> +}

I'd like reduce the amount of device info stuff we adjust at probe, not
increase.

Long term, I'd like to make dev_priv->info a const pointer to the const
data in i915_pci.c, and make it truly immutable. We could have an
additional runtime device info to complement that, but this approach
calls for a more concrete split in const and non-const data, not "mostly
const but sometimes mutable".

I think I've chatted about this with Chris too.

BR,
Jani.

> +
>  static void intel_detect_pch(struct drm_i915_private *dev_priv)
>  {
>   struct pci_dev *pch = NULL;
> @@ -904,6 +912,8 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv)
>   if (ret < 0)
>   goto err_workqueues;
>  
> + intel_adjust_skus_differences(dev_priv);
> +
>   /* This must be called before any calls to HAS_PCH_* */
>   intel_detect_pch(dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7ad232849268..99e42df79ed8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2485,8 +2485,6 @@ intel_info(const struct drm_i915_private *dev_priv)
>(dev_priv)->info.gt == 2)
>  #define IS_CFL_GT3(dev_priv) (IS_COFFEELAKE(dev_priv) && \
>(dev_priv)->info.gt == 3)
> -#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> - (INTEL_DEVID(dev_priv) & 0x0004) == 
> 0x0004)
>  
>  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 5d1f53723388..63d676de3840 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2782,8 +2782,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   if (INTEL_GEN(dev_priv) >= 11)
>   tmp_mask |= ICL_AUX_CHANNEL_E;
>  
> - if (IS_CNL_WITH_PORT_F(dev_priv) ||
> - INTEL_GEN(dev_priv) >= 11)
> + if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
>   tmp_mask |= CNL_AUX_CHANNEL_F;
>  
>   if (iir & tmp_mask) {
> @@ -4220,7 +4219,7 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   if (INTEL_GEN(dev_priv) >= 11)
>   de_port_masked |= ICL_AUX_CHANNEL_E;
>  
> - if (IS_CNL_WITH_PORT_F(dev_priv) || INTEL_GEN(dev_priv) >= 11)
> + if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
>   de_port_masked |= CNL_AUX_CHANNEL_F;
>  
>   de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3384a9bbdafd..0ea0414ccef4 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -402,7 +402,7 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
>   return 54;
>  
>   /* For this SKU 8.1G is supported in all ports */
> - if (IS_CNL_WITH_PORT_F(dev_priv))
> + if (INTEL_INFO(dev_priv)->ddi_ports == 6)
>   return 81;
>  
>   /* For other SKUs, max rate on ports A and D is 5.4G */
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 648a13c6043c..05d1faf77048 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -101,7 +101,7 @@ enum hpd_pin intel_hpd_pin_default(struct 
> drm_i915_private *dev_priv,
>   case PORT_E:
>   return HPD_PORT_E;
>   case PORT_F:
> - if (IS_CNL_WITH_PORT_F(dev_priv))
> + if (IS_GEN10(dev_priv))
>   

Re: [Intel-gfx] [PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Quoting Daniel Vetter (2018-10-18 22:32:00)
> On Thu, Oct 18, 2018 at 6:57 PM Joonas Lahtinen
>  wrote:
> >
> > Hi Dave,
> >
> > Here comes the final set of fixes under -next-fixes umbrella.
> > Next one will be then from -fixes, assuming a release next Sun.
> >
> > Fixes for bunch of display related issues reported by users, then the
> > MST fixes that were dropped from Rodrigos PR + further Icelake fixes
> > and proactive improvements picked by tooling.
> >
> > Excuse for the slight accumulation as I skipped last week due to
> > travel like I warned.
> >
> > Regards, Joonas
> >
> > ***
> >
> > drm-intel-next-fixes-2018-10-18:
> > - Fix GPU hang on MacBook2,1 when booting in EFI mode (Bugzilla #105637)
> > - Fix garbled console on Y tiled BIOS framebuffer configs (Bugzilla #108264)
> > - Fix black screen on certain eDP panels eg. Dell XPS 9350 (Bugzilla 
> > #107489 and #105338)
> > - MST fixes that Rodrigo dropped from drm-intel-fixes and bunch of Icelake 
> > fixes
> 
> This won't work because it doesn't contain Lyude's core fix (+ the 2
> fixups). You either need to cherry-pick all of them (and then probably
> include the nouveau one), or none of them. Did the cherry-pick script
> not propose them, or something else? They're all cc: stable.

cherry-pick-next-fixes did not propose more. I did specifically ask
Rodrigo to drop the relevant stuff from drm-intel-fixes so that the
tooling would pick it up. What is there that is missing?

Regards, Joonas

> -Daniel
> 
> > - Then assorted proactive code fixes caught by CI or developers
> >
> > The following changes since commit ca4b869240d5810ebac6b1570ad7beffcfbac2f5:
> >
> >   Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux 
> > into drm-next (2018-10-11 14:53:45 +1000)
> >
> > are available in the Git repository at:
> >
> >   git://anongit.freedesktop.org/drm/drm-intel 
> > tags/drm-intel-next-fixes-2018-10-18
> >
> > for you to fetch changes up to 835fe6d75d14c1513910ed7f5665127fee12acc8:
> >
> >   firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake. (2018-10-18 
> > 10:36:10 +0300)
> >
> > 
> > - Fix GPU hang on MacBook2,1 when booting in EFI mode (Bugzilla #105637)
> > - Fix garbled console on Y tiled BIOS framebuffer configs (Bugzilla #108264)
> > - Fix black screen on certain eDP panels eg. Dell XPS 9350 (Bugzilla 
> > #107489 and #105338)
> > - MST fixes that Rodrigo dropped from drm-intel-fixes and bunch of Icelake 
> > fixes
> > - Then assorted proactive code fixes caught by CI or developers
> >
> > 
> > Anusha Srivatsa (1):
> >   firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake.
> >
> > Chris Wilson (3):
> >   drm/i915: Only reset seqno if actually idle
> >   drm/i915/selftests: Disable shrinker across mmap-exhaustion
> >   drm/i915: Large page offsets for pread/pwrite
> >
> > Imre Deak (1):
> >   drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
> >
> > Lyude Paul (3):
> >   drm/i915: Don't unset intel_connector->mst_port
> >   drm/i915: Skip vcpi allocation for MSTB ports that are gone
> >   drm/i915: Fix intel_dp_mst_best_encoder()
> >
> > Mahesh Kumar (2):
> >   drm/i915/icl: create function to identify combophy port
> >   drm/i915/icl: Fix DDI/TC port clk_off bits
> >
> > Manasi Navare (1):
> >   drm/i915/dp: Link train Fallback on eDP only if fallback link BW can 
> > fit panel's native mode
> >
> > Rodrigo Vivi (1):
> >   drm/i915/icl: Fix signal_levels
> >
> > Ville Syrjälä (3):
> >   drm/i915: Check fb stride against plane max stride
> >   drm/i915: Restore vblank interrupts earlier
> >   drm/i915: Use the correct crtc when sanitizing plane mapping
> >
> >  drivers/gpu/drm/i915/i915_debugfs.c  |   2 +-
> >  drivers/gpu/drm/i915/i915_gem.c  |  12 +-
> >  drivers/gpu/drm/i915/i915_reg.h  |   3 +
> >  drivers/gpu/drm/i915/intel_csr.c |   1 +
> >  drivers/gpu/drm/i915/intel_ddi.c |  36 --
> >  drivers/gpu/drm/i915/intel_display.c | 151 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  |  32 -
> >  drivers/gpu/drm/i915/intel_dp_link_training.c|  26 ++--
> >  drivers/gpu/drm/i915/intel_dp_mst.c  |  41 +++---
> >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> >  drivers/gpu/drm/i915/intel_sprite.c  |  22 
> >  drivers/gpu/drm/i915/selftests/i915_gem_object.c |   3 +
> >  12 files changed, 227 insertions(+), 104 deletions(-)
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add ppgtt to GVT GEM context

[Chris Wilson]

Quoting Zhenyu Wang (2018-10-19 04:05:20)
> On 2018.10.18 13:40:31 +0800, Xiong Zhang wrote:
> > Currently the guest couldn't boot up under GVT-g environment as the
> > following call trace exists:
> > [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 
> > 0100
> > [  272.504834] Call Trace:
> > [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> > [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> > [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> > [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> > [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> > [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> > [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> > [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> > [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> > 
> > GVT GEM context is created by i915_gem_context_create_gvt() which
> > doesn't allocate ppgtt. So GVT GEM context structure doesn't have
> > a valid i915_hw_ppgtt.
> > 
> > This patch create ppgtt table at GVT GEM context creation, then assign
> > shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
> > be used on GPU. So GVT GEM context has valid ppgtt address. But note
> > that this ppgtt only contain valid ppgtt root table address, the table
> > entry in this ppgtt structure are invalid.
> > 
> > Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for 
> > execlists")
> > 
> > Signed-off-by: Xiong Zhang 
> > Reviewed-by: Zhenyu Wang 
> 
> Any more comment for this? We need it for current gvt broken on drm-tip,
> and it requires to change i915 for gvt ppgtt allocation, so I assume it's
> better to be merged by i915 directly, or do you like a gvt pull instead?

You only needed ctx->ppgtt being set I thought, as you previously
ignored the initial PD bits in the context image and overwrote the
registers anyway.

Do you want what appears to be a significant change to gvt itself to
enter from i915?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 3/8] drm/i915/gen10: Prefer gen number than platform codename.

[Jani Nikula]

On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> Whenever possible let's move towards preferring gen number
> and or features instead of hard coding platform codename
> everywhere.

Rationale missing.

But for gem, agreed, it largely makes sense. For display, I'm not sure
if this is a good idea. Consider the likes of Geminilake. It's gen 9,
but largely gen 10 display. There'll be more stuff like that.

Now I don't know what the answer should be. But you need to consider the
conditions like

if (IS_CANNONLAKE() || IS_GEMINILAKE())

and

if (INTEL_GEN() == 9 && !IS_GEMINILAKE())

and figure out how to do that in a sensible way for display. Just
changing stuff from platforms to gen numbers isn't helpful for the
humans reading the code.

BR,
Jani.


>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/intel_cdclk.c  |  6 +++---
>  drivers/gpu/drm/i915/intel_ddi.c| 20 ++--
>  drivers/gpu/drm/i915/intel_display.c|  4 ++--
>  drivers/gpu/drm/i915/intel_dpll_mgr.c   |  2 +-
>  drivers/gpu/drm/i915/intel_mocs.c   |  2 +-
>  drivers/gpu/drm/i915/intel_pm.c |  2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  8 
>  8 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 99e42df79ed8..d19b38ef145b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2620,7 +2620,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>  
>  /* WaRsDisableCoarsePowerGating:skl,cnl */
>  #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
> - (IS_CANNONLAKE(dev_priv) || \
> + (IS_GEN10(dev_priv) || \
>IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
>  
>  #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 29075c763428..4aa6500604cc 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -2577,7 +2577,7 @@ void intel_update_max_cdclk(struct drm_i915_private 
> *dev_priv)
>   dev_priv->max_cdclk_freq = 648000;
>   else
>   dev_priv->max_cdclk_freq = 652800;
> - } else if (IS_CANNONLAKE(dev_priv)) {
> + } else if (IS_GEN10(dev_priv)) {
>   dev_priv->max_cdclk_freq = 528000;
>   } else if (IS_GEN9_BC(dev_priv)) {
>   u32 limit = I915_READ(SKL_DFSM) & SKL_DFSM_CDCLK_LIMIT_MASK;
> @@ -2797,7 +2797,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private 
> *dev_priv)
>   dev_priv->display.set_cdclk = skl_set_cdclk;
>   dev_priv->display.modeset_calc_cdclk =
>   skl_modeset_calc_cdclk;
> - } else if (IS_CANNONLAKE(dev_priv)) {
> + } else if (IS_GEN10(dev_priv)) {
>   dev_priv->display.set_cdclk = cnl_set_cdclk;
>   dev_priv->display.modeset_calc_cdclk =
>   cnl_modeset_calc_cdclk;
> @@ -2808,7 +2808,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private 
> *dev_priv)
>  
>   if (IS_ICELAKE(dev_priv))
>   dev_priv->display.get_cdclk = icl_get_cdclk;
> - else if (IS_CANNONLAKE(dev_priv))
> + else if (IS_GEN10(dev_priv))
>   dev_priv->display.get_cdclk = cnl_get_cdclk;
>   else if (IS_GEN9_BC(dev_priv))
>   dev_priv->display.get_cdclk = skl_get_cdclk;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6b9742baa5f2..cd627851f2a5 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -922,7 +922,7 @@ static int intel_ddi_hdmi_level(struct drm_i915_private 
> *dev_priv, enum port por
>   else
>   n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
>   default_entry = n_entries - 1;
> - } else if (IS_CANNONLAKE(dev_priv)) {
> + } else if (IS_GEN10(dev_priv)) {
>   cnl_get_buf_trans_hdmi(dev_priv, _entries);
>   default_entry = n_entries - 1;
>   } else if (IS_GEN9_LP(dev_priv)) {
> @@ -1743,7 +1743,7 @@ static void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>   skl_ddi_clock_get(encoder, pipe_config);
>   else if (IS_GEN9_LP(dev_priv))
>   bxt_ddi_clock_get(encoder, pipe_config);
> - else if (IS_CANNONLAKE(dev_priv))
> + else if (IS_GEN10(dev_priv))
>   cnl_ddi_clock_get(encoder, pipe_config);
>   else if (IS_ICELAKE(dev_priv))
>   icl_ddi_clock_get(encoder, pipe_config);
> @@ -2247,7 +2247,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder 
> *encoder)
>   _entries);
>   else
>   n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
> - } else if (IS_CANNONLAKE(dev_priv)) {
> + } else if 

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Fix unsigned overflow when calculating total data rate

[Maarten Lankhorst]

Op 18-10-18 om 16:53 schreef Ville Syrjälä:
> On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
>> On gen11, we can definitely smash the 32-bits barrier with just a
>> when we enable all planes in the next patch.
>>
>> Signed-off-by: Maarten Lankhorst 
> I guess the per-plane data rate is still <32bit (because it doesn't
> account for the refresh rate). But making everything 64bit seems safest.
With the current limits, we're already awfully close if we ever end up with 16 
bits per component formats.
> Reviewed-by: Ville Syrjälä 
>
> Now we could also improve the per-plane data rate to include the
> refresh rate and get rid of inaccurate drm_mode_vrefresh() in there.
Yeah would be nice. :)
>> ---
>>  drivers/gpu/drm/i915/intel_pm.c | 47 +++--
>>  1 file changed, 22 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 67a4d0735291..3b136fdfd24f 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -3784,7 +3784,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state 
>> *state)
>>  
>>  static u16 intel_get_ddb_size(struct drm_i915_private *dev_priv,
>>const struct intel_crtc_state *cstate,
>> -  const unsigned int total_data_rate,
>> +  const u64 total_data_rate,
>>const int num_active,
>>struct skl_ddb_allocation *ddb)
>>  {
>> @@ -3798,12 +3798,12 @@ static u16 intel_get_ddb_size(struct 
>> drm_i915_private *dev_priv,
>>  return ddb_size - 4; /* 4 blocks for bypass path allocation */
>>  
>>  adjusted_mode = >base.adjusted_mode;
>> -total_data_bw = (u64)total_data_rate * drm_mode_vrefresh(adjusted_mode);
>> +total_data_bw = total_data_rate * drm_mode_vrefresh(adjusted_mode);
>>  
>>  /*
>>   * 12GB/s is maximum BW supported by single DBuf slice.
>>   */
>> -if (total_data_bw >= GBps(12) || num_active > 1) {
>> +if (num_active > 1 || total_data_bw >= GBps(12)) {
>>  ddb->enabled_slices = 2;
>>  } else {
>>  ddb->enabled_slices = 1;
>> @@ -3816,7 +3816,7 @@ static u16 intel_get_ddb_size(struct drm_i915_private 
>> *dev_priv,
>>  static void
>>  skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
>> const struct intel_crtc_state *cstate,
>> -   const unsigned int total_data_rate,
>> +   const u64 total_data_rate,
>> struct skl_ddb_allocation *ddb,
>> struct skl_ddb_entry *alloc, /* out */
>> int *num_active /* out */)
>> @@ -4139,7 +4139,7 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
>> *intel_crtc,
>>  return 0;
>>  }
>>  
>> -static unsigned int
>> +static u64
>>  skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
>>   const struct drm_plane_state *pstate,
>>   const int plane)
>> @@ -4151,6 +4151,7 @@ skl_plane_relative_data_rate(const struct 
>> intel_crtc_state *cstate,
>>  struct drm_framebuffer *fb;
>>  u32 format;
>>  uint_fixed_16_16_t down_scale_amount;
>> +u64 rate;
>>  
>>  if (!intel_pstate->base.visible)
>>  return 0;
>> @@ -4177,28 +4178,26 @@ skl_plane_relative_data_rate(const struct 
>> intel_crtc_state *cstate,
>>  height /= 2;
>>  }
>>  
>> -data_rate = width * height * fb->format->cpp[plane];
>> +data_rate = width * height;
>>  
>>  down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
>>  
>> -return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
>> +rate = mul_round_up_u32_fixed16(data_rate, down_scale_amount);
>> +
>> +rate *= fb->format->cpp[plane];
>> +return rate;
>>  }
>>  
>> -/*
>> - * We don't overflow 32 bits. Worst case is 3 planes enabled, each fetching
>> - * a 8192x4096@32bpp framebuffer:
>> - *   3 * 4096 * 8192  * 4 < 2^32
>> - */
>> -static unsigned int
>> +static u64
>>  skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
>> - unsigned int *plane_data_rate,
>> - unsigned int *uv_plane_data_rate)
>> + u64 *plane_data_rate,
>> + u64 *uv_plane_data_rate)
>>  {
>>  struct drm_crtc_state *cstate = _cstate->base;
>>  struct drm_atomic_state *state = cstate->state;
>>  struct drm_plane *plane;
>>  const struct drm_plane_state *pstate;
>> -unsigned int total_data_rate = 0;
>> +u64 total_data_rate = 0;
>>  
>>  if (WARN_ON(!state))
>>  return 0;
>> @@ -4206,7 +4205,7 @@ skl_get_total_relative_data_rate(struct 
>> intel_crtc_state *intel_cstate,
>>  /* Calculate and cache data rate 

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Fix unsigned overflow when calculating total data rate

[Maarten Lankhorst]

Op 18-10-18 om 17:11 schreef Ville Syrjälä:
> On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
>> On gen11, we can definitely smash the 32-bits barrier with just a
>> when we enable all planes in the next patch.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_pm.c | 47 +++--
>>  1 file changed, 22 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 67a4d0735291..3b136fdfd24f 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -3784,7 +3784,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state 
>> *state)
>>  
>>  static u16 intel_get_ddb_size(struct drm_i915_private *dev_priv,
>>const struct intel_crtc_state *cstate,
>> -  const unsigned int total_data_rate,
>> +  const u64 total_data_rate,
>>const int num_active,
>>struct skl_ddb_allocation *ddb)
>>  {
>> @@ -3798,12 +3798,12 @@ static u16 intel_get_ddb_size(struct 
>> drm_i915_private *dev_priv,
>>  return ddb_size - 4; /* 4 blocks for bypass path allocation */
>>  
>>  adjusted_mode = >base.adjusted_mode;
>> -total_data_bw = (u64)total_data_rate * drm_mode_vrefresh(adjusted_mode);
>> +total_data_bw = total_data_rate * drm_mode_vrefresh(adjusted_mode);
>>  
>>  /*
>>   * 12GB/s is maximum BW supported by single DBuf slice.
>>   */
>> -if (total_data_bw >= GBps(12) || num_active > 1) {
>> +if (num_active > 1 || total_data_bw >= GBps(12)) {
>>  ddb->enabled_slices = 2;
>>  } else {
>>  ddb->enabled_slices = 1;
>> @@ -3816,7 +3816,7 @@ static u16 intel_get_ddb_size(struct drm_i915_private 
>> *dev_priv,
>>  static void
>>  skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
>> const struct intel_crtc_state *cstate,
>> -   const unsigned int total_data_rate,
>> +   const u64 total_data_rate,
>> struct skl_ddb_allocation *ddb,
>> struct skl_ddb_entry *alloc, /* out */
>> int *num_active /* out */)
>> @@ -4139,7 +4139,7 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
>> *intel_crtc,
>>  return 0;
>>  }
>>  
>> -static unsigned int
>> +static u64
>>  skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
>>   const struct drm_plane_state *pstate,
>>   const int plane)
>> @@ -4151,6 +4151,7 @@ skl_plane_relative_data_rate(const struct 
>> intel_crtc_state *cstate,
>>  struct drm_framebuffer *fb;
>>  u32 format;
>>  uint_fixed_16_16_t down_scale_amount;
>> +u64 rate;
>>  
>>  if (!intel_pstate->base.visible)
>>  return 0;
>> @@ -4177,28 +4178,26 @@ skl_plane_relative_data_rate(const struct 
>> intel_crtc_state *cstate,
>>  height /= 2;
>>  }
>>  
>> -data_rate = width * height * fb->format->cpp[plane];
>> +data_rate = width * height;
>>  
>>  down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
>>  
>> -return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
>> +rate = mul_round_up_u32_fixed16(data_rate, down_scale_amount);
>> +
>> +rate *= fb->format->cpp[plane];
>> +return rate;
>>  }
>>  
>> -/*
>> - * We don't overflow 32 bits. Worst case is 3 planes enabled, each fetching
>> - * a 8192x4096@32bpp framebuffer:
>> - *   3 * 4096 * 8192  * 4 < 2^32
>> - */
>> -static unsigned int
>> +static u64
>>  skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
>> - unsigned int *plane_data_rate,
>> - unsigned int *uv_plane_data_rate)
>> + u64 *plane_data_rate,
>> + u64 *uv_plane_data_rate)
>>  {
>>  struct drm_crtc_state *cstate = _cstate->base;
>>  struct drm_atomic_state *state = cstate->state;
>>  struct drm_plane *plane;
>>  const struct drm_plane_state *pstate;
>> -unsigned int total_data_rate = 0;
>> +u64 total_data_rate = 0;
>>  
>>  if (WARN_ON(!state))
>>  return 0;
>> @@ -4206,7 +4205,7 @@ skl_get_total_relative_data_rate(struct 
>> intel_crtc_state *intel_cstate,
>>  /* Calculate and cache data rate for each plane */
>>  drm_atomic_crtc_state_for_each_plane_state(plane, pstate, cstate) {
>>  enum plane_id plane_id = to_intel_plane(plane)->id;
>> -unsigned int rate;
>> +u64 rate;
>>  
>>  /* packed/y */
>>  rate = skl_plane_relative_data_rate(intel_cstate,
>> @@ -4325,11 +4324,11 @@ skl_allocate_pipe_ddb(struct intel_crtc_state 
>> *cstate,
>>  uint16_t alloc_size, 

[Intel-gfx] [PATCH v1] drm/i915/icl: Define MOCS table for Icelake

[Tomasz Lis]

The table has been unified across OSes to minimize virtualization overhead.

The MOCS table is now versioned; the patch includes version 1 entries.

BSpec: 34007
BSpec: 560
Signed-off-by: Tomasz Lis 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Zhenyu Wang 
---
 drivers/gpu/drm/i915/intel_mocs.c | 246 +-
 1 file changed, 244 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index 77e9871..b76d6db 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
 #define LE_SCC(value)  ((value) << 8)
 #define LE_PFM(value)  ((value) << 11)
 #define LE_SCF(value)  ((value) << 14)
+#define LE_CoS(value)  ((value) << 15)
+#define LE_SSE(value)  ((value) << 17)
 
 /* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
 #define L3_ESC(value)  ((value) << 0)
@@ -96,6 +98,243 @@ struct drm_i915_mocs_table {
  *   may only be updated incrementally by adding entries at the
  *   end.
  */
+static const struct drm_i915_mocs_entry icelake_mocs_table[] = {
+   [0] = {
+ /* Base - Uncached (Deprecated) */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [1] = {
+ /* Base - L3 + LeCC:PAT (Deprecated) */
+ .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   [2] = {
+ /* Base - L3 + LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   [3] = {
+ /* Base - Uncached */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [4] = {
+ /* Base - L3 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   [5] = {
+ /* Base - LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [6] = {
+ /* Age 0 - LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [7] = {
+ /* Age 0 - L3 + LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   [8] = {
+ /* Age: Don't Chg. - LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(2) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [9] = {
+ /* Age: Don't Chg. - L3 + LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(2) | LE_AOM(0) | LE_RSC(0) | 

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Fix unsigned overflow when calculating total data rate

[Maarten Lankhorst]

Op 19-10-18 om 15:06 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-10-19 14:03:47)
>> Op 18-10-18 om 17:11 schreef Ville Syrjälä:
>>> On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
 @@ -4402,8 +4401,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state 
 *cstate,
   * result is < available as data_rate / total_data_rate < 1
   */
  plane_blocks = minimum[plane_id];
 -plane_blocks += div_u64((uint64_t)alloc_size * data_rate,
 -total_data_rate);
 +plane_blocks += alloc_size * data_rate / total_data_rate;
>>> I failed to spot the raw 64bit divisions here. Fortunately CI caught
>>> them (yay). Need to be fixed.
>> No we can't, if we make the per plane data rate 64-bits, the divisor will 
>> overflow a div_u64..
> div64_u64()
> -Chris

Right, will use that.

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

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Fix unsigned overflow when calculating total data rate

[Chris Wilson]

Quoting Maarten Lankhorst (2018-10-19 14:03:47)
> Op 18-10-18 om 17:11 schreef Ville Syrjälä:
> > On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
> >> @@ -4402,8 +4401,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state 
> >> *cstate,
> >>   * result is < available as data_rate / total_data_rate < 1
> >>   */
> >>  plane_blocks = minimum[plane_id];
> >> -plane_blocks += div_u64((uint64_t)alloc_size * data_rate,
> >> -total_data_rate);
> >> +plane_blocks += alloc_size * data_rate / total_data_rate;
> > I failed to spot the raw 64bit divisions here. Fortunately CI caught
> > them (yay). Need to be fixed.
> No we can't, if we make the per plane data rate 64-bits, the divisor will 
> overflow a div_u64..

div64_u64()
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915/icl: Preempt-to-idle support in execlists.

[Lis, Tomasz]

On 2018-10-16 12:53, Joonas Lahtinen wrote:

Quoting Tomasz Lis (2018-10-15 20:29:18)

The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.

Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle directly. In Icelake it is
possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.

This patch does not cover using the new preemption mechanism when GuC is
active.

v2: Added needs_preempt_context() change so that it is not created when
 preempt-to-idle is supported. (Chris)
 Updated setting HWACK flag so that it is cleared after
 preempt-to-dle. (Chris, Daniele)
 Updated to use I915_ENGINE_HAS_PREEMPTION flag. (Chris)

v3: Fixed needs_preempt_context() change. (Chris)
 Merged preemption trigger functions to one. (Chris)
 Fixed conyext state tonot assume COMPLETED_MASK after preemption,
 since idle-to-idle case will not have it set.

v4: Simplified needs_preempt_context() change. (Daniele)
 Removed clearing HWACK flag in idle-to-idle preempt. (Daniele)

v5: Renamed inject_preempt_context(). (Daniele)
 Removed duplicated GEM_BUG_ON() on HWACK (Daniele)

Bspec: 18922
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Winiarski 
Cc: Mika Kuoppala 
Reviewed-by: Daniele Ceraolo Spurio 

This R-b was on v4, and should be indicated with # v4 comment.

The commit message doesn't say much about why preempting to idle is
beneficial? The pre-Gen11 codepath needs to be maintained anyway.

Regards, Joonas

The benefit is one less context switch - there is no "preempt context".
-Tomasz


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

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Avoid initializing framebuffer without pipes

[Chris Wilson]

Quoting Mika Kuoppala (2018-10-19 13:30:37)
> If we try to initialize a framebuffer without pipes, we get oops
> as we fail to get valid crtc for a PIPE A, on trying to find
> pitch limits. This is easily demonstrated by trying to init
> framebuffer with displays disabled by 'i915.disable_display=1'
> kernel cmdline.
> 
> Fix this by omitting framebuffer init early if there are no pipes.
> 
> Testcase: igt/kms_addfb_basic
> Cc: Ville Syrjala 
> Signed-off-by: Mika Kuoppala 

To which Ville previously replied with the suggestion of preventing the
ioctl from even getting this far, to whit

if (!INTEL_INFO(dev_priv)->num_pipes)
i915->drm.driver_features &= ~DRIVER_MODESET

See https://patchwork.freedesktop.org/series/51000/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v4.

[Maarten Lankhorst]

Op 18-10-18 om 18:00 schreef Ville Syrjälä:
> On Thu, Oct 18, 2018 at 01:51:29PM +0200, Maarten Lankhorst wrote:
>> To make NV12 working on icl, we need to update 2 planes simultaneously.
>> I've chosen to do this in the CRTC step after plane validation is done,
>> so we know what planes are (in)visible. The linked Y plane will get
>> updated in intel_plane_update_planes_on_crtc(), by the call to
>> update_slave, which gets the master's plane_state as argument.
>>
>> The link requires both planes for atomic_update to work,
>> so make sure skl_ddb_add_affected_planes() adds both states.
>>
>> Changes since v1:
>> - Introduce icl_is_nv12_y_plane(), instead of hardcoding sprite numbers.
>> - Put all the state updating login in intel_plane_atomic_check_with_state().
>> - Clean up changes in intel_plane_atomic_check().
>> Changes since v2:
>> - Fix intel_atomic_get_old_plane_state() to actually return old state.
>> - Move visibility changes to preparation patch.
>> - Only try to find a Y plane on gen11, earlier platforms only require
>>   a single plane.
>> Changes since v3:
>> - Fix checkpatch warning about to_intel_crtc() usage.
>> - Add affected planes from icl_add_linked_planes() before check_planes(),
>>   it's a cleaner way to do this. (Ville)
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_atomic_plane.c | 74 -
>>  drivers/gpu/drm/i915/intel_display.c  | 81 +++
>>  drivers/gpu/drm/i915/intel_drv.h  | 53 +++
>>  drivers/gpu/drm/i915/intel_pm.c   | 12 +++-
>>  4 files changed, 202 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
>> b/drivers/gpu/drm/i915/intel_atomic_plane.c
>> index b957ad63cd87..154ea3dc344f 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
>> @@ -122,7 +122,11 @@ int intel_plane_atomic_check_with_state(const struct 
>> intel_crtc_state *old_crtc_
>>  crtc_state->nv12_planes &= ~BIT(intel_plane->id);
>>  intel_state->base.visible = false;
>>  
>> -/* If this is a cursor plane, no further checks are needed. */
>> +/* Destroy the link */
>> +intel_state->linked_plane = NULL;
>> +intel_state->slave = false;
>> +
>> +/* If this is a cursor or Y plane, no further checks are needed. */
>>  if (!intel_state->base.crtc && !old_plane_state->base.crtc)
>>  return 0;
>>  
>> @@ -143,27 +147,44 @@ int intel_plane_atomic_check_with_state(const struct 
>> intel_crtc_state *old_crtc_
>> state);
>>  }
>>  
>> -static int intel_plane_atomic_check(struct drm_plane *plane,
>> -struct drm_plane_state *new_plane_state)
>> +static int intel_plane_atomic_check(struct drm_plane *drm_plane,
>> +struct drm_plane_state *new_drm_plane_state)
> My new cunning plane is to call these _plane, _new_plane_state etc.
> It should discourage people from using them and the aliasing
> intel_ types at the same time. And it avoids polluting the namespace
> for things we don't really want to use. 
>
> I already snuck in some uses of this ;)
>
>>  {
>> -struct drm_atomic_state *state = new_plane_state->state;
>> -const struct drm_plane_state *old_plane_state =
>> -drm_atomic_get_old_plane_state(state, plane);
>> -struct drm_crtc *crtc = new_plane_state->crtc ?: old_plane_state->crtc;
>> -const struct drm_crtc_state *old_crtc_state;
>> -struct drm_crtc_state *new_crtc_state;
>> -
>> -new_plane_state->visible = false;
>> +struct intel_atomic_state *state =
>> +to_intel_atomic_state(new_drm_plane_state->state);
>> +struct intel_plane *plane = to_intel_plane(drm_plane);
>> +const struct intel_plane_state *old_plane_state =
>> +intel_atomic_get_old_plane_state(state, plane);
>> +struct intel_plane_state *new_plane_state =
>> +to_intel_plane_state(new_drm_plane_state);
>> +struct intel_crtc *crtc =
>> +to_intel_crtc(new_plane_state->base.crtc ?:
>> +  old_plane_state->base.crtc);
>> +const struct intel_crtc_state *old_crtc_state;
>> +struct intel_crtc_state *new_crtc_state;
>> +struct intel_plane *linked = old_plane_state->linked_plane;
>> +
>> +if (linked && !crtc) {
>> +const struct intel_plane_state *old_linked_state =
>> +intel_atomic_get_old_plane_state(state, linked);
> Plane without a crtc that happens to have a linked plane
> attached to it...
>
> I guess that implies that 'plane' here is the slave and
> it was already active during the previous state (otherwise
> it would not have been linked to the other plane). So that
> means the master plane must have a valid crtc in its old
> plane state.
>
> Did I decode that correctly?
Correct.
> Maybe what we want to do here is to just always clear the
> 

Re: [Intel-gfx] [RFC 2/8] drm/i915: Use the ddi_ports info to kill ugly CNL_WITH_PORT_F.

[Lucas De Marchi]

On Fri, Oct 19, 2018 at 10:39:46AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > Now that we have the number of ddi ports information available
> > let's use it instead of that ugly platform macro.
> >
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 10 ++
> >  drivers/gpu/drm/i915/i915_drv.h |  2 --
> >  drivers/gpu/drm/i915/i915_irq.c |  5 ++---
> >  drivers/gpu/drm/i915/intel_dp.c |  2 +-
> >  drivers/gpu/drm/i915/intel_hotplug.c|  2 +-
> >  drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +-
> >  6 files changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index baac35f698f9..83ab325c6675 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -239,6 +239,14 @@ intel_virt_detect_pch(const struct drm_i915_private 
> > *dev_priv)
> > return id;
> >  }
> >  
> > +static void intel_adjust_skus_differences(struct drm_i915_private 
> > *dev_priv)
> > +{
> > +   /* Some Cannonlake SKUs have Port F */
> > +   if (IS_CANNONLAKE(dev_priv) &&
> > +   (INTEL_DEVID(dev_priv) & 0x0004) == 0x0004)
> > +   mkwrite_device_info(dev_priv)->ddi_ports = 6;
> > +}
> 
> I'd like reduce the amount of device info stuff we adjust at probe, not
> increase.
> 
> Long term, I'd like to make dev_priv->info a const pointer to the const
> data in i915_pci.c, and make it truly immutable. We could have an
> additional runtime device info to complement that, but this approach
> calls for a more concrete split in const and non-const data, not "mostly
> const but sometimes mutable".

I agree with this. I'd also like to have a const dev_info. What I think we need 
is to split
in what is const what can be changed in runtime/initialization.

However, I'm not fond on using the number of ddi ports to take decisions in the 
code not
related to the number of ports, but rather with other things of that sku. See 
below.

> 
> I think I've chatted about this with Chris too.
> 
> BR,
> Jani.
> 
> > +
> >  static void intel_detect_pch(struct drm_i915_private *dev_priv)
> >  {
> > struct pci_dev *pch = NULL;
> > @@ -904,6 +912,8 @@ static int i915_driver_init_early(struct 
> > drm_i915_private *dev_priv)
> > if (ret < 0)
> > goto err_workqueues;
> >  
> > +   intel_adjust_skus_differences(dev_priv);
> > +
> > /* This must be called before any calls to HAS_PCH_* */
> > intel_detect_pch(dev_priv);
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 7ad232849268..99e42df79ed8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2485,8 +2485,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  (dev_priv)->info.gt == 2)
> >  #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
> >  (dev_priv)->info.gt == 3)
> > -#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> > -   (INTEL_DEVID(dev_priv) & 0x0004) == 
> > 0x0004)
> >  
> >  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 5d1f53723388..63d676de3840 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2782,8 +2782,7 @@ gen8_de_irq_handler(struct drm_i915_private 
> > *dev_priv, u32 master_ctl)
> > if (INTEL_GEN(dev_priv) >= 11)
> > tmp_mask |= ICL_AUX_CHANNEL_E;
> >  
> > -   if (IS_CNL_WITH_PORT_F(dev_priv) ||
> > -   INTEL_GEN(dev_priv) >= 11)
> > +   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
> > tmp_mask |= CNL_AUX_CHANNEL_F;

ok, this is directly related to the number of ports

> >  
> > if (iir & tmp_mask) {
> > @@ -4220,7 +4219,7 @@ static void gen8_de_irq_postinstall(struct 
> > drm_i915_private *dev_priv)
> > if (INTEL_GEN(dev_priv) >= 11)
> > de_port_masked |= ICL_AUX_CHANNEL_E;
> >  
> > -   if (IS_CNL_WITH_PORT_F(dev_priv) || INTEL_GEN(dev_priv) >= 11)
> > +   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
> > de_port_masked |= CNL_AUX_CHANNEL_F;
> >  
> > de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 3384a9bbdafd..0ea0414ccef4 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -402,7 +402,7 @@ static int cnl_max_source_rate(struct intel_dp 
> > *intel_dp)
> > return 54;
> >  
> > /* For this SKU 8.1G is supported in all ports */
> > -   if (IS_CNL_WITH_PORT_F(dev_priv))
> > +   if 

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v4.

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 04:22:29PM +0200, Maarten Lankhorst wrote:
> Op 18-10-18 om 18:00 schreef Ville Syrjälä:
> > On Thu, Oct 18, 2018 at 01:51:29PM +0200, Maarten Lankhorst wrote:
> >> To make NV12 working on icl, we need to update 2 planes simultaneously.
> >> I've chosen to do this in the CRTC step after plane validation is done,
> >> so we know what planes are (in)visible. The linked Y plane will get
> >> updated in intel_plane_update_planes_on_crtc(), by the call to
> >> update_slave, which gets the master's plane_state as argument.
> >>
> >> The link requires both planes for atomic_update to work,
> >> so make sure skl_ddb_add_affected_planes() adds both states.
> >>
> >> Changes since v1:
> >> - Introduce icl_is_nv12_y_plane(), instead of hardcoding sprite numbers.
> >> - Put all the state updating login in 
> >> intel_plane_atomic_check_with_state().
> >> - Clean up changes in intel_plane_atomic_check().
> >> Changes since v2:
> >> - Fix intel_atomic_get_old_plane_state() to actually return old state.
> >> - Move visibility changes to preparation patch.
> >> - Only try to find a Y plane on gen11, earlier platforms only require
> >>   a single plane.
> >> Changes since v3:
> >> - Fix checkpatch warning about to_intel_crtc() usage.
> >> - Add affected planes from icl_add_linked_planes() before check_planes(),
> >>   it's a cleaner way to do this. (Ville)
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/intel_atomic_plane.c | 74 -
> >>  drivers/gpu/drm/i915/intel_display.c  | 81 +++
> >>  drivers/gpu/drm/i915/intel_drv.h  | 53 +++
> >>  drivers/gpu/drm/i915/intel_pm.c   | 12 +++-
> >>  4 files changed, 202 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> >> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> >> index b957ad63cd87..154ea3dc344f 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> >> @@ -122,7 +122,11 @@ int intel_plane_atomic_check_with_state(const struct 
> >> intel_crtc_state *old_crtc_
> >>crtc_state->nv12_planes &= ~BIT(intel_plane->id);
> >>intel_state->base.visible = false;
> >>  
> >> -  /* If this is a cursor plane, no further checks are needed. */
> >> +  /* Destroy the link */
> >> +  intel_state->linked_plane = NULL;
> >> +  intel_state->slave = false;
> >> +
> >> +  /* If this is a cursor or Y plane, no further checks are needed. */
> >>if (!intel_state->base.crtc && !old_plane_state->base.crtc)
> >>return 0;
> >>  
> >> @@ -143,27 +147,44 @@ int intel_plane_atomic_check_with_state(const struct 
> >> intel_crtc_state *old_crtc_
> >>   state);
> >>  }
> >>  
> >> -static int intel_plane_atomic_check(struct drm_plane *plane,
> >> -  struct drm_plane_state *new_plane_state)
> >> +static int intel_plane_atomic_check(struct drm_plane *drm_plane,
> >> +  struct drm_plane_state *new_drm_plane_state)
> > My new cunning plane is to call these _plane, _new_plane_state etc.
> > It should discourage people from using them and the aliasing
> > intel_ types at the same time. And it avoids polluting the namespace
> > for things we don't really want to use. 
> >
> > I already snuck in some uses of this ;)
> >
> >>  {
> >> -  struct drm_atomic_state *state = new_plane_state->state;
> >> -  const struct drm_plane_state *old_plane_state =
> >> -  drm_atomic_get_old_plane_state(state, plane);
> >> -  struct drm_crtc *crtc = new_plane_state->crtc ?: old_plane_state->crtc;
> >> -  const struct drm_crtc_state *old_crtc_state;
> >> -  struct drm_crtc_state *new_crtc_state;
> >> -
> >> -  new_plane_state->visible = false;
> >> +  struct intel_atomic_state *state =
> >> +  to_intel_atomic_state(new_drm_plane_state->state);
> >> +  struct intel_plane *plane = to_intel_plane(drm_plane);
> >> +  const struct intel_plane_state *old_plane_state =
> >> +  intel_atomic_get_old_plane_state(state, plane);
> >> +  struct intel_plane_state *new_plane_state =
> >> +  to_intel_plane_state(new_drm_plane_state);
> >> +  struct intel_crtc *crtc =
> >> +  to_intel_crtc(new_plane_state->base.crtc ?:
> >> +old_plane_state->base.crtc);
> >> +  const struct intel_crtc_state *old_crtc_state;
> >> +  struct intel_crtc_state *new_crtc_state;
> >> +  struct intel_plane *linked = old_plane_state->linked_plane;
> >> +
> >> +  if (linked && !crtc) {
> >> +  const struct intel_plane_state *old_linked_state =
> >> +  intel_atomic_get_old_plane_state(state, linked);
> > Plane without a crtc that happens to have a linked plane
> > attached to it...
> >
> > I guess that implies that 'plane' here is the slave and
> > it was already active during the previous state (otherwise
> > it would not have been linked to the 

Re: [Intel-gfx] [PATCH v1] drm/i915/icl: Define MOCS table for Icelake

[Daniele Ceraolo Spurio]

On 19/10/18 08:19, Tomasz Lis wrote:

The table has been unified across OSes to minimize virtualization overhead.

The MOCS table is now versioned; the patch includes version 1 entries.


A bit more explanation is required here. We need to make clear the fact 
that existing entries in the table for a given gen will not change in 
new versions of the table and only new entries might be added. Also the 
fact that since the table is in the specs we expect the users to know 
what each entry of the table means and we're therefore deprecating 
exposing the entries in the uapi with an enum.
Might also be worth mentioning that the first 3 entries are compatible 
with the legacy i915 entries for previous gen but that this is not 
guaranteed on future gens so userland drivers need to use the ICL 
timeframe to transition.


Lastly, we need a way to query what version of the table the kernel is 
programming in HW.




BSpec: 34007
BSpec: 560
Signed-off-by: Tomasz Lis 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Zhenyu Wang 


CC some mesa people here? not sure who the right contact would be for this


---
  drivers/gpu/drm/i915/intel_mocs.c | 246 +-
  1 file changed, 244 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index 77e9871..b76d6db 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
  #define LE_SCC(value) ((value) << 8)
  #define LE_PFM(value) ((value) << 11)
  #define LE_SCF(value) ((value) << 14)
+#define LE_CoS(value)  ((value) << 15)
+#define LE_SSE(value)  ((value) << 17)
  
  /* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */

  #define L3_ESC(value) ((value) << 0)
@@ -96,6 +98,243 @@ struct drm_i915_mocs_table {
   *   may only be updated incrementally by adding entries at the
   *   end.
   */
+static const struct drm_i915_mocs_entry icelake_mocs_table[] = {
+   [0] = {
+ /* Base - Uncached (Deprecated) */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [1] = {
+ /* Base - L3 + LeCC:PAT (Deprecated) */
+ .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   [2] = {
+ /* Base - L3 + LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   [3] = {
+ /* Base - Uncached */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [4] = {
+ /* Base - L3 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   [5] = {
+ /* Base - LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [6] = {
+ /* Age 0 - LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0) | LE_CoS(0) | LE_SSE(0),
+
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   [7] = {
+ /* Age 0 - L3 + LLC */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+ 

[Intel-gfx] [PATCH xf86-video-intel] sna: Switch back to hwcursor on the next cursor update

[Ville Syrjala]

From: Ville Syrjälä 

Once we've switched to using the swcursor (possibly
due to the cursor ioctl failing) we currently keep
using the swcursor until the modeset.

That's not particularly great as the swcursor has several
issues. Apart from the (presumably expected) flicker,
the cursor also tends to leave horrible trails behind
around dri2/3 windows (happens with tearfree at least).

To avoid some of that let's try to switch back to the hwcursor
a bit sooner. We can do that neatly via the convenient swcursor
block handler.

References: https://bugs.freedesktop.org/show_bug.cgi?id=106935
Signed-off-by: Ville Syrjälä 
---
 src/sna/sna_display.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 96e7b1bc50d3..4fdeebd2497c 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -6285,10 +6285,15 @@ static void enable_fb_access(ScrnInfoPtr scrn, int 
state)
 
 static void __restore_swcursor(ScrnInfoPtr scrn)
 {
+   struct sna *sna = to_sna(scrn);
+
DBG(("%s: attempting to restore SW cursor\n", __FUNCTION__));
enable_fb_access(scrn, FALSE);
enable_fb_access(scrn, TRUE);
 
+   /* Try to switch back to the HW cursor on the next cursor update */
+   sna->cursor.disable = false;
+
RemoveBlockAndWakeupHandlers((void *)__restore_swcursor,
 (void *)NoopDDA,
 scrn);
-- 
2.18.1

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

Re: [Intel-gfx] [RFC 4/8] drm/i915: Group gen 10 display.

[Lucas De Marchi]

On Fri, Oct 19, 2018 at 01:33:08PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 19, 2018 at 10:30:46AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > > On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > > > Continuing with the goal of use less platform codenames:
> > > > let's group platforms who has gen10 display.
> > > 
> > > Ahah, so this answers my question in the previous patch. ;)
> > > 
> > > So we already have HAS_GMCH_DISPLAY().
> > 
> > We also have HAS_DDI, which I guess you could call gen8 display :-)
> 
> There's also these interesting gen designations in some old docs:
> ctg/elk = gen5.5
> ilk = gen5.75
> I guess we could more or less call all of that as gen5 display.
> 
> And of course we have the other oddballs like vlv/chv which are
> sort of mismash of i965, ctg/elk, ibx, and custom stuff. Also
> pnv is mostly gen3 display except for a few bits that were
> snatched from i965.
> 
> Not sure we have enough numbers for all that without resotring to
> fractions. And no one could anyway remember what all the different
> numbers mean.

I think we should approximate to the closest one, but prefer using gen_display 
number
checks for cases in which it's clear from the spec the separation.

For other things we will need more fine grained flags, that can be used across
gens or to differentiate features within a single gen.



Lucas De Marchi


> 
> > 
> > > If we're going to make gen10 display a thing, should we not generalize
> > > this to have an actual display gen in device info? Of course for most
> > > platforms it's going to be identical to the gem gen.
> > > 
> > > The question becomes, is display gen accurate enough? It's not enough to
> > > cover all of Geminilake I believe. Which makes me think, should we just
> > > add tons more device info flags to cover features at a detailed level? I
> > > think that's what Joonas advocates. Perhaps it bloats the device info,
> > > and causes increase in the number of device info blocks. But my gut
> > > feeling says together with truly immutable device info, there are
> > > compiler optimization benefits to be had.
> > > 
> > > Also, currently we "inherit" device info using truly obnoxious macro
> > > layering where you have to work hard to trace the macros to find out
> > > what is set for a given platform. It doesn't have to be that way. We
> > > could move parts of it to separate but shared features structs, and add
> > > pointers to them.
> > > 
> > > Anyway, thanks for rolling this series as a starting point for
> > > discussion. Even if I'm not buying the changes as-is. ;)
> > 
> > Yeah, stuffing this into intel_info imo makes sense. As long as it's
> > booleans they should be fairly cheap.
> > -Daniel
> > > 
> > > 
> > > BR,
> > > Jani.
> > > 
> > > >
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
> > > >  drivers/gpu/drm/i915/intel_cdclk.c   | 2 +-
> > > >  drivers/gpu/drm/i915/intel_color.c   | 2 +-
> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > > >  drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
> > > >  5 files changed, 7 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index d19b38ef145b..6436fedfe561 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2637,6 +2637,8 @@ intel_info(const struct drm_i915_private 
> > > > *dev_priv)
> > > >  #define SUPPORTS_TV(dev_priv)  ((dev_priv)->info.supports_tv)
> > > >  #define I915_HAS_HOTPLUG(dev_priv) ((dev_priv)->info.has_hotplug)
> > > >  
> > > > +#define HAS_DISPLAY_10(dev_priv) (IS_GEN10(dev_priv) || 
> > > > IS_GEMINILAKE(dev_priv))
> > > > +
> > > >  #define HAS_FW_BLC(dev_priv)   (INTEL_GEN(dev_priv) > 2)
> > > >  #define HAS_FBC(dev_priv)  ((dev_priv)->info.has_fbc)
> > > >  #define HAS_CUR_FBC(dev_priv)  (!HAS_GMCH_DISPLAY(dev_priv) && 
> > > > INTEL_GEN(dev_priv) >= 7)
> > > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > index 4aa6500604cc..b315b70fd49c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > @@ -2181,7 +2181,7 @@ int intel_crtc_compute_min_cdclk(const struct 
> > > > intel_crtc_state *crtc_state)
> > > > crtc_state->has_audio &&
> > > > crtc_state->port_clock >= 54 &&
> > > > crtc_state->lane_count == 4) {
> > > > -   if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) 
> > > > {
> > > > +   if (HAS_DISPLAY_10(dev_priv)) {
> > > > /* Display WA #1145: glk,cnl */
> > > > min_cdclk = max(316800, min_cdclk);
> > > > } else if (IS_GEN9(dev_priv) || IS_BROADWELL(dev_priv)) 
> > > > {
> > > > diff --git a/drivers/gpu/drm/i915/intel_color.c 
> > > > 

[Intel-gfx] [PATCH] drm/i915: Simplify has_sagv

[Rodrigo Vivi]

Let's add a platform has_sagv instead of having a full
function that handle platform by platform.

The specially case for SKL for not controlled sagv
is already taken care inside intel_enable_sagv, so there's
no need to duplicate the check here.

v2: Go one step further and remove skl special case. (Jani)

Cc: Jani Nikula 
Cc: Lucas De Marchi 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_pci.c  |  1 +
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 20 +++-
 4 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef037fed..8eab6bdff8a4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2650,6 +2650,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_DDI(dev_priv)   ((dev_priv)->info.has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) ((dev_priv)->info.has_fpga_dbg)
 #define HAS_PSR(dev_priv)   ((dev_priv)->info.has_psr)
+#define HAS_SAGV(dev_priv)  ((dev_priv)->info.has_sagv && \
+ dev_priv->sagv_status != 
I915_SAGV_NOT_CONTROLLED)
 
 #define HAS_RC6(dev_priv)   ((dev_priv)->info.has_rc6)
 #define HAS_RC6p(dev_priv)  ((dev_priv)->info.has_rc6p)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0a05cc7ace14..21ca9917b86e 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -465,6 +465,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_csr = 1, \
.has_guc = 1, \
.has_ipc = 1, \
+   .has_sagv = 1, \
.ddb_size = 896
 
 #define SKL_PLATFORM \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index af7002640cdf..e77c8b62783f 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -117,6 +117,7 @@ enum intel_ppgtt {
func(hws_needs_physical); \
func(overlay_needs_physical); \
func(supports_tv); \
+   func(has_sagv); \
func(has_ipc);
 
 #define GEN_MAX_SLICES (6) /* CNL upper bound */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 67a4d0735291..09c21f6151fd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3609,20 +3609,6 @@ static bool skl_needs_memory_bw_wa(struct 
intel_atomic_state *state)
return false;
 }
 
-static bool
-intel_has_sagv(struct drm_i915_private *dev_priv)
-{
-   if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
-   IS_CANNONLAKE(dev_priv) || IS_ICELAKE(dev_priv))
-   return true;
-
-   if (IS_SKYLAKE(dev_priv) &&
-   dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED)
-   return true;
-
-   return false;
-}
-
 /*
  * SAGV dynamically adjusts the system agent voltage and clock frequencies
  * depending on power and performance requirements. The display engine access
@@ -3639,7 +3625,7 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
 {
int ret;
 
-   if (!intel_has_sagv(dev_priv))
+   if (!HAS_SAGV(dev_priv))
return 0;
 
if (dev_priv->sagv_status == I915_SAGV_ENABLED)
@@ -3676,7 +3662,7 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
 {
int ret;
 
-   if (!intel_has_sagv(dev_priv))
+   if (!HAS_SAGV(dev_priv))
return 0;
 
if (dev_priv->sagv_status == I915_SAGV_DISABLED)
@@ -3721,7 +3707,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
int level, latency;
int sagv_block_time_us;
 
-   if (!intel_has_sagv(dev_priv))
+   if (!HAS_SAGV(dev_priv))
return false;
 
if (IS_GEN9(dev_priv))
-- 
2.19.1

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

Re: [Intel-gfx] [RFC 2/8] drm/i915: Use the ddi_ports info to kill ugly CNL_WITH_PORT_F.

[Rodrigo Vivi]

On Fri, Oct 19, 2018 at 09:46:13AM -0700, Lucas De Marchi wrote:
> On Fri, Oct 19, 2018 at 10:39:46AM +0300, Jani Nikula wrote:
> > On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > > Now that we have the number of ddi ports information available
> > > let's use it instead of that ugly platform macro.
> > >
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 10 ++
> > >  drivers/gpu/drm/i915/i915_drv.h |  2 --
> > >  drivers/gpu/drm/i915/i915_irq.c |  5 ++---
> > >  drivers/gpu/drm/i915/intel_dp.c |  2 +-
> > >  drivers/gpu/drm/i915/intel_hotplug.c|  2 +-
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +-
> > >  6 files changed, 15 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index baac35f698f9..83ab325c6675 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -239,6 +239,14 @@ intel_virt_detect_pch(const struct drm_i915_private 
> > > *dev_priv)
> > >   return id;
> > >  }
> > >  
> > > +static void intel_adjust_skus_differences(struct drm_i915_private 
> > > *dev_priv)
> > > +{
> > > + /* Some Cannonlake SKUs have Port F */
> > > + if (IS_CANNONLAKE(dev_priv) &&
> > > + (INTEL_DEVID(dev_priv) & 0x0004) == 0x0004)
> > > + mkwrite_device_info(dev_priv)->ddi_ports = 6;
> > > +}
> > 
> > I'd like reduce the amount of device info stuff we adjust at probe, not
> > increase.
> > 
> > Long term, I'd like to make dev_priv->info a const pointer to the const
> > data in i915_pci.c, and make it truly immutable. We could have an
> > additional runtime device info to complement that, but this approach
> > calls for a more concrete split in const and non-const data, not "mostly
> > const but sometimes mutable".
> 
> I agree with this. I'd also like to have a const dev_info. What I think we 
> need is to split
> in what is const what can be changed in runtime/initialization.
> 
> However, I'm not fond on using the number of ddi ports to take decisions in 
> the code not
> related to the number of ports, but rather with other things of that sku. See 
> below.
> 
> > 
> > I think I've chatted about this with Chris too.
> > 
> > BR,
> > Jani.
> > 
> > > +
> > >  static void intel_detect_pch(struct drm_i915_private *dev_priv)
> > >  {
> > >   struct pci_dev *pch = NULL;
> > > @@ -904,6 +912,8 @@ static int i915_driver_init_early(struct 
> > > drm_i915_private *dev_priv)
> > >   if (ret < 0)
> > >   goto err_workqueues;
> > >  
> > > + intel_adjust_skus_differences(dev_priv);
> > > +
> > >   /* This must be called before any calls to HAS_PCH_* */
> > >   intel_detect_pch(dev_priv);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 7ad232849268..99e42df79ed8 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2485,8 +2485,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> > >(dev_priv)->info.gt == 2)
> > >  #define IS_CFL_GT3(dev_priv) (IS_COFFEELAKE(dev_priv) && \
> > >(dev_priv)->info.gt == 3)
> > > -#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> > > - (INTEL_DEVID(dev_priv) & 0x0004) == 
> > > 0x0004)
> > >  
> > >  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
> > >  
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 5d1f53723388..63d676de3840 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -2782,8 +2782,7 @@ gen8_de_irq_handler(struct drm_i915_private 
> > > *dev_priv, u32 master_ctl)
> > >   if (INTEL_GEN(dev_priv) >= 11)
> > >   tmp_mask |= ICL_AUX_CHANNEL_E;
> > >  
> > > - if (IS_CNL_WITH_PORT_F(dev_priv) ||
> > > - INTEL_GEN(dev_priv) >= 11)
> > > + if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
> > >   tmp_mask |= CNL_AUX_CHANNEL_F;
> 
> ok, this is directly related to the number of ports
> 
> > >  
> > >   if (iir & tmp_mask) {
> > > @@ -4220,7 +4219,7 @@ static void gen8_de_irq_postinstall(struct 
> > > drm_i915_private *dev_priv)
> > >   if (INTEL_GEN(dev_priv) >= 11)
> > >   de_port_masked |= ICL_AUX_CHANNEL_E;
> > >  
> > > - if (IS_CNL_WITH_PORT_F(dev_priv) || INTEL_GEN(dev_priv) >= 11)
> > > + if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
> > >   de_port_masked |= CNL_AUX_CHANNEL_F;
> > >  
> > >   de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 3384a9bbdafd..0ea0414ccef4 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ 

Re: [Intel-gfx] [v2 6/6] drm/i915/fec: Disable FEC state.

[Ville Syrjälä]

On Mon, Oct 15, 2018 at 02:50:37PM -0700, Anusha Srivatsa wrote:
> Set the suitable bits in DP_TP_CTL to stop
> bit correction when DSC is disabled.
> 
> v2:
> - rebased.
> - Add additional check for compression state. (Gaurav)
> 
> v3: rebased.
> 
> Cc: Gaurav K Singh 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c |  2 ++
>  drivers/gpu/drm/i915/intel_dp.c  | 18 ++
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  3 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 67c013ea4d39..fefa92070b2d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3245,6 +3245,8 @@ static void intel_disable_ddi_dp(struct intel_encoder 
> *encoder,
>   /* Disable the decompression in DP Sink */
>   intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
> ~DP_DECOMPRESSION_EN);
> + /* Disable FEC in DP Sink */
> + intel_dp_disable_fec_state(intel_dp, old_crtc_state);

This looks like the wrong spot as well.

Should be in intel_disable_ddi_buf() if I'm reading the spec correctly.

>  }
>  
>  static void intel_disable_ddi_hdmi(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b9f85502d9ff..1db1a738c85f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3044,6 +3044,24 @@ void intel_dp_enable_fec_state(struct intel_dp 
> *intel_dp,
>   DRM_ERROR("Timed out waiting for FEC Enable Status\n");
>  }
>  
> +void intel_dp_disable_fec_state(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + enum port port = intel_dig_port->base.port;
> + u32 val;
> +
> + if (crtc_state->dsc_params.compression_enable)
> + DRM_DEBUG_KMS("Compression still enabled\n");
> + return;
> +
> + val = I915_READ(DP_TP_CTL(port));
> + val &= ~DP_TP_CTL_FEC_ENABLE;
> + I915_WRITE(DP_TP_CTL(port), val);
> + POSTING_READ(DP_TP_CTL(port));
> +}

Same comments as for the other patch.

> +
>  /* If the sink supports it, try to set the power state appropriately */
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index e51d612a9f42..0c2429f7cc35 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1713,6 +1713,8 @@ void intel_dp_sink_set_fec_ready(struct intel_dp 
> *intel_dp,
>int state);
>  void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
>  const struct intel_crtc_state *crtc_state);
> +void intel_dp_disable_fec_state(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state);
>  void intel_dp_encoder_reset(struct drm_encoder *encoder);
>  void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
>  void intel_dp_encoder_destroy(struct drm_encoder *encoder);
> -- 
> 2.17.1

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

Re: [Intel-gfx] [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.

[Ville Syrjälä]

On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> If FEC is supported, the corresponding
> DP_TP_CTL register bits have to be configured.
> 
> The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
> Also add the warn message to make sure that the control
> register is already active while enabling FEC.
> 
> v2:
> - Change commit message. Configure fec state after
>   link training (Manasi, Gaurav)
> - Remove redundent checks (Manasi)
> - Remove the registers that get added automagically (Anusha)
> 
> v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
> 
> v4: rebased.
> 
> Cc: Gaurav K Singh 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c |  2 ++
>  drivers/gpu/drm/i915/intel_dp.c  | 27 +++
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
>  4 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bcde78bc0027..c8d7fdcd7823 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9093,6 +9093,7 @@ enum skl_power_gate {
>  #define _DP_TP_CTL_B 0x64140
>  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
>  #define  DP_TP_CTL_ENABLE(1 << 31)
> +#define  DP_TP_CTL_FEC_ENABLE(1 << 30)
>  #define  DP_TP_CTL_MODE_SST  (0 << 27)
>  #define  DP_TP_CTL_MODE_MST  (1 << 27)
>  #define  DP_TP_CTL_FORCE_ACT (1 << 25)
> @@ -9111,6 +9112,7 @@ enum skl_power_gate {
>  #define _DP_TP_STATUS_A  0x64044
>  #define _DP_TP_STATUS_B  0x64144
>  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, _DP_TP_STATUS_B)
> +#define  DP_TP_STATUS_FEC_ENABLE_LIVE(1 << 28)
>  #define  DP_TP_STATUS_IDLE_DONE  (1 << 25)
>  #define  DP_TP_STATUS_ACT_SENT   (1 << 24)
>  #define  DP_TP_STATUS_MODE_STATUS_MST(1 << 23)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f531900165bf..67c013ea4d39 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2911,6 +2911,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
> DP_DECOMPRESSION_EN);
>   intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
>   intel_dp_start_link_train(intel_dp);
> + intel_dp_enable_fec_state(intel_dp, crtc_state);

This doesn't look like the correct spot. According to the spec it
should be after stop_link_train() (where we set DP_TP_CTL to
to normal).

> +
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b4e8af3142a2..b9f85502d9ff 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3017,6 +3017,33 @@ void intel_dp_sink_set_fec_ready(struct intel_dp 
> *intel_dp,
>   DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
>  }
>  
> +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
> +const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + enum port port = intel_dig_port->base.port;
> + u32 val;
> +
> + /* FEC support exists for DP 1.4 only */
> + if (intel_dp_is_edp(intel_dp))
> + return;
> +
> + /* If Display Compression is not enabled, FEC need not be configured */
> + if (!crtc_state->dsc_params.compression_enable)
> + return;
> +
> + val = I915_READ(DP_TP_CTL(port));
> + val |= DP_TP_CTL_FEC_ENABLE;
> + I915_WRITE(DP_TP_CTL(port), val);
> +
> + if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
> + DP_TP_STATUS_FEC_ENABLE_LIVE,
> + DP_TP_STATUS_FEC_ENABLE_LIVE,
> + 1))
> + DRM_ERROR("Timed out waiting for FEC Enable Status\n");
> +}

There is no reason to stick these into intel_dp.c when the
only caller is in intel_ddi.c.

We also seem to be missing platform checks. FEC doesn't appear to
be a thing prior to ICL. I guess the edp+compression_enable takes care
of this, but I think I'd rather stick a new fec_enable bool into
the crtc state. That way we get can add it to the state checker as well.

> +
>  /* If the sink supports it, try to set the power state appropriately */
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>  {
> diff 

Re: [Intel-gfx] [RFC 4/8] drm/i915: Group gen 10 display.

[Rodrigo Vivi]

On Fri, Oct 19, 2018 at 01:33:08PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 19, 2018 at 10:30:46AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > > On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > > > Continuing with the goal of use less platform codenames:
> > > > let's group platforms who has gen10 display.
> > > 
> > > Ahah, so this answers my question in the previous patch. ;)
> > > 
> > > So we already have HAS_GMCH_DISPLAY().
> > 
> > We also have HAS_DDI, which I guess you could call gen8 display :-)
> 
> There's also these interesting gen designations in some old docs:
> ctg/elk = gen5.5
> ilk = gen5.75
> I guess we could more or less call all of that as gen5 display.
> 
> And of course we have the other oddballs like vlv/chv which are
> sort of mismash of i965, ctg/elk, ibx, and custom stuff. Also
> pnv is mostly gen3 display except for a few bits that were
> snatched from i965.
> 
> Not sure we have enough numbers for all that without resotring to
> fractions. And no one could anyway remember what all the different
> numbers mean.

Thanks for all the comments. Yeap, the idea is not to use this series
as is but just start the discussion and evolve it.

Gen number by itself doesn't fit to display indeed, but neither
display-gen-number because we have the fraction and cases like glk
that is gen10-stripped-display+bxt :/

Also platform names are not enough by itself, like cannnonlake-with-port-f
because the sku lacks on having a different name. If you take a look to our
internal branch the same is about to happen with icl soon

So my idea was that we first use feature {name, or number of something}
whenever possible. On the secondary case we use groups of things like
HAS_GMCH_DISPLAY, HAS_GEN10_DISPLAY, HAS_VLV_DISPLAY. And on last case
we use gen numbers.

My idea of preferring gen over platform names in general was that for
platform name we cannot use >= ICELAKE... :/

Well, maybe having at least the basic display number to use in cases
like this would solve this case, but I'm afraid it can get tricky
in some common areas and the use of IS_GENx or IS_DISPLAY_x could become
blur and mixed up.

I will play more with this series, removing the controversial parts
and see what I can do with boolean "has_"

but for now still using gen >= 11 instead of icelake while we don't
have a better suggestion that covers that...

Thanks,
Rodrigo.

> 
> > 
> > > If we're going to make gen10 display a thing, should we not generalize
> > > this to have an actual display gen in device info? Of course for most
> > > platforms it's going to be identical to the gem gen.
> > > 
> > > The question becomes, is display gen accurate enough? It's not enough to
> > > cover all of Geminilake I believe. Which makes me think, should we just
> > > add tons more device info flags to cover features at a detailed level? I
> > > think that's what Joonas advocates. Perhaps it bloats the device info,
> > > and causes increase in the number of device info blocks. But my gut
> > > feeling says together with truly immutable device info, there are
> > > compiler optimization benefits to be had.
> > > 
> > > Also, currently we "inherit" device info using truly obnoxious macro
> > > layering where you have to work hard to trace the macros to find out
> > > what is set for a given platform. It doesn't have to be that way. We
> > > could move parts of it to separate but shared features structs, and add
> > > pointers to them.
> > > 
> > > Anyway, thanks for rolling this series as a starting point for
> > > discussion. Even if I'm not buying the changes as-is. ;)
> > 
> > Yeah, stuffing this into intel_info imo makes sense. As long as it's
> > booleans they should be fairly cheap.
> > -Daniel
> > > 
> > > 
> > > BR,
> > > Jani.
> > > 
> > > >
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
> > > >  drivers/gpu/drm/i915/intel_cdclk.c   | 2 +-
> > > >  drivers/gpu/drm/i915/intel_color.c   | 2 +-
> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > > >  drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
> > > >  5 files changed, 7 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index d19b38ef145b..6436fedfe561 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2637,6 +2637,8 @@ intel_info(const struct drm_i915_private 
> > > > *dev_priv)
> > > >  #define SUPPORTS_TV(dev_priv)  ((dev_priv)->info.supports_tv)
> > > >  #define I915_HAS_HOTPLUG(dev_priv) ((dev_priv)->info.has_hotplug)
> > > >  
> > > > +#define HAS_DISPLAY_10(dev_priv) (IS_GEN10(dev_priv) || 
> > > > IS_GEMINILAKE(dev_priv))
> > > > +
> > > >  #define HAS_FW_BLC(dev_priv)   (INTEL_GEN(dev_priv) > 2)
> > > >  #define HAS_FBC(dev_priv)  ((dev_priv)->info.has_fbc)
> > > >  #define HAS_CUR_FBC(dev_priv)  

Re: [Intel-gfx] [RFC 4/8] drm/i915: Group gen 10 display.

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 09:41:37AM -0700, Rodrigo Vivi wrote:
> On Fri, Oct 19, 2018 at 01:33:08PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 19, 2018 at 10:30:46AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > > > On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > > > > Continuing with the goal of use less platform codenames:
> > > > > let's group platforms who has gen10 display.
> > > > 
> > > > Ahah, so this answers my question in the previous patch. ;)
> > > > 
> > > > So we already have HAS_GMCH_DISPLAY().
> > > 
> > > We also have HAS_DDI, which I guess you could call gen8 display :-)
> > 
> > There's also these interesting gen designations in some old docs:
> > ctg/elk = gen5.5
> > ilk = gen5.75
> > I guess we could more or less call all of that as gen5 display.
> > 
> > And of course we have the other oddballs like vlv/chv which are
> > sort of mismash of i965, ctg/elk, ibx, and custom stuff. Also
> > pnv is mostly gen3 display except for a few bits that were
> > snatched from i965.
> > 
> > Not sure we have enough numbers for all that without resotring to
> > fractions. And no one could anyway remember what all the different
> > numbers mean.
> 
> Thanks for all the comments. Yeap, the idea is not to use this series
> as is but just start the discussion and evolve it.
> 
> Gen number by itself doesn't fit to display indeed, but neither
> display-gen-number because we have the fraction and cases like glk
> that is gen10-stripped-display+bxt :/
> 
> Also platform names are not enough by itself, like cannnonlake-with-port-f
> because the sku lacks on having a different name. If you take a look to our
> internal branch the same is about to happen with icl soon
> 
> So my idea was that we first use feature {name, or number of something}
> whenever possible. On the secondary case we use groups of things like
> HAS_GMCH_DISPLAY, HAS_GEN10_DISPLAY, HAS_VLV_DISPLAY. And on last case
> we use gen numbers.
> 
> My idea of preferring gen over platform names in general was that for
> platform name we cannot use >= ICELAKE... :/

Well... we could. Assuming we order the enum suitably. Problem
is that there may not be a single order that works for all cases.
But it might be good enough for a lot of the cases.

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

Re: [Intel-gfx] [v2 6/6] drm/i915/fec: Disable FEC state.

[Srivatsa, Anusha]

>-Original Message-
>From: Navare, Manasi D
>Sent: Thursday, October 18, 2018 4:16 PM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org; Singh, Gaurav K 
>;
>Jani Nikula ; Ville Syrjala
>
>Subject: Re: [v2 6/6] drm/i915/fec: Disable FEC state.
>
>Hi Anusha,
>
>Find my comments below:
>
>On Mon, Oct 15, 2018 at 02:50:37PM -0700, Anusha Srivatsa wrote:
>> Set the suitable bits in DP_TP_CTL to stop bit correction when DSC is
>> disabled.
>>
>
>> - rebased.
>> - Add additional check for compression state. (Gaurav)
>>
>> v3: rebased.
>>
>> Cc: Gaurav K Singh 
>> Cc: Jani Nikula 
>> Cc: Ville Syrjala 
>> Cc: Manasi Navare 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c |  2 ++
>> drivers/gpu/drm/i915/intel_dp.c  | 18 ++
>> drivers/gpu/drm/i915/intel_drv.h |  2 ++
>>  3 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 67c013ea4d39..fefa92070b2d 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3245,6 +3245,8 @@ static void intel_disable_ddi_dp(struct intel_encoder
>*encoder,
>>  /* Disable the decompression in DP Sink */
>>  intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
>>~DP_DECOMPRESSION_EN);
>> +/* Disable FEC in DP Sink */
>> +intel_dp_disable_fec_state(intel_dp, old_crtc_state);
>>  }
>>
>>  static void intel_disable_ddi_hdmi(struct intel_encoder *encoder,
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c index b9f85502d9ff..1db1a738c85f
>> 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -3044,6 +3044,24 @@ void intel_dp_enable_fec_state(struct intel_dp
>*intel_dp,
>>  DRM_ERROR("Timed out waiting for FEC Enable Status\n");  }
>>
>> +void intel_dp_disable_fec_state(struct intel_dp *intel_dp,
>> +const struct intel_crtc_state *crtc_state) {
>> +struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> +struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>> +enum port port = intel_dig_port->base.port;
>> +u32 val;
>> +
>> +if (crtc_state->dsc_params.compression_enable)
>> +DRM_DEBUG_KMS("Compression still enabled\n");
>
>This check is wrong. The crtc_state->dsc_params.compression_enable only
>indicates that compression enable is allowed in atomic check. This does not
>indicate whether it is enabled or disabled in source/sink
>
>Infact this function shd return if !crtc_state->dsc_params.compression_enable,
>see what intel_dp_sink_set_decompression_state does.
>
>After that to make sure DSC is disabled, you can read DP_DSC_ENABLE DPCD
>register and check DP_DECOMPRESSION_EN bit before proceeding to disabling
>FEC.

That is a good point. I will make the changes. 
Thanks For the review.

Anusha 
>Manasi
>
>> +return;
>> +
>> +val = I915_READ(DP_TP_CTL(port));
>> +val &= ~DP_TP_CTL_FEC_ENABLE;
>> +I915_WRITE(DP_TP_CTL(port), val);
>> +POSTING_READ(DP_TP_CTL(port));
>> +}
>> +
>>  /* If the sink supports it, try to set the power state appropriately
>> */  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)  {
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index e51d612a9f42..0c2429f7cc35 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1713,6 +1713,8 @@ void intel_dp_sink_set_fec_ready(struct intel_dp
>*intel_dp,
>>   int state);
>>  void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
>> const struct intel_crtc_state *crtc_state);
>> +void intel_dp_disable_fec_state(struct intel_dp *intel_dp,
>> +const struct intel_crtc_state *crtc_state);
>>  void intel_dp_encoder_reset(struct drm_encoder *encoder);  void
>> intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);  void
>> intel_dp_encoder_destroy(struct drm_encoder *encoder);
>> --
>> 2.17.1
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] drm/i915/icl: Define MOCS table for Icelake

[Lionel Landwerlin]

On 19/10/2018 17:19, Daniele Ceraolo Spurio wrote:
CC some mesa people here? not sure who the right contact would be for 
this 

Adding Anuj.

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

Re: [Intel-gfx] [RFC 4/8] drm/i915: Group gen 10 display.

[Lucas De Marchi]

On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi  wrote:
> > Continuing with the goal of use less platform codenames:
> > let's group platforms who has gen10 display.
> 
> Ahah, so this answers my question in the previous patch. ;)
> 
> So we already have HAS_GMCH_DISPLAY().
> 
> If we're going to make gen10 display a thing, should we not generalize
> this to have an actual display gen in device info? Of course for most
> platforms it's going to be identical to the gem gen.

I think we should have indeed a display_gen in device info. It's a way to group 
features
that are particular to that gen. Just like we do for gem.  When the spec is 
clear about
this being something from that gen, I think it's fine.

We will need more fine grained flags in the device info, but IMO that should be 
in addition
to this display gen number.

Lucas De Marchi

> 
> The question becomes, is display gen accurate enough? It's not enough to
> cover all of Geminilake I believe. Which makes me think, should we just
> add tons more device info flags to cover features at a detailed level? I
> think that's what Joonas advocates. Perhaps it bloats the device info,
> and causes increase in the number of device info blocks. But my gut
> feeling says together with truly immutable device info, there are
> compiler optimization benefits to be had.
> 
> Also, currently we "inherit" device info using truly obnoxious macro
> layering where you have to work hard to trace the macros to find out
> what is set for a given platform. It doesn't have to be that way. We
> could move parts of it to separate but shared features structs, and add
> pointers to them.
> 
> Anyway, thanks for rolling this series as a starting point for
> discussion. Even if I'm not buying the changes as-is. ;)
> 
> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
> >  drivers/gpu/drm/i915/intel_cdclk.c   | 2 +-
> >  drivers/gpu/drm/i915/intel_color.c   | 2 +-
> >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> >  drivers/gpu/drm/i915/intel_sprite.c  | 2 +-
> >  5 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index d19b38ef145b..6436fedfe561 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2637,6 +2637,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  #define SUPPORTS_TV(dev_priv)  ((dev_priv)->info.supports_tv)
> >  #define I915_HAS_HOTPLUG(dev_priv) ((dev_priv)->info.has_hotplug)
> >  
> > +#define HAS_DISPLAY_10(dev_priv) (IS_GEN10(dev_priv) || 
> > IS_GEMINILAKE(dev_priv))
> > +
> >  #define HAS_FW_BLC(dev_priv)   (INTEL_GEN(dev_priv) > 2)
> >  #define HAS_FBC(dev_priv)  ((dev_priv)->info.has_fbc)
> >  #define HAS_CUR_FBC(dev_priv)  (!HAS_GMCH_DISPLAY(dev_priv) && 
> > INTEL_GEN(dev_priv) >= 7)
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 4aa6500604cc..b315b70fd49c 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -2181,7 +2181,7 @@ int intel_crtc_compute_min_cdclk(const struct 
> > intel_crtc_state *crtc_state)
> > crtc_state->has_audio &&
> > crtc_state->port_clock >= 54 &&
> > crtc_state->lane_count == 4) {
> > -   if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
> > +   if (HAS_DISPLAY_10(dev_priv)) {
> > /* Display WA #1145: glk,cnl */
> > min_cdclk = max(316800, min_cdclk);
> > } else if (IS_GEN9(dev_priv) || IS_BROADWELL(dev_priv)) {
> > diff --git a/drivers/gpu/drm/i915/intel_color.c 
> > b/drivers/gpu/drm/i915/intel_color.c
> > index 5127da286a2b..d5f67b9c9698 100644
> > --- a/drivers/gpu/drm/i915/intel_color.c
> > +++ b/drivers/gpu/drm/i915/intel_color.c
> > @@ -659,7 +659,7 @@ void intel_color_init(struct drm_crtc *crtc)
> >IS_BROXTON(dev_priv)) {
> > dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
> > dev_priv->display.load_luts = broadwell_load_luts;
> > -   } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> > +   } else if (HAS_DISPLAY_10(dev_priv)) {
> > dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
> > dev_priv->display.load_luts = glk_load_luts;
> > } else {
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7b04b8436b6d..1abf79a4ee91 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5730,7 +5730,7 @@ static void haswell_crtc_enable(struct 
> > intel_crtc_state *pipe_config,
> > intel_crtc->active = true;
> >  
> > /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
> > -   psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || 

Re: [Intel-gfx] [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.

[Manasi Navare]

On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> > If FEC is supported, the corresponding
> > DP_TP_CTL register bits have to be configured.
> > 
> > The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> > and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
> > Also add the warn message to make sure that the control
> > register is already active while enabling FEC.
> > 
> > v2:
> > - Change commit message. Configure fec state after
> >   link training (Manasi, Gaurav)
> > - Remove redundent checks (Manasi)
> > - Remove the registers that get added automagically (Anusha)
> > 
> > v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
> > 
> > v4: rebased.
> > 
> > Cc: Gaurav K Singh 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Cc: Manasi Navare 
> > Signed-off-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
> >  drivers/gpu/drm/i915/intel_ddi.c |  2 ++
> >  drivers/gpu/drm/i915/intel_dp.c  | 27 +++
> >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> >  4 files changed, 33 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index bcde78bc0027..c8d7fdcd7823 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9093,6 +9093,7 @@ enum skl_power_gate {
> >  #define _DP_TP_CTL_B   0x64140
> >  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
> >  #define  DP_TP_CTL_ENABLE  (1 << 31)
> > +#define  DP_TP_CTL_FEC_ENABLE  (1 << 30)
> >  #define  DP_TP_CTL_MODE_SST(0 << 27)
> >  #define  DP_TP_CTL_MODE_MST(1 << 27)
> >  #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
> > @@ -9111,6 +9112,7 @@ enum skl_power_gate {
> >  #define _DP_TP_STATUS_A0x64044
> >  #define _DP_TP_STATUS_B0x64144
> >  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, 
> > _DP_TP_STATUS_B)
> > +#define  DP_TP_STATUS_FEC_ENABLE_LIVE  (1 << 28)
> >  #define  DP_TP_STATUS_IDLE_DONE(1 << 25)
> >  #define  DP_TP_STATUS_ACT_SENT (1 << 24)
> >  #define  DP_TP_STATUS_MODE_STATUS_MST  (1 << 23)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index f531900165bf..67c013ea4d39 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2911,6 +2911,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> >   DP_DECOMPRESSION_EN);
> > intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
> > intel_dp_start_link_train(intel_dp);
> > +   intel_dp_enable_fec_state(intel_dp, crtc_state);
> 
> This doesn't look like the correct spot. According to the spec it
> should be after stop_link_train() (where we set DP_TP_CTL to
> to normal).
>

Yes I see in the display port enabling sequence page of the spec, that it says 
enable FEC
after DP_TP_CTL is set to Normal. Also the FEC page says that this should be 
enabled only after ensuring that link training
completed. So according to that this call should happen after
intel_dp_stop_link_train(). 
So yes move this to after intel_dp_stop_link_training().

> > +
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b4e8af3142a2..b9f85502d9ff 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3017,6 +3017,33 @@ void intel_dp_sink_set_fec_ready(struct intel_dp 
> > *intel_dp,
> > DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
> >  }
> >  
> > +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
> > +  const struct intel_crtc_state *crtc_state)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   enum port port = intel_dig_port->base.port;
> > +   u32 val;
> > +
> > +   /* FEC support exists for DP 1.4 only */
> > +   if (intel_dp_is_edp(intel_dp))
> > +   return;
> > +
> > +   /* If Display Compression is not enabled, FEC need not be configured */
> > +   if (!crtc_state->dsc_params.compression_enable)
> > +   return;
> > +
> > +   val = I915_READ(DP_TP_CTL(port));
> > +   val |= DP_TP_CTL_FEC_ENABLE;
> > +   I915_WRITE(DP_TP_CTL(port), val);
> > +
> > +   if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
> > +   DP_TP_STATUS_FEC_ENABLE_LIVE,
> > +   DP_TP_STATUS_FEC_ENABLE_LIVE,
> > +  

Re: [Intel-gfx] [PATCH xf86-video-intel] sna: Switch back to hwcursor on the next cursor update

[Chris Wilson]

Quoting Ville Syrjala (2018-10-19 17:55:02)
> From: Ville Syrjälä 
> 
> Once we've switched to using the swcursor (possibly
> due to the cursor ioctl failing) we currently keep
> using the swcursor until the modeset.
> 
> That's not particularly great as the swcursor has several
> issues. Apart from the (presumably expected) flicker,
> the cursor also tends to leave horrible trails behind
> around dri2/3 windows (happens with tearfree at least).
> 
> To avoid some of that let's try to switch back to the hwcursor
> a bit sooner. We can do that neatly via the convenient swcursor
> block handler.

Ok, so that forces the sw cursor to be switched off on the very next
xf86CursorSetCursor() after being enabled. If the HWCursor fails, the
cursor should be invisible until the next block handler. Won't that
cause the cursor to flicker even more? Hmm, except that the swcursor
should be restored within a frame. So more or less simply doubling the
work of using swcursor? (Probably not actually, since swcursor is
effectively an undo and paint every time and now we just make those two
distinct steps) Certainly achieves the goal of forcing HW cursor back on
at the earliest opportunity.

I think I have just argued that this doesn't actually impact on swcursor
rendering, just extends the loop.

> References: https://bugs.freedesktop.org/show_bug.cgi?id=106935
> Signed-off-by: Ville Syrjälä 

Tentative
Reviewed-by: Chris Wilson 
I think I would like to review the impact on swcursor a bit more,
FAIL_CURSOR_IOCTL be my friend.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/psr: Move intel_psr_disable_source() code to intel_psr_disable_locked()

[Dhinakaran Pandiyan]

On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> In the past we had hooks to configure HW for VLV/CHV too, in the drop
> of VLV/CHV support the intel_psr_disable_source() code was not moved
> to the caller, so doing it here.
> 
> Suggested-by: Dhinakaran Pandiyan 

Reviewed-by: Dhinakaran Pandiyan 

Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 25 +
>  1 file changed, 9 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 16d0e3df7de0..70d4e26e17b5 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -680,13 +680,20 @@ static void intel_psr_exit(struct
> drm_i915_private *dev_priv)
>   dev_priv->psr.active = false;
>  }
>  
> -static void
> -intel_psr_disable_source(struct intel_dp *intel_dp)
> +static void intel_psr_disable_locked(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   i915_reg_t psr_status;
>   u32 psr_status_mask;
>  
> + lockdep_assert_held(_priv->psr.lock);
> +
> + if (!dev_priv->psr.enabled)
> + return;
> +
> + DRM_DEBUG_KMS("Disabling PSR%s\n",
> +   dev_priv->psr.psr2_enabled ? "2" : "1");
> +
>   intel_psr_exit(dev_priv);

The above lockdep_assert_held(_priv->psr.lock) made me think we
need one in inside psr_exit() too. Not in this though, could perhaps be
added in patch 1.


>  
>   if (dev_priv->psr.psr2_enabled) {
> @@ -701,20 +708,6 @@ intel_psr_disable_source(struct intel_dp
> *intel_dp)
>   if (intel_wait_for_register(dev_priv, psr_status,
> psr_status_mask, 0,
>   2000))
>   DRM_ERROR("Timed out waiting for PSR Idle State\n");
> -}
> -
> -static void intel_psr_disable_locked(struct intel_dp *intel_dp)
> -{
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> -
> - lockdep_assert_held(_priv->psr.lock);
> -
> - if (!dev_priv->psr.enabled)
> - return;
> -
> - DRM_DEBUG_KMS("Disabling PSR%s\n",
> -   dev_priv->psr.psr2_enabled ? "2" : "1");
> - intel_psr_disable_source(intel_dp);
>  
>   /* Disable PSR on Sink */
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);

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

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Check PSR errors instead of retrain while PSR is enabled

[Dhinakaran Pandiyan]

On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> When a PSR error happens sink also update the link status values
> while source do not retrain link as required in the PSR exit
> sequence.
> So in the short pulse handling it was returning earlier and doing a
> full detection and attempting to retrain but it fails because for
> most sinks the main link is disabled while PSR is active, before even
> check PSR errors.
> 
> Just call intel_psr_short_pulse() before
> intel_dp_needs_link_retrain() is also not the right fix as
> intel_dp_needs_link_retrain() would return true and trigger a full
> detection and trying to retrain link while PSR HW is also doing that.
> 
> Check for PSR active is also not safe as it could be inactive due a
> frontbuffer invalidate and still doing the PSR exit sequence.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  |  7 +++
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 15 +++
>  3 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 1826d491efd7..2a21a9e29eb2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4396,6 +4396,13 @@ intel_dp_needs_link_retrain(struct intel_dp
> *intel_dp)
>   if (!intel_dp->link_trained)
>   return false;
>  
> + /*
> +  * While PSR is enabled, HW will control main-link and retrain
> when
> +  * exiting PSR
> +  */
> + if (intel_psr_enabled(intel_dp))

You need a check for !link_standby. The link status is expected to be
good if we are not turning the link fully off.

-DK

> + return false;
> +
>   if (!intel_dp_get_link_status(intel_dp, link_status))
>   return false;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3dea7a1bda7f..147a116cfc71 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1958,6 +1958,7 @@ void intel_psr_irq_handler(struct
> drm_i915_private *dev_priv, u32 psr_iir);
>  void intel_psr_short_pulse(struct intel_dp *intel_dp);
>  int intel_psr_wait_for_idle(const struct intel_crtc_state
> *new_crtc_state,
>   u32 *out_value);
> +bool intel_psr_enabled(struct intel_dp *intel_dp);
>  
>  /* intel_runtime_pm.c */
>  int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index ad09130cb4ad..e4429f2f3034 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1138,3 +1138,18 @@ void intel_psr_short_pulse(struct intel_dp
> *intel_dp)
>  exit:
>   mutex_unlock(>lock);
>  }
> +
> +bool intel_psr_enabled(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + bool ret;
> +
> + if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
> + return false;
> +
> + mutex_lock(_priv->psr.lock);
> + ret = (dev_priv->psr.dp == intel_dp && dev_priv->psr.enabled);
> + mutex_unlock(_priv->psr.lock);
> +
> + return ret;
> +}

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Fix the macros for DFLEXDPMLE register bits

[Srivatsa, Anusha]

From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of Manasi 
Navare [manasi.d.nav...@intel.com]
Sent: Thursday, October 18, 2018 3:16 PM
To: intel-gfx@lists.freedesktop.org
Cc: Zanoni, Paulo R
Subject: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Fix the macros for DFLEXDPMLE 
register bits

This patch fixes the macros used for defining the DFLEXDPMLE
register bit fields. This accounts for changes in the spec.

Fixes: a2bc69a1a9d6 ("drm/i915/icl: Add register definition for DFLEXDPMLE")
Cc: Animesh Manna 
Cc: Paulo Zanoni 
Cc: Jose Roberto de Souza 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/i915_reg.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81f1c601987d..f5f8a39c4116 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2057,8 +2057,12 @@ enum i915_power_well_id {

 /* ICL PHY DFLEX registers */
 #define PORT_TX_DFLEXDPMLE1_MMIO(0x1638C0)
-#define   DFLEXDPMLE1_DPMLETC_MASK(n)  (0xf << (4 * (n)))
-#define   DFLEXDPMLE1_DPMLETC(n, x)((x) << (4 * (n)))
+#define   DFLEXDPMLE1_DPMLETC_MASK(tc_port)(0xf << (4 * (tc_port)))
+#define   DFLEXDPMLE1_DPMLETC_ML0(tc_port) (1 << (4 * (tc_port)))
+#define   DFLEXDPMLE1_DPMLETC_ML1_0(tc_port)   (3 << (4 * (tc_port)))
+#define   DFLEXDPMLE1_DPMLETC_ML3(tc_port) (8 << (4 * (tc_port)))
+#define   DFLEXDPMLE1_DPMLETC_ML3_2(tc_port)   (12 << (4 * (tc_port))

Wont ML0, 1_0, 3, 3_2 suffice?

Anusha 
+#define   DFLEXDPMLE1_DPMLETC_ML_3_0(tc_port)  (15 << (4 * (tc_port)))

 /* BXT PHY Ref registers */
 #define _PORT_REF_DW3_A0x16218C
--
2.18.0

___
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] [PATCH 0/5] Sorting "if" blocks and statements from newer to older platform

[Rodrigo Vivi]

This general approach has been acked by Jani on an RFC patch
that I sent yesterday.

But when rebasing it on drm-tip I noticed that it would be better
for review if I split this in very small chunks.

As I wrote yesterday I consider and tried to start using coccinelle
here but in the end, at least for me, it was easier and simpler
to do the manual change directly.

Thanks,
Rodrigo.

Cc: Jani Nikula 

Rodrigo Vivi (5):
  drm/i915: ddi_clock_get sort platforms newer-to-older.
  drm/i915: compute_min_voltage_level sort platforms newer-to-older
  drm/i915: digital_port_connected sort platforms newer-to-older
  drm/i915: power_domains_init sort platforms newer-to-older
  drm/i915: uncore_fw_domains_init sort platforms newer-to-older

 drivers/gpu/drm/i915/intel_ddi.c| 18 -
 drivers/gpu/drm/i915/intel_dp.c | 27 ++---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 17 
 drivers/gpu/drm/i915/intel_uncore.c |  2 +-
 4 files changed, 33 insertions(+), 31 deletions(-)

-- 
2.19.1

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

[Intel-gfx] [PATCH 2/5] drm/i915: compute_min_voltage_level sort platforms newer-to-older

[Rodrigo Vivi]

No functional change.

Just sorting this "if" block from newer to older platform.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 5e8173f28eaa..c49270a266d6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3373,10 +3373,10 @@ static bool intel_ddi_is_audio_enabled(struct 
drm_i915_private *dev_priv,
 void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
 struct intel_crtc_state *crtc_state)
 {
-   if (IS_CANNONLAKE(dev_priv) && crtc_state->port_clock > 594000)
-   crtc_state->min_voltage_level = 2;
-   else if (IS_ICELAKE(dev_priv) && crtc_state->port_clock > 594000)
+   if (IS_ICELAKE(dev_priv) && crtc_state->port_clock > 594000)
crtc_state->min_voltage_level = 1;
+   else if (IS_CANNONLAKE(dev_priv) && crtc_state->port_clock > 594000)
+   crtc_state->min_voltage_level = 2;
 }
 
 void intel_ddi_get_config(struct intel_encoder *encoder,
-- 
2.19.1

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

[Intel-gfx] [PATCH 1/5] drm/i915: ddi_clock_get sort platforms newer-to-older.

[Rodrigo Vivi]

No functional change.

Just sorting this "if" block from newer to older platform.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6b9742baa5f2..5e8173f28eaa 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1737,16 +1737,16 @@ static void intel_ddi_clock_get(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
 
-   if (INTEL_GEN(dev_priv) <= 8)
-   hsw_ddi_clock_get(encoder, pipe_config);
+   if (IS_ICELAKE(dev_priv))
+   icl_ddi_clock_get(encoder, pipe_config);
+   else if (IS_CANNONLAKE(dev_priv))
+   cnl_ddi_clock_get(encoder, pipe_config);
else if (IS_GEN9_BC(dev_priv))
skl_ddi_clock_get(encoder, pipe_config);
else if (IS_GEN9_LP(dev_priv))
bxt_ddi_clock_get(encoder, pipe_config);
-   else if (IS_CANNONLAKE(dev_priv))
-   cnl_ddi_clock_get(encoder, pipe_config);
-   else if (IS_ICELAKE(dev_priv))
-   icl_ddi_clock_get(encoder, pipe_config);
+   else if (INTEL_GEN(dev_priv) <= 8)
+   hsw_ddi_clock_get(encoder, pipe_config);
 }
 
 void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
-- 
2.19.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Consolidate cdclk hooks.

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 12:11:53PM -0700, Rodrigo Vivi wrote:
> We don't need 2 different blocks.
> Specially with on in ordered older-to-newer and the other
> one newer-to-older.
> 
> Let's start always using newer-to-older order
> when it makes sense.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 91 ++
>  1 file changed, 42 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 29075c763428..76e69c4f154f 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -2777,80 +2777,73 @@ void intel_update_rawclk(struct drm_i915_private 
> *dev_priv)
>   */
>  void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
>  {
> - if (IS_CHERRYVIEW(dev_priv)) {
> - dev_priv->display.set_cdclk = chv_set_cdclk;
> - dev_priv->display.modeset_calc_cdclk =
> - vlv_modeset_calc_cdclk;
> - } else if (IS_VALLEYVIEW(dev_priv)) {
> - dev_priv->display.set_cdclk = vlv_set_cdclk;
> - dev_priv->display.modeset_calc_cdclk =
> - vlv_modeset_calc_cdclk;
> - } else if (IS_BROADWELL(dev_priv)) {
> - dev_priv->display.set_cdclk = bdw_set_cdclk;
> - dev_priv->display.modeset_calc_cdclk =
> - bdw_modeset_calc_cdclk;
> - } else if (IS_GEN9_LP(dev_priv)) {
> - dev_priv->display.set_cdclk = bxt_set_cdclk;
> - dev_priv->display.modeset_calc_cdclk =
> - bxt_modeset_calc_cdclk;
> - } else if (IS_GEN9_BC(dev_priv)) {
> - dev_priv->display.set_cdclk = skl_set_cdclk;
> - dev_priv->display.modeset_calc_cdclk =
> - skl_modeset_calc_cdclk;
> + if (IS_ICELAKE(dev_priv)) {
> + dev_priv->display.set_cdclk = icl_set_cdclk;
> + dev_priv->display.modeset_calc_cdclk = icl_modeset_calc_cdclk;
> + dev_priv->display.get_cdclk = icl_get_cdclk;
>   } else if (IS_CANNONLAKE(dev_priv)) {
>   dev_priv->display.set_cdclk = cnl_set_cdclk;
>   dev_priv->display.modeset_calc_cdclk =
>   cnl_modeset_calc_cdclk;

Can you eliminate these extra '\n' in these assigments while you're
here? I think they should all fit within the 80 col rule now.

Also another ocd you could do is order the assignments in a better
looking way. I'd suggest either get,set,calc or calc,set,get.

> - } else if (IS_ICELAKE(dev_priv)) {
> - dev_priv->display.set_cdclk = icl_set_cdclk;
> - dev_priv->display.modeset_calc_cdclk = icl_modeset_calc_cdclk;
> - }
> -
> - if (IS_ICELAKE(dev_priv))
> - dev_priv->display.get_cdclk = icl_get_cdclk;
> - else if (IS_CANNONLAKE(dev_priv))
>   dev_priv->display.get_cdclk = cnl_get_cdclk;
> - else if (IS_GEN9_BC(dev_priv))
> + } else if (IS_GEN9_BC(dev_priv)) {
> + dev_priv->display.set_cdclk = skl_set_cdclk;
> + dev_priv->display.modeset_calc_cdclk =
> + skl_modeset_calc_cdclk;
>   dev_priv->display.get_cdclk = skl_get_cdclk;
> - else if (IS_GEN9_LP(dev_priv))
> + } else if (IS_GEN9_LP(dev_priv)) {
> + dev_priv->display.set_cdclk = bxt_set_cdclk;
> + dev_priv->display.modeset_calc_cdclk =
> + bxt_modeset_calc_cdclk;
>   dev_priv->display.get_cdclk = bxt_get_cdclk;

bxt before skl if we want to be chronologically pedantic?

> - else if (IS_BROADWELL(dev_priv))
> + } else if (IS_BROADWELL(dev_priv)) {
> + dev_priv->display.set_cdclk = bdw_set_cdclk;
> + dev_priv->display.modeset_calc_cdclk =
> + bdw_modeset_calc_cdclk;
>   dev_priv->display.get_cdclk = bdw_get_cdclk;
> - else if (IS_HASWELL(dev_priv))
> + } else if (IS_HASWELL(dev_priv)) {
>   dev_priv->display.get_cdclk = hsw_get_cdclk;

hsw will look a bit lonely in the middle here, but I suppose that's
not sufficient reason to upstream my hsw_set_cdclk :P

> - else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + } else if (IS_CHERRYVIEW(dev_priv)) {
> + dev_priv->display.set_cdclk = chv_set_cdclk;
> + dev_priv->display.modeset_calc_cdclk =
> + vlv_modeset_calc_cdclk;
>   dev_priv->display.get_cdclk = vlv_get_cdclk;

chv before bdw?

Patch is 
Reviewed-by: Ville Syrjälä 

Feel free to ignore any of my bikesheds you don't agree with.

> - else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
> + } else if (IS_VALLEYVIEW(dev_priv)) {
> + dev_priv->display.set_cdclk = vlv_set_cdclk;
> + dev_priv->display.modeset_calc_cdclk =
> + vlv_modeset_calc_cdclk;
> + dev_priv->display.get_cdclk 

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove the hardware readout path for DSI panel orientation

[Chris Wilson]

Quoting Chris Wilson (2018-10-19 21:11:11)
> Quoting Ville Syrjala (2018-10-19 20:59:48)
> > From: Ville Syrjälä 
> > 
> > Now that we can actually grab the rotation data from the VBT,
> > maybe we can get rid of the hardware readout path? My VLV
> > FFRD is still happy.
> 
> Module reload? kexec? hibernation?

Panel orientation, not fb orientation. Apologies for the noise.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.

[Manasi Navare]

On Fri, Oct 19, 2018 at 10:58:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
> > On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> > > On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> > > > If FEC is supported, the corresponding
> > > > DP_TP_CTL register bits have to be configured.
> > > > 
> > > > The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> > > > and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
> > > > Also add the warn message to make sure that the control
> > > > register is already active while enabling FEC.
> > > > 
> > > > v2:
> > > > - Change commit message. Configure fec state after
> > > >   link training (Manasi, Gaurav)
> > > > - Remove redundent checks (Manasi)
> > > > - Remove the registers that get added automagically (Anusha)
> > > > 
> > > > v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
> > > > 
> > > > v4: rebased.
> > > > 
> > > > Cc: Gaurav K Singh 
> > > > Cc: Jani Nikula 
> > > > Cc: Ville Syrjala 
> > > > Cc: Manasi Navare 
> > > > Signed-off-by: Anusha Srivatsa 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
> > > >  drivers/gpu/drm/i915/intel_ddi.c |  2 ++
> > > >  drivers/gpu/drm/i915/intel_dp.c  | 27 +++
> > > >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> > > >  4 files changed, 33 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index bcde78bc0027..c8d7fdcd7823 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -9093,6 +9093,7 @@ enum skl_power_gate {
> > > >  #define _DP_TP_CTL_B   0x64140
> > > >  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
> > > >  #define  DP_TP_CTL_ENABLE  (1 << 31)
> > > > +#define  DP_TP_CTL_FEC_ENABLE  (1 << 30)
> > > >  #define  DP_TP_CTL_MODE_SST(0 << 27)
> > > >  #define  DP_TP_CTL_MODE_MST(1 << 27)
> > > >  #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
> > > > @@ -9111,6 +9112,7 @@ enum skl_power_gate {
> > > >  #define _DP_TP_STATUS_A0x64044
> > > >  #define _DP_TP_STATUS_B0x64144
> > > >  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, 
> > > > _DP_TP_STATUS_B)
> > > > +#define  DP_TP_STATUS_FEC_ENABLE_LIVE  (1 << 28)
> > > >  #define  DP_TP_STATUS_IDLE_DONE(1 << 25)
> > > >  #define  DP_TP_STATUS_ACT_SENT (1 << 24)
> > > >  #define  DP_TP_STATUS_MODE_STATUS_MST  (1 << 23)
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index f531900165bf..67c013ea4d39 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -2911,6 +2911,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > > intel_encoder *encoder,
> > > >   DP_DECOMPRESSION_EN);
> > > > intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
> > > > intel_dp_start_link_train(intel_dp);
> > > > +   intel_dp_enable_fec_state(intel_dp, crtc_state);
> > > 
> > > This doesn't look like the correct spot. According to the spec it
> > > should be after stop_link_train() (where we set DP_TP_CTL to
> > > to normal).
> > >
> > 
> > Yes I see in the display port enabling sequence page of the spec, that it 
> > says enable FEC
> > after DP_TP_CTL is set to Normal. Also the FEC page says that this should 
> > be enabled only after ensuring that link training
> > completed. So according to that this call should happen after
> > intel_dp_stop_link_train(). 
> > So yes move this to after intel_dp_stop_link_training().
> > 
> > > > +
> > > > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > > > intel_dp_stop_link_train(intel_dp);
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index b4e8af3142a2..b9f85502d9ff 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -3017,6 +3017,33 @@ void intel_dp_sink_set_fec_ready(struct intel_dp 
> > > > *intel_dp,
> > > > DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
> > > >  }
> > > >  
> > > > +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
> > > > +  const struct intel_crtc_state 
> > > > *crtc_state)
> > > > +{
> > > > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > > +   struct intel_digital_port *intel_dig_port = 
> > > > dp_to_dig_port(intel_dp);
> > > > +   enum port port = intel_dig_port->base.port;
> > > > +   u32 val;
> > > > +
> > > > +   /* FEC support exists for DP 1.4 only */

Re: [Intel-gfx] [PATCH xf86-video-intel] sna: Switch back to hwcursor on the next cursor update

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 09:08:15PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-10-19 17:55:02)
> > From: Ville Syrjälä 
> > 
> > Once we've switched to using the swcursor (possibly
> > due to the cursor ioctl failing) we currently keep
> > using the swcursor until the modeset.
> > 
> > That's not particularly great as the swcursor has several
> > issues. Apart from the (presumably expected) flicker,
> > the cursor also tends to leave horrible trails behind
> > around dri2/3 windows (happens with tearfree at least).
> > 
> > To avoid some of that let's try to switch back to the hwcursor
> > a bit sooner. We can do that neatly via the convenient swcursor
> > block handler.
> 
> Ok, so that forces the sw cursor to be switched off on the very next
> xf86CursorSetCursor() after being enabled. If the HWCursor fails, the
> cursor should be invisible until the next block handler. Won't that
> cause the cursor to flicker even more? Hmm, except that the swcursor
> should be restored within a frame. So more or less simply doubling the
> work of using swcursor? (Probably not actually, since swcursor is
> effectively an undo and paint every time and now we just make those two
> distinct steps) Certainly achieves the goal of forcing HW cursor back on
> at the earliest opportunity.
> 
> I think I have just argued that this doesn't actually impact on swcursor
> rendering, just extends the loop.

Hmm. I didn't fully consider what happens when we try to switch back.
So first the old swscursor gets cleared out, then we try to turn on
the hwcursor, and if that still fails we eventually render the new
swcursor? Right, so I guess this just adds a bit of a delay between
the two steps.

My intial thought was to use a timer, but then I realized that I
can just stick it into the block handler while still avoiding any
recursion horrors.

> 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=106935
> > Signed-off-by: Ville Syrjälä 
> 
> Tentative
>   Reviewed-by: Chris Wilson 
> I think I would like to review the impact on swcursor a bit more,
> FAIL_CURSOR_IOCTL be my friend.

Sure. Maybe you can even figure out why we get those dirt trails ;)

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: compute_min_voltage_level sort platforms newer-to-older

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 12:03:32PM -0700, Rodrigo Vivi wrote:
> No functional change.
> 
> Just sorting this "if" block from newer to older platform.
> 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 5e8173f28eaa..c49270a266d6 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3373,10 +3373,10 @@ static bool intel_ddi_is_audio_enabled(struct 
> drm_i915_private *dev_priv,
>  void intel_ddi_compute_min_voltage_level(struct drm_i915_private *dev_priv,
>struct intel_crtc_state *crtc_state)
>  {
> - if (IS_CANNONLAKE(dev_priv) && crtc_state->port_clock > 594000)
> - crtc_state->min_voltage_level = 2;
> - else if (IS_ICELAKE(dev_priv) && crtc_state->port_clock > 594000)
> + if (IS_ICELAKE(dev_priv) && crtc_state->port_clock > 594000)
>   crtc_state->min_voltage_level = 1;
> + else if (IS_CANNONLAKE(dev_priv) && crtc_state->port_clock > 594000)
> + crtc_state->min_voltage_level = 2;
>  }
>  
>  void intel_ddi_get_config(struct intel_encoder *encoder,
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: ddi_clock_get sort platforms newer-to-older.

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 12:03:31PM -0700, Rodrigo Vivi wrote:
> No functional change.
> 
> Just sorting this "if" block from newer to older platform.
> 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6b9742baa5f2..5e8173f28eaa 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1737,16 +1737,16 @@ static void intel_ddi_clock_get(struct intel_encoder 
> *encoder,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>  
> - if (INTEL_GEN(dev_priv) <= 8)
> - hsw_ddi_clock_get(encoder, pipe_config);
> + if (IS_ICELAKE(dev_priv))
> + icl_ddi_clock_get(encoder, pipe_config);
> + else if (IS_CANNONLAKE(dev_priv))
> + cnl_ddi_clock_get(encoder, pipe_config);
>   else if (IS_GEN9_BC(dev_priv))
>   skl_ddi_clock_get(encoder, pipe_config);
>   else if (IS_GEN9_LP(dev_priv))
>   bxt_ddi_clock_get(encoder, pipe_config);

These remaining two should get swapped too I think.

> - else if (IS_CANNONLAKE(dev_priv))
> - cnl_ddi_clock_get(encoder, pipe_config);
> - else if (IS_ICELAKE(dev_priv))
> - icl_ddi_clock_get(encoder, pipe_config);
> + else if (INTEL_GEN(dev_priv) <= 8)
> + hsw_ddi_clock_get(encoder, pipe_config);

This whole thing could be a candidate for a vfunc. Though this code
is perhaps misplaced altogether. It should probably be moved next
to the other dpll stuff in intel_dpll_mgr.c.

But anyways
Reviewed-by: Ville Syrjälä 

>  }
>  
>  void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH 3/3] drm/i915: Remove the hardware readout path for DSI panel orientation

[Ville Syrjala]

From: Ville Syrjälä 

Now that we can actually grab the rotation data from the VBT,
maybe we can get rid of the hardware readout path? My VLV
FFRD is still happy.

Cc: Hans de Goede 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/vlv_dsi.c | 42 --
 1 file changed, 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index a3119ec3189a..6f25571b5800 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1668,54 +1668,12 @@ static const struct drm_connector_funcs 
intel_dsi_connector_funcs = {
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
 };
 
-static enum drm_panel_orientation
-vlv_dsi_get_hw_panel_orientation(struct intel_connector *connector)
-{
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_encoder *encoder = connector->encoder;
-   enum intel_display_power_domain power_domain;
-   enum drm_panel_orientation orientation;
-   struct intel_plane *plane;
-   struct intel_crtc *crtc;
-   enum pipe pipe;
-   u32 val;
-
-   if (!encoder->get_hw_state(encoder, ))
-   return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
-
-   crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
-   plane = to_intel_plane(crtc->base.primary);
-
-   power_domain = POWER_DOMAIN_PIPE(pipe);
-   if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
-   return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
-
-   val = I915_READ(DSPCNTR(plane->i9xx_plane));
-
-   if (!(val & DISPLAY_PLANE_ENABLE))
-   orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
-   else if (val & DISPPLANE_ROTATE_180)
-   orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
-   else
-   orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
-
-   intel_display_power_put(dev_priv, power_domain);
-
-   return orientation;
-}
-
 static enum drm_panel_orientation
 intel_dsi_get_panel_orientation(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
enum drm_panel_orientation orientation;
 
-   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   orientation = vlv_dsi_get_hw_panel_orientation(connector);
-   if (orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
-   return orientation;
-   }
-
orientation = dev_priv->vbt.dsi.orientation;
if (orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return orientation;
-- 
2.18.1

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

[Intel-gfx] [PATCH 2/3] drm/i915: Determine DSI panel orientation from VBT

[Ville Syrjala]

From: Ville Syrjälä 

VBT appears to have two (or possibly three) ways to indicate the panel
rotation. The first is in the MIPI config block, but that apparenly
usually (maybe always?) indicates 0 degrees despite the actual panel
orientation. The second way to indicate this is in the general features
block, which can just indicate whether 180 degress rotation is used.
The third might be a separate rotation data block, but that is not
at all documented so who knows what it may contain.

Let's try the first two. We first try the DSI specicic VBT
information, and it it doesn't look trustworthy (ie. indicates
0 degrees) we fall back to the 180 degree thing. Just to avoid too
many changes in one go we shall also keep the hardware readout path
for now.

If this works for more than just my VLV FFRD the question becomes
how many of the panel orientation quirks are now redundant?

Cc: Hans de Goede 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_bios.c | 31 +++
 drivers/gpu/drm/i915/vlv_dsi.c| 11 ++-
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef037fed..115d5963e5a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1102,6 +1102,7 @@ struct intel_vbt_data {
unsigned int panel_type:4;
int lvds_ssc_freq;
unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
+   enum drm_panel_orientation orientation;
 
enum drrs_support_type drrs_type;
 
@@ -1147,6 +1148,7 @@ struct intel_vbt_data {
u8 *data;
const u8 *sequence[MIPI_SEQ_MAX];
u8 *deassert_seq; /* Used by fixup_mipi_sequences() */
+   enum drm_panel_orientation orientation;
} dsi;
 
int crt_ddc_pin;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 1faa494e2bc9..a4bfd92212df 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -420,6 +420,13 @@ parse_general_features(struct drm_i915_private *dev_priv,
intel_bios_ssc_frequency(dev_priv, general->ssc_freq);
dev_priv->vbt.display_clock_mode = general->display_clock_mode;
dev_priv->vbt.fdi_rx_polarity_inverted = 
general->fdi_rx_polarity_inverted;
+   if (bdb->version >= 181) {
+   dev_priv->vbt.orientation = general->rotate_180 ?
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP :
+   DRM_MODE_PANEL_ORIENTATION_NORMAL;
+   } else {
+   dev_priv->vbt.orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+   }
DRM_DEBUG_KMS("BDB_GENERAL_FEATURES int_tv_support %d int_crt_support 
%d lvds_use_ssc %d lvds_ssc_freq %d display_clock_mode %d 
fdi_rx_polarity_inverted %d\n",
  dev_priv->vbt.int_tv_support,
  dev_priv->vbt.int_crt_support,
@@ -852,6 +859,30 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
 
parse_dsi_backlight_ports(dev_priv, bdb->version, port);
 
+   /* FIXME is the 90 vs. 270 correct? */
+   switch (config->rotation) {
+   case ENABLE_ROTATION_0:
+   /*
+* Most (all?) VBTs claim 0 degrees despite having
+* an upside down panel, thus we do not trust this.
+*/
+   dev_priv->vbt.dsi.orientation =
+   DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+   break;
+   case ENABLE_ROTATION_90:
+   dev_priv->vbt.dsi.orientation =
+   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+   break;
+   case ENABLE_ROTATION_180:
+   dev_priv->vbt.dsi.orientation =
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+   break;
+   case ENABLE_ROTATION_270:
+   dev_priv->vbt.dsi.orientation =
+   DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+   break;
+   }
+
/* We have mandatory mipi config blocks. Initialize as generic panel */
dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
 }
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index 893839ea0ff9..a3119ec3189a 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1704,7 +1704,8 @@ vlv_dsi_get_hw_panel_orientation(struct intel_connector 
*connector)
return orientation;
 }
 
-static int intel_dsi_get_panel_orientation(struct intel_connector *connector)
+static enum drm_panel_orientation
+intel_dsi_get_panel_orientation(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
enum drm_panel_orientation orientation;
@@ -1715,6 +1716,14 @@ static int intel_dsi_get_panel_orientation(struct 
intel_connector *connector)
  

[Intel-gfx] [PATCH 1/3] drm/i915: Fix the VLV/CHV DSI panel orientation hw readout

[Ville Syrjala]

From: Ville Syrjälä 

Let's make sure the DSI port is actually on before we go
poking at the plane register to determine which way
it's rotated. Otherwise we could be looking at a plane
that is feeding a HDMI port for instance.

And in order to read the plane register we need the power
well to be on. Make sure that is indeed the case. We'll
also make sure the plane is actually enabled before we
trust the rotation bit to tell us the truth.

Cc: Hans de Goede 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/vlv_dsi.c | 53 ++
 1 file changed, 41 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index dbca30460a6b..893839ea0ff9 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1668,27 +1668,56 @@ static const struct drm_connector_funcs 
intel_dsi_connector_funcs = {
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
 };
 
-static int intel_dsi_get_panel_orientation(struct intel_connector *connector)
+static enum drm_panel_orientation
+vlv_dsi_get_hw_panel_orientation(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
-   enum i9xx_plane_id i9xx_plane;
+   struct intel_encoder *encoder = connector->encoder;
+   enum intel_display_power_domain power_domain;
+   enum drm_panel_orientation orientation;
+   struct intel_plane *plane;
+   struct intel_crtc *crtc;
+   enum pipe pipe;
u32 val;
 
-   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   if (connector->encoder->crtc_mask == BIT(PIPE_B))
-   i9xx_plane = PLANE_B;
-   else
-   i9xx_plane = PLANE_A;
+   if (!encoder->get_hw_state(encoder, ))
+   return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
 
-   val = I915_READ(DSPCNTR(i9xx_plane));
-   if (val & DISPPLANE_ROTATE_180)
-   orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
-   }
+   crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+   plane = to_intel_plane(crtc->base.primary);
+
+   power_domain = POWER_DOMAIN_PIPE(pipe);
+   if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
+   return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+
+   val = I915_READ(DSPCNTR(plane->i9xx_plane));
+
+   if (!(val & DISPLAY_PLANE_ENABLE))
+   orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+   else if (val & DISPPLANE_ROTATE_180)
+   orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+   else
+   orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+
+   intel_display_power_put(dev_priv, power_domain);
 
return orientation;
 }
 
+static int intel_dsi_get_panel_orientation(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   enum drm_panel_orientation orientation;
+
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   orientation = vlv_dsi_get_hw_panel_orientation(connector);
+   if (orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+   return orientation;
+   }
+
+   return DRM_MODE_PANEL_ORIENTATION_NORMAL;
+}
+
 static void intel_dsi_add_properties(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-- 
2.18.1

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

[Intel-gfx] [PATCH 2/3] drm/i915: Prefer direct IS_CANNONLAKE over IS_CNL_WITH_PORT_F

[Rodrigo Vivi]

After all, no Cannonlake has HPD_PORT_F, even the skus with port F.

Also we will only reach this case if PORT_F is already there in
use.

So let's use IS_CANNONLAKE directly here and avoid the ugly check
starting from here.

Cc: Lucas De Marchi 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..927e23cb426c 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -101,7 +101,7 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private 
*dev_priv,
case PORT_E:
return HPD_PORT_E;
case PORT_F:
-   if (IS_CNL_WITH_PORT_F(dev_priv))
+   if (IS_CANNONLAKE(dev_priv))
return HPD_PORT_E;
return HPD_PORT_F;
default:
-- 
2.19.1

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

[Intel-gfx] [PATCH 1/3] drm/i915: Make number of ddi ports explicit.

[Rodrigo Vivi]

Instead of a simple bool that shows if we have ddi ports
or not, let's highlight the number of ddi ports.

So we can use this information to determine the code
path instead of using platforms codenames.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  | 2 +-
 drivers/gpu/drm/i915/i915_pci.c  | 5 +++--
 drivers/gpu/drm/i915/intel_device_info.h | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef037fed..7ad232849268 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2647,7 +2647,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 
 #define HAS_DP_MST(dev_priv)   ((dev_priv)->info.has_dp_mst)
 
-#define HAS_DDI(dev_priv)   ((dev_priv)->info.has_ddi)
+#define HAS_DDI(dev_priv)   ((dev_priv)->info.ddi_ports > 0)
 #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) ((dev_priv)->info.has_fpga_dbg)
 #define HAS_PSR(dev_priv)   ((dev_priv)->info.has_psr)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0a05cc7ace14..0427486f63d0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -363,7 +363,7 @@ static const struct intel_device_info intel_valleyview_info 
= {
 #define G75_FEATURES  \
GEN7_FEATURES, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
-   .has_ddi = 1, \
+   .ddi_ports = 5, \
.has_fpga_dbg = 1, \
.has_psr = 1, \
.has_dp_mst = 1, \
@@ -505,7 +505,7 @@ static const struct intel_device_info 
intel_skylake_gt4_info = {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
.num_pipes = 3, \
.has_64bit_reloc = 1, \
-   .has_ddi = 1, \
+   .ddi_ports = 3, \
.has_fpga_dbg = 1, \
.has_fbc = 1, \
.has_psr = 1, \
@@ -596,6 +596,7 @@ static const struct intel_device_info intel_cannonlake_info 
= {
 #define GEN11_FEATURES \
GEN10_FEATURES, \
GEN(11), \
+   .ddi_ports = 6, \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index af7002640cdf..1be941222ed0 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -90,7 +90,6 @@ enum intel_ppgtt {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_csr); \
-   func(has_ddi); \
func(has_dp_mst); \
func(has_reset_engine); \
func(has_fbc); \
@@ -165,6 +164,7 @@ struct intel_device_info {
 
u32 display_mmio_offset;
 
+   u8 ddi_ports;
u8 num_pipes;
u8 num_sprites[I915_MAX_PIPES];
u8 num_scalers[I915_MAX_PIPES];
-- 
2.19.1

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

[Intel-gfx] [PATCH 3/3] drm/i915: Use the ddi_ports info to kill ugly CNL_WITH_PORT_F.

[Rodrigo Vivi]

Now that we have the number of ddi ports information available
let's use it instead of that ugly platform macro.

v2: - Don't override platform info (Jani) But use platform info (Daniel)
- Don't use ddi_ports when it doesn't make sense (Lucas)
- Add a comment to let clear that port E is fused off. (Rodrigo)

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Lucas De Marchi 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 --
 drivers/gpu/drm/i915/i915_irq.c | 5 ++---
 drivers/gpu/drm/i915/i915_pci.c | 8 
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
 include/drm/i915_pciids.h   | 4 +++-
 6 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ad232849268..99e42df79ed8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2485,8 +2485,6 @@ intel_info(const struct drm_i915_private *dev_priv)
 (dev_priv)->info.gt == 2)
 #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
 (dev_priv)->info.gt == 3)
-#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
-   (INTEL_DEVID(dev_priv) & 0x0004) == 
0x0004)
 
 #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5d1f53723388..63d676de3840 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2782,8 +2782,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
if (INTEL_GEN(dev_priv) >= 11)
tmp_mask |= ICL_AUX_CHANNEL_E;
 
-   if (IS_CNL_WITH_PORT_F(dev_priv) ||
-   INTEL_GEN(dev_priv) >= 11)
+   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
tmp_mask |= CNL_AUX_CHANNEL_F;
 
if (iir & tmp_mask) {
@@ -4220,7 +4219,7 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) >= 11)
de_port_masked |= ICL_AUX_CHANNEL_E;
 
-   if (IS_CNL_WITH_PORT_F(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
de_port_masked |= CNL_AUX_CHANNEL_F;
 
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0427486f63d0..dc78daca145f 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -593,6 +593,13 @@ static const struct intel_device_info 
intel_cannonlake_info = {
.gt = 2,
 };
 
+static const struct intel_device_info intel_cannonlake_portf_info = {
+   GEN10_FEATURES,
+   PLATFORM(INTEL_CANNONLAKE),
+   .gt = 2,
+   .ddi_ports = 6, /* Although port E is fused off, full port F is added */
+};
+
 #define GEN11_FEATURES \
GEN10_FEATURES, \
GEN(11), \
@@ -672,6 +679,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_AML_CFL_GT2_IDS(_coffeelake_gt2_info),
INTEL_WHL_U_GT3_IDS(_coffeelake_gt3_info),
INTEL_CNL_IDS(_cannonlake_info),
+   INTEL_CNL_PORTF_IDS(_cannonlake_portf_info),
INTEL_ICL_11_IDS(_icelake_11_info),
{0, 0, 0}
 };
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3384a9bbdafd..0ea0414ccef4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -402,7 +402,7 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
return 54;
 
/* For this SKU 8.1G is supported in all ports */
-   if (IS_CNL_WITH_PORT_F(dev_priv))
+   if (INTEL_INFO(dev_priv)->ddi_ports == 6)
return 81;
 
/* For other SKUs, max rate on ports A and D is 5.4G */
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 31a49bdcf193..80e14be11279 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3099,7 +3099,7 @@ int intel_power_domains_init(struct drm_i915_private 
*dev_priv)
 * timeouts, lets remove them from the list
 * for the SKUs without port F.
 */
-   if (!IS_CNL_WITH_PORT_F(dev_priv))
+   if (INTEL_INFO(dev_priv)->ddi_ports == 5)
power_domains->power_well_count -= 2;
 
} else if (IS_BROXTON(dev_priv)) {
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 192667144693..486822205151 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -445,7 +445,9 @@
INTEL_VGA_DEVICE(0x5A42, info), \
INTEL_VGA_DEVICE(0x5A4A, info), \
   

Re: [Intel-gfx] [PATCH v5 24/28] drm/i915/dp: Configure Display stream splitter registers during DSC enable

[Manasi Navare]

On Thu, Oct 18, 2018 at 08:02:14PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 05, 2018 at 04:23:02PM -0700, Manasi Navare wrote:
> > Display Stream Splitter registers need to be programmed to enable
> > the joiner if two DSC engines are used and also to enable
> > the left and the right DSC engines. This happens as part of
> > the DSC enabling routine in the source in atomic commit.
> > 
> > v2:
> > * Rebase (Manasi)
> > 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Cc: Anusha Srivatsa 
> > Signed-off-by: Manasi Navare 
> > Reviewed-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/intel_vdsc.c | 22 ++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index f2b3b30b6f5e..d3001647a887 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -1009,6 +1009,12 @@ static void intel_dp_send_dsc_pps_sdp(struct 
> > intel_encoder *encoder,
> >  void intel_dsc_enable(struct intel_encoder *encoder,
> >   struct intel_crtc_state *crtc_state)
> >  {
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   enum pipe pipe = crtc->pipe;
> > +   i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
> > +   u32 dss_ctl1_val = 0;
> > +   u32 dss_ctl2_val = 0;
> >  
> > if (!crtc_state->dsc_params.compression_enable)
> > return;
> > @@ -1017,5 +1023,21 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> >  
> > intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> >  
> > +   /* Configure DSS_CTL registers for DSC */
> > +   if (encoder->type == INTEL_OUTPUT_EDP) {
> 
> Presumably this should check the transcoder instead? I see a lot of
> similar confusion in other patches as well.
>

So that would mean that if we force eDP output on pipe B then it will use 
transcoder B
and hence DSC engines on transcoder B, so we would use the DSS_CTL1/2 only for
Transcoder EDP else it shd use ICL_PIPE_DSS_CTL1(pipe).

And same for the DSC PPS configure patch as well.

Correct?
 
> > +   dss_ctl1_reg = DSS_CTL1;
> > +   dss_ctl2_reg = DSS_CTL2;
> > +   } else {
> > +   dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
> > +   dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
> > +   }
> > +   dss_ctl2_val |= LEFT_BRANCH_VDSC_ENABLE;
> > +   if (crtc_state->dsc_params.dsc_split) {
> > +   dss_ctl2_val |= RIGHT_BRANCH_VDSC_ENABLE;
> > +   dss_ctl1_val |= JOINER_ENABLE;
> > +   }
> > +   I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
> > +   I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
> > +
> > return;
> >  }
> > -- 
> > 2.18.0
> 
> -- 
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Use the ddi_ports info to kill ugly CNL_WITH_PORT_F.

[Rodrigo Vivi]

Now that we have the number of ddi ports information available
let's use it instead of that ugly platform macro.

v2: - Don't override platform info (Jani) But use platform info (Daniel)
- Don't use ddi_ports when it doesn't make sense (Lucas)
- Add a comment to let clear that port E is fused off. (Rodrigo)

v3: - Adding missing case suggested by Lucas to avoid using ddi_ports
when it doesn't make sense.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Lucas De Marchi 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  | 3 +--
 drivers/gpu/drm/i915/i915_irq.c  | 5 ++---
 drivers/gpu/drm/i915/i915_pci.c  | 9 +
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 drivers/gpu/drm/i915/intel_dp.c  | 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c  | 2 +-
 include/drm/i915_pciids.h| 4 +++-
 7 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ad232849268..3e7624de4681 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2485,8 +2485,6 @@ intel_info(const struct drm_i915_private *dev_priv)
 (dev_priv)->info.gt == 2)
 #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
 (dev_priv)->info.gt == 3)
-#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
-   (INTEL_DEVID(dev_priv) & 0x0004) == 
0x0004)
 
 #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
 
@@ -2648,6 +2646,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_DP_MST(dev_priv)   ((dev_priv)->info.has_dp_mst)
 
 #define HAS_DDI(dev_priv)   ((dev_priv)->info.ddi_ports > 0)
+#define HAS_ALL_PORTS_HBR3(dev_priv)((dev_priv)->info.has_all_ports_hbr3)
 #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) ((dev_priv)->info.has_fpga_dbg)
 #define HAS_PSR(dev_priv)   ((dev_priv)->info.has_psr)
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5d1f53723388..63d676de3840 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2782,8 +2782,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
if (INTEL_GEN(dev_priv) >= 11)
tmp_mask |= ICL_AUX_CHANNEL_E;
 
-   if (IS_CNL_WITH_PORT_F(dev_priv) ||
-   INTEL_GEN(dev_priv) >= 11)
+   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
tmp_mask |= CNL_AUX_CHANNEL_F;
 
if (iir & tmp_mask) {
@@ -4220,7 +4219,7 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) >= 11)
de_port_masked |= ICL_AUX_CHANNEL_E;
 
-   if (IS_CNL_WITH_PORT_F(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+   if (INTEL_INFO(dev_priv)->ddi_ports >= 6)
de_port_masked |= CNL_AUX_CHANNEL_F;
 
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0427486f63d0..9d89f7190487 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -593,6 +593,14 @@ static const struct intel_device_info 
intel_cannonlake_info = {
.gt = 2,
 };
 
+static const struct intel_device_info intel_cannonlake_portf_info = {
+   GEN10_FEATURES,
+   PLATFORM(INTEL_CANNONLAKE),
+   .gt = 2,
+   .ddi_ports = 6, /* Although port E is fused off, full port F is added */
+   .has_all_ports_hbr3 = true,
+};
+
 #define GEN11_FEATURES \
GEN10_FEATURES, \
GEN(11), \
@@ -672,6 +680,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_AML_CFL_GT2_IDS(_coffeelake_gt2_info),
INTEL_WHL_U_GT3_IDS(_coffeelake_gt3_info),
INTEL_CNL_IDS(_cannonlake_info),
+   INTEL_CNL_PORTF_IDS(_cannonlake_portf_info),
INTEL_ICL_11_IDS(_icelake_11_info),
{0, 0, 0}
 };
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 1be941222ed0..44e597b7b307 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -89,6 +89,7 @@ enum intel_ppgtt {
func(is_alpha_support); \
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
+   func(has_all_ports_hbr3); \
func(has_csr); \
func(has_dp_mst); \
func(has_reset_engine); \
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3384a9bbdafd..8d9d0b82e459 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -402,7 +402,7 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
return 54;
 
/* For this SKU 8.1G is supported in 

Re: [Intel-gfx] [PATCH 5/5] drm/i915: uncore_fw_domains_init sort platforms newer-to-older

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 12:03:35PM -0700, Rodrigo Vivi wrote:
> No functional change.
> 
> Just sorting this "if" statement from newer to older platform.

Sure. Why not.
Reviewed-by: Ville Syrjälä 

> 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 3ad302c66254..9289515108c3 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1437,7 +1437,7 @@ static void intel_uncore_fw_domains_init(struct 
> drm_i915_private *dev_priv)
>  FORCEWAKE_MEDIA_VEBOX_GEN11(i),
>  FORCEWAKE_ACK_MEDIA_VEBOX_GEN11(i));
>   }
> - } else if (IS_GEN9(dev_priv) || IS_GEN10(dev_priv)) {
> + } else if (IS_GEN10(dev_priv) || IS_GEN9(dev_priv)) {
>   dev_priv->uncore.funcs.force_wake_get =
>   fw_domains_get_with_fallback;
>   dev_priv->uncore.funcs.force_wake_put = fw_domains_put;
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: power_domains_init sort platforms newer-to-older

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 12:03:34PM -0700, Rodrigo Vivi wrote:
> No functional change.
> 
> Just sorting this "if" block from newer to older platform.
> 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 31a49bdcf193..bcc639940c5e 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3084,12 +3084,6 @@ int intel_power_domains_init(struct drm_i915_private 
> *dev_priv)
>*/
>   if (IS_ICELAKE(dev_priv)) {
>   err = set_power_wells(power_domains, icl_power_wells);
> - } else if (IS_HASWELL(dev_priv)) {
> - err = set_power_wells(power_domains, hsw_power_wells);
> - } else if (IS_BROADWELL(dev_priv)) {
> - err = set_power_wells(power_domains, bdw_power_wells);
> - } else if (IS_GEN9_BC(dev_priv)) {
> - err = set_power_wells(power_domains, skl_power_wells);
>   } else if (IS_CANNONLAKE(dev_priv)) {
>   err = set_power_wells(power_domains, cnl_power_wells);
>  
> @@ -3101,15 +3095,20 @@ int intel_power_domains_init(struct drm_i915_private 
> *dev_priv)
>*/
>   if (!IS_CNL_WITH_PORT_F(dev_priv))
>   power_domains->power_well_count -= 2;
> -
> - } else if (IS_BROXTON(dev_priv)) {
> - err = set_power_wells(power_domains, bxt_power_wells);
>   } else if (IS_GEMINILAKE(dev_priv)) {
>   err = set_power_wells(power_domains, glk_power_wells);
> + } else if (IS_GEN9_BC(dev_priv)) {
> + err = set_power_wells(power_domains, skl_power_wells);
> + } else if (IS_BROXTON(dev_priv)) {
> + err = set_power_wells(power_domains, bxt_power_wells);

bxt before skl+ is what my chronometer says

> + } else if (IS_BROADWELL(dev_priv)) {
> + err = set_power_wells(power_domains, bdw_power_wells);
>   } else if (IS_CHERRYVIEW(dev_priv)) {
>   err = set_power_wells(power_domains, chv_power_wells);

and chv before bdw

>   } else if (IS_VALLEYVIEW(dev_priv)) {
>   err = set_power_wells(power_domains, vlv_power_wells);
> + } else if (IS_HASWELL(dev_priv)) {
> + err = set_power_wells(power_domains, hsw_power_wells);

and hsw before vlv ... I think

>   } else if (IS_I830(dev_priv)) {
>   err = set_power_wells(power_domains, i830_power_wells);

Dang! i830 ruins it anyway ;)

Reviewed-by: Ville Syrjälä 

>   } else {
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove the hardware readout path for DSI panel orientation

[Chris Wilson]

Quoting Ville Syrjala (2018-10-19 20:59:48)
> From: Ville Syrjälä 
> 
> Now that we can actually grab the rotation data from the VBT,
> maybe we can get rid of the hardware readout path? My VLV
> FFRD is still happy.

Module reload? kexec? hibernation?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: remove unneeded goto from selftest

[Lucas De Marchi]

On Fri, Oct 19, 2018 at 02:16:57PM -0700, Daniele Ceraolo Spurio wrote:
> commit e346a991f42c ("drm/i915/guc: drop negative doorbell alloc
> selftest") removed the negative case from the selftest and left no
> code between the goto from the positive case of the test and the label
> itself, so we can get rid of it.
> 
> Reported-by: Lucas De Marchi 
> Cc: Lucas De Marchi 
> Cc: Michal Wajdeczko 
> Signed-off-by: Daniele Ceraolo Spurio 

Reviewed-by: Lucas De Marchi 

thanks
Lucas De Marchi

> ---
>  drivers/gpu/drm/i915/selftests/intel_guc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c 
> b/drivers/gpu/drm/i915/selftests/intel_guc.c
> index 464f7d5defad..32cba4cae31a 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_guc.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
> @@ -214,8 +214,6 @@ static int igt_guc_clients(void *args)
>* client it is currently assigned should not cause a failure.
>*/
>   err = create_doorbell(guc->execbuf_client);
> - if (err)
> - goto out;
>  
>  out:
>   /*
> -- 
> 2.19.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: digital_port_connected sort platforms newer-to-older

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 12:03:33PM -0700, Rodrigo Vivi wrote:
> Just sorting this "if" block from newer to older platform.
> 
> The main difference here is the addition of a
> missing case with return false that should never occur.
> And if it occurs it is better than to raise a warn
> than use the icl one.
> 
> The gen >= 11 was already present in the previous logic,
> although hidden.
> 
> So, in summary no real functional change.
> 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3384a9bbdafd..8c38efef77a1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5035,20 +5035,23 @@ bool intel_digital_port_connected(struct 
> intel_encoder *encoder)
>   return g4x_digital_port_connected(encoder);
>   }
>  
> - if (IS_GEN5(dev_priv))
> - return ilk_digital_port_connected(encoder);
> - else if (IS_GEN6(dev_priv))
> - return snb_digital_port_connected(encoder);
> - else if (IS_GEN7(dev_priv))
> - return ivb_digital_port_connected(encoder);
> - else if (IS_GEN8(dev_priv))
> - return bdw_digital_port_connected(encoder);
> + if (INTEL_GEN(dev_priv) >= 11)
> + return icl_digital_port_connected(encoder);
> + else if (IS_GEN10(dev_priv) || IS_GEN9_BC(dev_priv))
> + return spt_digital_port_connected(encoder);
>   else if (IS_GEN9_LP(dev_priv))
>   return bxt_digital_port_connected(encoder);

Tough choice here between skl+/cnl vs. bxt/glk. I guess this
is pretty much as good as the other order.

Reviewed-by: Ville Syrjälä 

Might also be good vfunc territory here. If we made it per-encoder
we could even remove the port A special cases from these. At the
cost of some extra function pointers in our structs.

> - else if (IS_GEN9_BC(dev_priv) || IS_GEN10(dev_priv))
> - return spt_digital_port_connected(encoder);
> - else
> - return icl_digital_port_connected(encoder);
> + else if (IS_GEN8(dev_priv))
> + return bdw_digital_port_connected(encoder);
> + else if (IS_GEN7(dev_priv))
> + return ivb_digital_port_connected(encoder);
> + else if (IS_GEN6(dev_priv))
> + return snb_digital_port_connected(encoder);
> + else if (IS_GEN5(dev_priv))
> + return ilk_digital_port_connected(encoder);
> +
> + MISSING_CASE(INTEL_GEN(dev_priv));
> + return false;
>  }
>  
>  static struct edid *
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/psr: Always wait for idle state when disabling PSR

[Dhinakaran Pandiyan]

On Fri, 2018-10-19 at 13:42 -0700, Dhinakaran Pandiyan wrote:
> On Wednesday, October 10, 2018 5:41:20 PM PDT José Roberto de Souza
> wrote:
> > It should always wait for idle state when disabling PSR because PSR
> > could be inactive due a call to intel_psr_exit() and while PSR is
> > still being disabled asynchronously userspace could change the
> > modeset causing a call to psr_disable() that will not wait for PSR
> > idle and then PSR will be enabled again while PSR is still not
> > idle.
> > 
> > v2: rebased on top of the patch reusing psr_exit()
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 41 ++
> > --
> >  1 file changed, 18 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c index f698b3f45c6d..16d0e3df7de0
> > 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -661,8 +661,12 @@ static void intel_psr_exit(struct
> > drm_i915_private
> > *dev_priv) {
> > u32 val;
> > 
> > -   if (!dev_priv->psr.active)
> > +   if (!dev_priv->psr.active) {
> > +   if (INTEL_GEN(dev_priv) >= 9)
> > +   WARN_ON(I915_READ(EDP_PSR2_CTL) &
> > EDP_PSR2_ENABLE);
> > +   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> 
> Do we really need so many WARN_ONs needing MMIO reads? There are
> almost as 
> many lines of warnings as code in this function. I think at this
> point, we 
> know this code works and the warnings in psr_exit() should be
> removed.
> 
> > return;
> > +   }
> > 
> > if (dev_priv->psr.psr2_enabled) {
> > val = I915_READ(EDP_PSR2_CTL);
> > @@ -680,32 +684,23 @@ static void
> >  intel_psr_disable_source(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +   i915_reg_t psr_status;
> > +   u32 psr_status_mask;
> > 
> > -   if (dev_priv->psr.active) {
> > -   i915_reg_t psr_status;
> > -   u32 psr_status_mask;
> > -
> > -   intel_psr_exit(dev_priv);
> > +   intel_psr_exit(dev_priv);
> > 
> > -   if (dev_priv->psr.psr2_enabled) {
> > -   psr_status = EDP_PSR2_STATUS;
> > -   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> > -   } else {
> > -   psr_status = EDP_PSR_STATUS;
> > -   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> > -   }
> > -
> > -   /* Wait till PSR is idle */
> > -   if (intel_wait_for_register(dev_priv,
> > -   psr_status,
> > psr_status_mask, 0,
> > -   2000))
> > -   DRM_ERROR("Timed out waiting for PSR Idle
> > State\n");
> > +   if (dev_priv->psr.psr2_enabled) {
> > +   psr_status = EDP_PSR2_STATUS;
> > +   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> > } else {
> > -   if (dev_priv->psr.psr2_enabled)
> > -   WARN_ON(I915_READ(EDP_PSR2_CTL) &
> > EDP_PSR2_ENABLE);
> > -   else
> > -   WARN_ON(I915_READ(EDP_PSR_CTL) &
> > EDP_PSR_ENABLE);
> > +   psr_status = EDP_PSR_STATUS;
> > +   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> > }
> > +
> > +   /* Wait till PSR is idle */
> > +   if (intel_wait_for_register(dev_priv, psr_status,
> > psr_status_mask, 0,
> > +   2000))
> > +   DRM_ERROR("Timed out waiting for PSR Idle State\n");
nitpick: Mind writing this as "Timed out waiting PSR idle state\n" if
you end up sending another version without the warnings?


> >  }
> > 
> >  static void intel_psr_disable_locked(struct intel_dp *intel_dp)
> 
> 
> 
> 
> ___
> 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

Re: [Intel-gfx] [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.

[Srivatsa, Anusha]

>-Original Message-
>From: Navare, Manasi D
>Sent: Friday, October 19, 2018 1:29 PM
>To: Ville Syrjälä 
>Cc: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org; Singh, Gaurav K ; Jani
>Nikula 
>Subject: Re: [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.
>
>On Fri, Oct 19, 2018 at 10:58:29PM +0300, Ville Syrjälä wrote:
>> On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
>> > On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
>> > > On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
>> > > > If FEC is supported, the corresponding DP_TP_CTL register bits
>> > > > have to be configured.
>> > > >
>> > > > The driver has to program the FEC_ENABLE in DP_TP_CTL[30]
>> > > > register and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
>> > > > Also add the warn message to make sure that the control register
>> > > > is already active while enabling FEC.
>> > > >
>> > > > v2:
>> > > > - Change commit message. Configure fec state after
>> > > >   link training (Manasi, Gaurav)
>> > > > - Remove redundent checks (Manasi)
>> > > > - Remove the registers that get added automagically (Anusha)
>> > > >
>> > > > v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state()
>> > > > (Gaurav)
>> > > >
>> > > > v4: rebased.
>> > > >
>> > > > Cc: Gaurav K Singh 
>> > > > Cc: Jani Nikula 
>> > > > Cc: Ville Syrjala 
>> > > > Cc: Manasi Navare 
>> > > > Signed-off-by: Anusha Srivatsa 
>> > > > ---
>> > > >  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
>> > > > drivers/gpu/drm/i915/intel_ddi.c |  2 ++
>> > > > drivers/gpu/drm/i915/intel_dp.c  | 27
>> > > > +++  drivers/gpu/drm/i915/intel_drv.h |
>> > > > 3 ++-
>> > > >  4 files changed, 33 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > > > b/drivers/gpu/drm/i915/i915_reg.h index
>> > > > bcde78bc0027..c8d7fdcd7823 100644
>> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > > @@ -9093,6 +9093,7 @@ enum skl_power_gate {
>> > > >  #define _DP_TP_CTL_B  0x64140
>> > > >  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A,
>_DP_TP_CTL_B)
>> > > >  #define  DP_TP_CTL_ENABLE (1 << 31)
>> > > > +#define  DP_TP_CTL_FEC_ENABLE (1 << 30)
>> > > >  #define  DP_TP_CTL_MODE_SST   (0 << 27)
>> > > >  #define  DP_TP_CTL_MODE_MST   (1 << 27)
>> > > >  #define  DP_TP_CTL_FORCE_ACT  (1 << 25)
>> > > > @@ -9111,6 +9112,7 @@ enum skl_power_gate {
>> > > >  #define _DP_TP_STATUS_A   0x64044
>> > > >  #define _DP_TP_STATUS_B   0x64144
>> > > >  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A,
>> > > > _DP_TP_STATUS_B)
>> > > > +#define  DP_TP_STATUS_FEC_ENABLE_LIVE (1 << 28)
>> > > >  #define  DP_TP_STATUS_IDLE_DONE   (1 << 25)
>> > > >  #define  DP_TP_STATUS_ACT_SENT(1 << 24)
>> > > >  #define  DP_TP_STATUS_MODE_STATUS_MST (1 << 23)
>> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> > > > b/drivers/gpu/drm/i915/intel_ddi.c
>> > > > index f531900165bf..67c013ea4d39 100644
>> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
>> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> > > > @@ -2911,6 +2911,8 @@ static void intel_ddi_pre_enable_dp(struct
>intel_encoder *encoder,
>> > > >  DP_DECOMPRESSION_EN);
>> > > >intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
>> > > >intel_dp_start_link_train(intel_dp);
>> > > > +  intel_dp_enable_fec_state(intel_dp, crtc_state);
>> > >
>> > > This doesn't look like the correct spot. According to the spec it
>> > > should be after stop_link_train() (where we set DP_TP_CTL to to
>> > > normal).
>> > >
>> >
>> > Yes I see in the display port enabling sequence page of the spec,
>> > that it says enable FEC after DP_TP_CTL is set to Normal. Also the
>> > FEC page says that this should be enabled only after ensuring that
>> > link training completed. So according to that this call should happen after
>intel_dp_stop_link_train().
>> > So yes move this to after intel_dp_stop_link_training().
>> >
>> > > > +
>> > > >if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>> > > >intel_dp_stop_link_train(intel_dp);
>> > > >
>> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> > > > b/drivers/gpu/drm/i915/intel_dp.c index
>> > > > b4e8af3142a2..b9f85502d9ff 100644
>> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > > > @@ -3017,6 +3017,33 @@ void intel_dp_sink_set_fec_ready(struct
>intel_dp *intel_dp,
>> > > >DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");  }
>> > > >
>> > > > +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
>> > > > + const struct intel_crtc_state 
>> > > > 

[Intel-gfx] [PATCH 5/5] drm/i915: uncore_fw_domains_init sort platforms newer-to-older

[Rodrigo Vivi]

No functional change.

Just sorting this "if" statement from newer to older platform.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_uncore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 3ad302c66254..9289515108c3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1437,7 +1437,7 @@ static void intel_uncore_fw_domains_init(struct 
drm_i915_private *dev_priv)
   FORCEWAKE_MEDIA_VEBOX_GEN11(i),
   FORCEWAKE_ACK_MEDIA_VEBOX_GEN11(i));
}
-   } else if (IS_GEN9(dev_priv) || IS_GEN10(dev_priv)) {
+   } else if (IS_GEN10(dev_priv) || IS_GEN9(dev_priv)) {
dev_priv->uncore.funcs.force_wake_get =
fw_domains_get_with_fallback;
dev_priv->uncore.funcs.force_wake_put = fw_domains_put;
-- 
2.19.1

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

[Intel-gfx] [PATCH 3/5] drm/i915: digital_port_connected sort platforms newer-to-older

[Rodrigo Vivi]

Just sorting this "if" block from newer to older platform.

The main difference here is the addition of a
missing case with return false that should never occur.
And if it occurs it is better than to raise a warn
than use the icl one.

The gen >= 11 was already present in the previous logic,
although hidden.

So, in summary no real functional change.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3384a9bbdafd..8c38efef77a1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5035,20 +5035,23 @@ bool intel_digital_port_connected(struct intel_encoder 
*encoder)
return g4x_digital_port_connected(encoder);
}
 
-   if (IS_GEN5(dev_priv))
-   return ilk_digital_port_connected(encoder);
-   else if (IS_GEN6(dev_priv))
-   return snb_digital_port_connected(encoder);
-   else if (IS_GEN7(dev_priv))
-   return ivb_digital_port_connected(encoder);
-   else if (IS_GEN8(dev_priv))
-   return bdw_digital_port_connected(encoder);
+   if (INTEL_GEN(dev_priv) >= 11)
+   return icl_digital_port_connected(encoder);
+   else if (IS_GEN10(dev_priv) || IS_GEN9_BC(dev_priv))
+   return spt_digital_port_connected(encoder);
else if (IS_GEN9_LP(dev_priv))
return bxt_digital_port_connected(encoder);
-   else if (IS_GEN9_BC(dev_priv) || IS_GEN10(dev_priv))
-   return spt_digital_port_connected(encoder);
-   else
-   return icl_digital_port_connected(encoder);
+   else if (IS_GEN8(dev_priv))
+   return bdw_digital_port_connected(encoder);
+   else if (IS_GEN7(dev_priv))
+   return ivb_digital_port_connected(encoder);
+   else if (IS_GEN6(dev_priv))
+   return snb_digital_port_connected(encoder);
+   else if (IS_GEN5(dev_priv))
+   return ilk_digital_port_connected(encoder);
+
+   MISSING_CASE(INTEL_GEN(dev_priv));
+   return false;
 }
 
 static struct edid *
-- 
2.19.1

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

[Intel-gfx] [PATCH 4/5] drm/i915: power_domains_init sort platforms newer-to-older

[Rodrigo Vivi]

No functional change.

Just sorting this "if" block from newer to older platform.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 31a49bdcf193..bcc639940c5e 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3084,12 +3084,6 @@ int intel_power_domains_init(struct drm_i915_private 
*dev_priv)
 */
if (IS_ICELAKE(dev_priv)) {
err = set_power_wells(power_domains, icl_power_wells);
-   } else if (IS_HASWELL(dev_priv)) {
-   err = set_power_wells(power_domains, hsw_power_wells);
-   } else if (IS_BROADWELL(dev_priv)) {
-   err = set_power_wells(power_domains, bdw_power_wells);
-   } else if (IS_GEN9_BC(dev_priv)) {
-   err = set_power_wells(power_domains, skl_power_wells);
} else if (IS_CANNONLAKE(dev_priv)) {
err = set_power_wells(power_domains, cnl_power_wells);
 
@@ -3101,15 +3095,20 @@ int intel_power_domains_init(struct drm_i915_private 
*dev_priv)
 */
if (!IS_CNL_WITH_PORT_F(dev_priv))
power_domains->power_well_count -= 2;
-
-   } else if (IS_BROXTON(dev_priv)) {
-   err = set_power_wells(power_domains, bxt_power_wells);
} else if (IS_GEMINILAKE(dev_priv)) {
err = set_power_wells(power_domains, glk_power_wells);
+   } else if (IS_GEN9_BC(dev_priv)) {
+   err = set_power_wells(power_domains, skl_power_wells);
+   } else if (IS_BROXTON(dev_priv)) {
+   err = set_power_wells(power_domains, bxt_power_wells);
+   } else if (IS_BROADWELL(dev_priv)) {
+   err = set_power_wells(power_domains, bdw_power_wells);
} else if (IS_CHERRYVIEW(dev_priv)) {
err = set_power_wells(power_domains, chv_power_wells);
} else if (IS_VALLEYVIEW(dev_priv)) {
err = set_power_wells(power_domains, vlv_power_wells);
+   } else if (IS_HASWELL(dev_priv)) {
+   err = set_power_wells(power_domains, hsw_power_wells);
} else if (IS_I830(dev_priv)) {
err = set_power_wells(power_domains, i830_power_wells);
} else {
-- 
2.19.1

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

[Intel-gfx] [PATCH] drm/i915: Consolidate cdclk hooks.

[Rodrigo Vivi]

We don't need 2 different blocks.
Specially with on in ordered older-to-newer and the other
one newer-to-older.

Let's start always using newer-to-older order
when it makes sense.

Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 91 ++
 1 file changed, 42 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 29075c763428..76e69c4f154f 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2777,80 +2777,73 @@ void intel_update_rawclk(struct drm_i915_private 
*dev_priv)
  */
 void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
 {
-   if (IS_CHERRYVIEW(dev_priv)) {
-   dev_priv->display.set_cdclk = chv_set_cdclk;
-   dev_priv->display.modeset_calc_cdclk =
-   vlv_modeset_calc_cdclk;
-   } else if (IS_VALLEYVIEW(dev_priv)) {
-   dev_priv->display.set_cdclk = vlv_set_cdclk;
-   dev_priv->display.modeset_calc_cdclk =
-   vlv_modeset_calc_cdclk;
-   } else if (IS_BROADWELL(dev_priv)) {
-   dev_priv->display.set_cdclk = bdw_set_cdclk;
-   dev_priv->display.modeset_calc_cdclk =
-   bdw_modeset_calc_cdclk;
-   } else if (IS_GEN9_LP(dev_priv)) {
-   dev_priv->display.set_cdclk = bxt_set_cdclk;
-   dev_priv->display.modeset_calc_cdclk =
-   bxt_modeset_calc_cdclk;
-   } else if (IS_GEN9_BC(dev_priv)) {
-   dev_priv->display.set_cdclk = skl_set_cdclk;
-   dev_priv->display.modeset_calc_cdclk =
-   skl_modeset_calc_cdclk;
+   if (IS_ICELAKE(dev_priv)) {
+   dev_priv->display.set_cdclk = icl_set_cdclk;
+   dev_priv->display.modeset_calc_cdclk = icl_modeset_calc_cdclk;
+   dev_priv->display.get_cdclk = icl_get_cdclk;
} else if (IS_CANNONLAKE(dev_priv)) {
dev_priv->display.set_cdclk = cnl_set_cdclk;
dev_priv->display.modeset_calc_cdclk =
cnl_modeset_calc_cdclk;
-   } else if (IS_ICELAKE(dev_priv)) {
-   dev_priv->display.set_cdclk = icl_set_cdclk;
-   dev_priv->display.modeset_calc_cdclk = icl_modeset_calc_cdclk;
-   }
-
-   if (IS_ICELAKE(dev_priv))
-   dev_priv->display.get_cdclk = icl_get_cdclk;
-   else if (IS_CANNONLAKE(dev_priv))
dev_priv->display.get_cdclk = cnl_get_cdclk;
-   else if (IS_GEN9_BC(dev_priv))
+   } else if (IS_GEN9_BC(dev_priv)) {
+   dev_priv->display.set_cdclk = skl_set_cdclk;
+   dev_priv->display.modeset_calc_cdclk =
+   skl_modeset_calc_cdclk;
dev_priv->display.get_cdclk = skl_get_cdclk;
-   else if (IS_GEN9_LP(dev_priv))
+   } else if (IS_GEN9_LP(dev_priv)) {
+   dev_priv->display.set_cdclk = bxt_set_cdclk;
+   dev_priv->display.modeset_calc_cdclk =
+   bxt_modeset_calc_cdclk;
dev_priv->display.get_cdclk = bxt_get_cdclk;
-   else if (IS_BROADWELL(dev_priv))
+   } else if (IS_BROADWELL(dev_priv)) {
+   dev_priv->display.set_cdclk = bdw_set_cdclk;
+   dev_priv->display.modeset_calc_cdclk =
+   bdw_modeset_calc_cdclk;
dev_priv->display.get_cdclk = bdw_get_cdclk;
-   else if (IS_HASWELL(dev_priv))
+   } else if (IS_HASWELL(dev_priv)) {
dev_priv->display.get_cdclk = hsw_get_cdclk;
-   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   } else if (IS_CHERRYVIEW(dev_priv)) {
+   dev_priv->display.set_cdclk = chv_set_cdclk;
+   dev_priv->display.modeset_calc_cdclk =
+   vlv_modeset_calc_cdclk;
dev_priv->display.get_cdclk = vlv_get_cdclk;
-   else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
+   } else if (IS_VALLEYVIEW(dev_priv)) {
+   dev_priv->display.set_cdclk = vlv_set_cdclk;
+   dev_priv->display.modeset_calc_cdclk =
+   vlv_modeset_calc_cdclk;
+   dev_priv->display.get_cdclk = vlv_get_cdclk;
+   } else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
dev_priv->display.get_cdclk = fixed_400mhz_get_cdclk;
-   else if (IS_GEN5(dev_priv))
+   } else if (IS_GEN5(dev_priv)) {
dev_priv->display.get_cdclk = fixed_450mhz_get_cdclk;
-   else if (IS_GM45(dev_priv))
+   } else if (IS_GM45(dev_priv)) {
dev_priv->display.get_cdclk = gm45_get_cdclk;
-   else if (IS_G45(dev_priv))
+   } else if (IS_G45(dev_priv)) {
dev_priv->display.get_cdclk = g33_get_cdclk;
-   else if (IS_I965GM(dev_priv))
+   } else if (IS_I965GM(dev_priv)) {

Re: [Intel-gfx] [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
> On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> > On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> > > If FEC is supported, the corresponding
> > > DP_TP_CTL register bits have to be configured.
> > > 
> > > The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> > > and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
> > > Also add the warn message to make sure that the control
> > > register is already active while enabling FEC.
> > > 
> > > v2:
> > > - Change commit message. Configure fec state after
> > >   link training (Manasi, Gaurav)
> > > - Remove redundent checks (Manasi)
> > > - Remove the registers that get added automagically (Anusha)
> > > 
> > > v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
> > > 
> > > v4: rebased.
> > > 
> > > Cc: Gaurav K Singh 
> > > Cc: Jani Nikula 
> > > Cc: Ville Syrjala 
> > > Cc: Manasi Navare 
> > > Signed-off-by: Anusha Srivatsa 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
> > >  drivers/gpu/drm/i915/intel_ddi.c |  2 ++
> > >  drivers/gpu/drm/i915/intel_dp.c  | 27 +++
> > >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> > >  4 files changed, 33 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index bcde78bc0027..c8d7fdcd7823 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -9093,6 +9093,7 @@ enum skl_power_gate {
> > >  #define _DP_TP_CTL_B 0x64140
> > >  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
> > >  #define  DP_TP_CTL_ENABLE(1 << 31)
> > > +#define  DP_TP_CTL_FEC_ENABLE(1 << 30)
> > >  #define  DP_TP_CTL_MODE_SST  (0 << 27)
> > >  #define  DP_TP_CTL_MODE_MST  (1 << 27)
> > >  #define  DP_TP_CTL_FORCE_ACT (1 << 25)
> > > @@ -9111,6 +9112,7 @@ enum skl_power_gate {
> > >  #define _DP_TP_STATUS_A  0x64044
> > >  #define _DP_TP_STATUS_B  0x64144
> > >  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, 
> > > _DP_TP_STATUS_B)
> > > +#define  DP_TP_STATUS_FEC_ENABLE_LIVE(1 << 28)
> > >  #define  DP_TP_STATUS_IDLE_DONE  (1 << 25)
> > >  #define  DP_TP_STATUS_ACT_SENT   (1 << 24)
> > >  #define  DP_TP_STATUS_MODE_STATUS_MST(1 << 23)
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index f531900165bf..67c013ea4d39 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -2911,6 +2911,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > intel_encoder *encoder,
> > > DP_DECOMPRESSION_EN);
> > >   intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
> > >   intel_dp_start_link_train(intel_dp);
> > > + intel_dp_enable_fec_state(intel_dp, crtc_state);
> > 
> > This doesn't look like the correct spot. According to the spec it
> > should be after stop_link_train() (where we set DP_TP_CTL to
> > to normal).
> >
> 
> Yes I see in the display port enabling sequence page of the spec, that it 
> says enable FEC
> after DP_TP_CTL is set to Normal. Also the FEC page says that this should be 
> enabled only after ensuring that link training
> completed. So according to that this call should happen after
> intel_dp_stop_link_train(). 
> So yes move this to after intel_dp_stop_link_training().
> 
> > > +
> > >   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > >   intel_dp_stop_link_train(intel_dp);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index b4e8af3142a2..b9f85502d9ff 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -3017,6 +3017,33 @@ void intel_dp_sink_set_fec_ready(struct intel_dp 
> > > *intel_dp,
> > >   DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
> > >  }
> > >  
> > > +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
> > > +const struct intel_crtc_state *crtc_state)
> > > +{
> > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > + enum port port = intel_dig_port->base.port;
> > > + u32 val;
> > > +
> > > + /* FEC support exists for DP 1.4 only */
> > > + if (intel_dp_is_edp(intel_dp))
> > > + return;
> > > +
> > > + /* If Display Compression is not enabled, FEC need not be configured */
> > > + if (!crtc_state->dsc_params.compression_enable)
> > > + return;
> > > +
> > > + val = I915_READ(DP_TP_CTL(port));
> > > + val |= DP_TP_CTL_FEC_ENABLE;
> > > + I915_WRITE(DP_TP_CTL(port), val);
> > > 

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

[Dhinakaran Pandiyan]

On Wednesday, October 10, 2018 5:41:19 PM PDT José Roberto de Souza wrote:
> Both functions have the same code to disable PSR, so let's reuse that
> code instead of duplicate.
> 
> Suggested-by: Dhinakaran Pandiyan 
> Cc: Dhinakaran Pandiyan 
Reviewed-by: Dhinakaran Pandiyan 

> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 50 ++--
>  1 file changed, 21 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c index 423cdf84059c..f698b3f45c6d 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -657,6 +657,25 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   mutex_unlock(_priv->psr.lock);
>  }
> 
> +static void intel_psr_exit(struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> +
> + if (!dev_priv->psr.active)
> + return;
> +
> + if (dev_priv->psr.psr2_enabled) {
> + val = I915_READ(EDP_PSR2_CTL);
> + WARN_ON(!(val & EDP_PSR2_ENABLE));
> + I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
> + } else {
> + val = I915_READ(EDP_PSR_CTL);
> + WARN_ON(!(val & EDP_PSR_ENABLE));
> + I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
> + }
> + dev_priv->psr.active = false;
> +}
> +
>  static void
>  intel_psr_disable_source(struct intel_dp *intel_dp)
>  {
> @@ -666,20 +685,14 @@ intel_psr_disable_source(struct intel_dp *intel_dp)
>   i915_reg_t psr_status;
>   u32 psr_status_mask;
> 
> + intel_psr_exit(dev_priv);
> +
>   if (dev_priv->psr.psr2_enabled) {
>   psr_status = EDP_PSR2_STATUS;
>   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> -
> - I915_WRITE(EDP_PSR2_CTL,
> -I915_READ(EDP_PSR2_CTL) &
> -~(EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE));
> -
>   } else {
>   psr_status = EDP_PSR_STATUS;
>   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> -
> - I915_WRITE(EDP_PSR_CTL,
> -I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
>   }
> 
>   /* Wait till PSR is idle */
> @@ -687,8 +700,6 @@ intel_psr_disable_source(struct intel_dp *intel_dp)
>   psr_status, psr_status_mask, 0,
>   2000))
>   DRM_ERROR("Timed out waiting for PSR Idle State\n");
> -
> - dev_priv->psr.active = false;
>   } else {
>   if (dev_priv->psr.psr2_enabled)
>   WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
> @@ -926,25 +937,6 @@ static void intel_psr_work(struct work_struct *work)
>   mutex_unlock(_priv->psr.lock);
>  }
> 
> -static void intel_psr_exit(struct drm_i915_private *dev_priv)
> -{
> - u32 val;
> -
> - if (!dev_priv->psr.active)
> - return;
> -
> - if (dev_priv->psr.psr2_enabled) {
> - val = I915_READ(EDP_PSR2_CTL);
> - WARN_ON(!(val & EDP_PSR2_ENABLE));
> - I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
> - } else {
> - val = I915_READ(EDP_PSR_CTL);
> - WARN_ON(!(val & EDP_PSR_ENABLE));
> - I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
> - }
> - dev_priv->psr.active = false;
> -}
> -
>  /**
>   * intel_psr_invalidate - Invalidade PSR
>   * @dev_priv: i915 device




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

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/psr: Always wait for idle state when disabling PSR

[Dhinakaran Pandiyan]

On Wednesday, October 10, 2018 5:41:20 PM PDT José Roberto de Souza wrote:
> It should always wait for idle state when disabling PSR because PSR
> could be inactive due a call to intel_psr_exit() and while PSR is
> still being disabled asynchronously userspace could change the
> modeset causing a call to psr_disable() that will not wait for PSR
> idle and then PSR will be enabled again while PSR is still not idle.
> 
> v2: rebased on top of the patch reusing psr_exit()
> 
> Cc: Rodrigo Vivi 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 41 ++--
>  1 file changed, 18 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c index f698b3f45c6d..16d0e3df7de0 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -661,8 +661,12 @@ static void intel_psr_exit(struct drm_i915_private
> *dev_priv) {
>   u32 val;
> 
> - if (!dev_priv->psr.active)
> + if (!dev_priv->psr.active) {
> + if (INTEL_GEN(dev_priv) >= 9)
> + WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
> + WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);

Do we really need so many WARN_ONs needing MMIO reads? There are almost as 
many lines of warnings as code in this function. I think at this point, we 
know this code works and the warnings in psr_exit() should be removed.

>   return;
> + }
> 
>   if (dev_priv->psr.psr2_enabled) {
>   val = I915_READ(EDP_PSR2_CTL);
> @@ -680,32 +684,23 @@ static void
>  intel_psr_disable_source(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + i915_reg_t psr_status;
> + u32 psr_status_mask;
> 
> - if (dev_priv->psr.active) {
> - i915_reg_t psr_status;
> - u32 psr_status_mask;
> -
> - intel_psr_exit(dev_priv);
> + intel_psr_exit(dev_priv);
> 
> - if (dev_priv->psr.psr2_enabled) {
> - psr_status = EDP_PSR2_STATUS;
> - psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> - } else {
> - psr_status = EDP_PSR_STATUS;
> - psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> - }
> -
> - /* Wait till PSR is idle */
> - if (intel_wait_for_register(dev_priv,
> - psr_status, psr_status_mask, 0,
> - 2000))
> - DRM_ERROR("Timed out waiting for PSR Idle State\n");
> + if (dev_priv->psr.psr2_enabled) {
> + psr_status = EDP_PSR2_STATUS;
> + psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
>   } else {
> - if (dev_priv->psr.psr2_enabled)
> - WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
> - else
> - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> + psr_status = EDP_PSR_STATUS;
> + psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
>   }
> +
> + /* Wait till PSR is idle */
> + if (intel_wait_for_register(dev_priv, psr_status, psr_status_mask, 0,
> + 2000))
> + DRM_ERROR("Timed out waiting for PSR Idle State\n");
>  }
> 
>  static void intel_psr_disable_locked(struct intel_dp *intel_dp)




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

[Intel-gfx] [PATCH] drm/i915/guc: remove unneeded goto from selftest

[Daniele Ceraolo Spurio]

commit e346a991f42c ("drm/i915/guc: drop negative doorbell alloc
selftest") removed the negative case from the selftest and left no
code between the goto from the positive case of the test and the label
itself, so we can get rid of it.

Reported-by: Lucas De Marchi 
Cc: Lucas De Marchi 
Cc: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/selftests/intel_guc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c 
b/drivers/gpu/drm/i915/selftests/intel_guc.c
index 464f7d5defad..32cba4cae31a 100644
--- a/drivers/gpu/drm/i915/selftests/intel_guc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
@@ -214,8 +214,6 @@ static int igt_guc_clients(void *args)
 * client it is currently assigned should not cause a failure.
 */
err = create_doorbell(guc->execbuf_client);
-   if (err)
-   goto out;
 
 out:
/*
-- 
2.19.0

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

Re: [Intel-gfx] [PATCH] drm/dp: Add definitions for eDP Rev 1.4a and 1.4b

[Manasi Navare]

Thanks for the review.
Pushed to drm-misc

Manasi

On Tue, Oct 09, 2018 at 04:43:51PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 08, 2018 at 05:23:51PM -0700, Manasi Navare wrote:
> > VESA eDP 1.4 specification has separate fields defined in
> > EDP_DPCD_REV for eDP 1.4a and 1.4b eDP revisions.
> > This patch defines those. Found this when one of my eDP panels
> > advertises eDP 1.4a (04h) in the EDP_DPCD_REV DPCD field.
> > 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  include/drm/drm_dp_helper.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 2a3843f248cf..9ad98e8d9ede 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -685,6 +685,8 @@
> >  # define DP_EDP_12 0x01
> >  # define DP_EDP_13 0x02
> >  # define DP_EDP_14 0x03
> > +# define DP_EDP_14a 0x04/* eDP 1.4a */
> > +# define DP_EDP_14b 0x05/* eDP 1.4b */
> 
> The comments seem a bit redundant.
> 
> Either way
> Reviewed-by: Ville Syrjälä 
> 
> >  
> >  #define DP_EDP_GENERAL_CAP_1   0x701
> >  # define DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP  (1 << 0)
> > -- 
> > 2.18.0
> 
> -- 
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/ICL: Add pre_pll_enable hook for ICL and set DFLEXDPMLE in this hook

[Souza, Jose]

On Thu, 2018-10-18 at 15:16 -0700, Manasi Navare wrote:
> In case of Legacy DP connector on TypeC port, the
> flex IO DPMLE register is set to number of lanes configured
> by the display driver which will be programmed into DDI_BUF_CTL
> PORT_WIDTH_SELECTION.
> This needs to be programmed before enabling the shared PLLs hence
> add a pre_pll_enable hook for ICL and add this programming in that
> hook.
> 
> Cc: Lucas De Marchi 
> Cc: Jose Roberto de Souza 
> Cc: Animesh Manna 
> Cc: Paulo Zanoni 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 52
> 
>  1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6b9742baa5f2..fd84f88753cb 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3311,6 +3311,56 @@ static void bxt_ddi_pre_pll_enable(struct
> intel_encoder *encoder,
>   bxt_ddi_phy_set_lane_optim_mask(encoder, mask);
>  }
>  
> +static void intel_ddi_set_fia_lane_count(struct intel_encoder
> *encoder,
> +  const struct intel_crtc_state
> *pipe_config,
> +  enum port port)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(
> >base);
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + u32 val = I915_READ(PORT_TX_DFLEXDPMLE1);
> + bool lane_reversal = (dig_port->tc_type == TC_PORT_TYPEC) ?
> false :
> + dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;

I guess this is more easy to read:
bool lane_reversal = dig_port->tc_type == TC_PORT_TYPEC && dig_port-
>saved_port_bits & DDI_BUF_PORT_REVERSAL;

> +
> + val &= ~DFLEXDPMLE1_DPMLETC_MASK(tc_port);
> + switch (pipe_config->lane_count) {
> + case 1:
> + val |= (lane_reversal) ?
> DFLEXDPMLE1_DPMLETC_ML3(tc_port) :
> + DFLEXDPMLE1_DPMLETC_ML0(tc_port);

For me the DFLEXDPMLE1_DPMLETC_ML0(tc_port); should be align with '('
but if bot said that it is okay...

> + break;
> + case 2:
> + val |= (lane_reversal) ?
> DFLEXDPMLE1_DPMLETC_ML3_2(tc_port) :
> + DFLEXDPMLE1_DPMLETC_ML1_0(tc_port);
> + break;
> + case 4:
> + val |= DFLEXDPMLE1_DPMLETC_ML_3_0(tc_port);
> + break;
> + default:
> + MISSING_CASE(pipe_config->lane_count);
> + }
> + I915_WRITE(PORT_TX_DFLEXDPMLE1, val);
> +}
> +
> +static void icl_ddi_pre_pll_enable(struct intel_encoder *encoder,
> +const struct intel_crtc_state
> *pipe_config,
> +const struct drm_connector_state
> *conn_state)
> +{
> + enum port port = encoder->port;
> + struct intel_digital_port *dig_port = enc_to_dig_port(
> >base);
> +
> + if (intel_port_is_combophy(to_i915(encoder->base.dev), port))
> + return;

Combophy ports will have dig_port->tc_type == TC_PORT_UNKNOWN so you
can drop this.

With this change:
Reviewed-by: José Roberto de Souza 

> +
> + /*
> +  * Program the lane count for static/dynamic connections on
> Type-C ports.
> +  * Skip this step for TBT.
> +  */
> + if (dig_port->tc_type == TC_PORT_TBT)
> + return;
> +
> + intel_ddi_set_fia_lane_count(encoder, pipe_config, port);
> +}
> +
>  void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port =
> dp_to_dig_port(intel_dp);
> @@ -3828,6 +3878,8 @@ void intel_ddi_init(struct drm_i915_private
> *dev_priv, enum port port)
>   intel_encoder->enable = intel_enable_ddi;
>   if (IS_GEN9_LP(dev_priv))
>   intel_encoder->pre_pll_enable = bxt_ddi_pre_pll_enable;
> + if (IS_ICELAKE(dev_priv))
> + intel_encoder->pre_pll_enable = icl_ddi_pre_pll_enable;
>   intel_encoder->pre_enable = intel_ddi_pre_enable;
>   intel_encoder->disable = intel_disable_ddi;
>   intel_encoder->post_disable = intel_ddi_post_disable;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915: Disable PSR when a PSR aux error happen

[Souza, Jose]

On Fri, 2018-10-19 at 16:14 -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> > While PSR is active hardware will do aux transactions by it self to
> > wakeup sink to receive a new frame when necessary. If that
> > transaction is not acked by sink, hardware will trigger this
> > interruption.
> > 
> > So let's disable PSR as it is a hint that there is problem with
> > this
> > sink.
> > 
> > The removed FIXME was asking to manually train the link but we
> > don't
> > need to do that as by spec sink should do a short pulse when it is
> > out of sync with source, we just need to make sure it is awaken and
> > the SDP header with PSR disable will trigger this condition.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_psr.c | 39 
> > 
> >  2 files changed, 36 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 3017ef037fed..e8ba00dd2c51 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -638,6 +638,7 @@ struct i915_psr {
> > u8 sink_sync_latency;
> > ktime_t last_entry_attempt;
> > ktime_t last_exit;
> > +   u32 irq_aux_error;
> >  };
> >  
> >  enum intel_pch {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 70d4e26e17b5..ad09130cb4ad 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -159,10 +159,16 @@ void intel_psr_irq_handler(struct
> > drm_i915_private *dev_priv, u32 psr_iir)
> >BIT(TRANSCODER_C);
> >  
> > for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> > transcoders) {
> > -   /* FIXME: Exit PSR and link train manually when this
> > happens. */
> > -   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > -   DRM_DEBUG_KMS("[transcoder %s] PSR aux
> > error\n",
> > - transcoder_name(cpu_transcoder));
> > +   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> > +   DRM_WARN("[transcoder %s] PSR aux error\n",
> > +transcoder_name(cpu_transcoder));
> Downgrade this to debug since the error is handled in the driver? 

I think is better keep as DRM_WARN so it is shown in regular kernel
logs this way if a user opens a bug complaning why PSR is disabled we
can check that is because of PSR aux error.

> 
> > +
> > +   spin_lock(_priv->irq_lock);
> > +   dev_priv->psr.irq_aux_error |=
> > BIT(cpu_transcoder);
> Just ignore the non eDP bits, I don't think we want to do anything
> with
> the information that some other bit was set.
> 
> > +   spin_unlock(_priv->irq_lock);
> > +
> > +   schedule_work(_priv->psr.work);
> > +   }
> >  
> > if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > dev_priv->psr.last_entry_attempt = time_ns;
> > @@ -893,11 +899,36 @@ int intel_psr_set_debugfs_mode(struct
> > drm_i915_private *dev_priv,
> > return ret;
> >  }
> >  
> > +static void intel_psr_handle_irq(struct drm_i915_private
> > *dev_priv)
> > +{
> > +   struct i915_psr *psr = _priv->psr;
> > +   u32 irq_aux_error;
> > +
> > +   spin_lock_irq(_priv->irq_lock);
> > +   irq_aux_error = psr->irq_aux_error;
> > +   psr->irq_aux_error = 0;
> A subsequent modeset will enable PSR again. I don't expect a modeset
> to
> to be able to fix an AUX wake up failure, so might as well disable it
> for good.

Add another field to do that or set sink_support=false? I guess PSR
short pulses errors should also disable it good too?

> 
> > +   spin_unlock_irq(_priv->irq_lock);
> > +
> > +   /* right now PSR is only enabled in eDP */
> "right now" implies that PSR could be enabled for non eDP ports, but
> that's not the case.
> 
> 
> > +   WARN_ON(irq_aux_error & ~BIT(TRANSCODER_EDP));
> This should go away if you ignore non-EDP bits, and a stack trace
> isn't
> particularly useful anyway.

Okay I will remove this handlings for other transcoders.

> 
> > +
> > +   mutex_lock(>lock);
> Is this sufficient? Don't we have to serialize against ongoing
> modesets
> like we do for debugfs enable/disable. The disable sequence in bspec
> calls out a running pipe and port as pre-requisites.

HW will only send a aux transaction when exiting PSR, in this cases
pipe will always be running:
- exiting because of changes in the screen
- exiting because pipe will be disabled
- exiting because of PSR error

> 
> Ccing Ville and Maarten to get their opinion on this.
>  
> > +
> > +   intel_psr_disable_locked(psr->dp);
> > +   /* let's make sure that sink is awaken */
> > +   drm_dp_dpcd_writeb(>dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D0);
> Given that the hardware initiated AUX 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Fix the macros for DFLEXDPMLE register bits

[Souza, Jose]

On Thu, 2018-10-18 at 15:16 -0700, Manasi Navare wrote:
> This patch fixes the macros used for defining the DFLEXDPMLE
> register bit fields. This accounts for changes in the spec.
> 
> Fixes: a2bc69a1a9d6 ("drm/i915/icl: Add register definition for
> DFLEXDPMLE")
> Cc: Animesh Manna 
> Cc: Paulo Zanoni 

Reviewed-by: José Roberto de Souza 

> Cc: Jose Roberto de Souza 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 81f1c601987d..f5f8a39c4116 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2057,8 +2057,12 @@ enum i915_power_well_id {
>  
>  /* ICL PHY DFLEX registers */
>  #define PORT_TX_DFLEXDPMLE1  _MMIO(0x1638C0)
> -#define   DFLEXDPMLE1_DPMLETC_MASK(n)(0xf << (4 * (n)))
> -#define   DFLEXDPMLE1_DPMLETC(n, x)  ((x) << (4 * (n)))
> +#define   DFLEXDPMLE1_DPMLETC_MASK(tc_port)  (0xf << (4 *
> (tc_port)))
> +#define   DFLEXDPMLE1_DPMLETC_ML0(tc_port)   (1 << (4 * (tc_port)))
> +#define   DFLEXDPMLE1_DPMLETC_ML1_0(tc_port) (3 << (4 * (tc_port)))
> +#define   DFLEXDPMLE1_DPMLETC_ML3(tc_port)   (8 << (4 * (tc_port)))
> +#define   DFLEXDPMLE1_DPMLETC_ML3_2(tc_port) (12 << (4 * (tc_port)))
> +#define   DFLEXDPMLE1_DPMLETC_ML_3_0(tc_port)(15 << (4 *
> (tc_port)))
>  
>  /* BXT PHY Ref registers */
>  #define _PORT_REF_DW3_A  0x16218C
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/psr: Always wait for idle state when disabling PSR

[Souza, Jose]

On Fri, 2018-10-19 at 13:42 -0700, Dhinakaran Pandiyan wrote:
> On Wednesday, October 10, 2018 5:41:20 PM PDT José Roberto de Souza
> wrote:
> > It should always wait for idle state when disabling PSR because PSR
> > could be inactive due a call to intel_psr_exit() and while PSR is
> > still being disabled asynchronously userspace could change the
> > modeset causing a call to psr_disable() that will not wait for PSR
> > idle and then PSR will be enabled again while PSR is still not
> > idle.
> > 
> > v2: rebased on top of the patch reusing psr_exit()
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 41 ++
> > --
> >  1 file changed, 18 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c index f698b3f45c6d..16d0e3df7de0
> > 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -661,8 +661,12 @@ static void intel_psr_exit(struct
> > drm_i915_private
> > *dev_priv) {
> > u32 val;
> > 
> > -   if (!dev_priv->psr.active)
> > +   if (!dev_priv->psr.active) {
> > +   if (INTEL_GEN(dev_priv) >= 9)
> > +   WARN_ON(I915_READ(EDP_PSR2_CTL) &
> > EDP_PSR2_ENABLE);
> > +   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> 
> Do we really need so many WARN_ONs needing MMIO reads? There are
> almost as 
> many lines of warnings as code in this function. I think at this
> point, we 
> know this code works and the warnings in psr_exit() should be
> removed.

I'm just moving what intel_psr_disable_source() had but yes I think we
can remove some WARN_ON() in intel_psr but I guess is better do in
another patch.

> 
> > return;
> > +   }
> > 
> > if (dev_priv->psr.psr2_enabled) {
> > val = I915_READ(EDP_PSR2_CTL);
> > @@ -680,32 +684,23 @@ static void
> >  intel_psr_disable_source(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +   i915_reg_t psr_status;
> > +   u32 psr_status_mask;
> > 
> > -   if (dev_priv->psr.active) {
> > -   i915_reg_t psr_status;
> > -   u32 psr_status_mask;
> > -
> > -   intel_psr_exit(dev_priv);
> > +   intel_psr_exit(dev_priv);
> > 
> > -   if (dev_priv->psr.psr2_enabled) {
> > -   psr_status = EDP_PSR2_STATUS;
> > -   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> > -   } else {
> > -   psr_status = EDP_PSR_STATUS;
> > -   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> > -   }
> > -
> > -   /* Wait till PSR is idle */
> > -   if (intel_wait_for_register(dev_priv,
> > -   psr_status,
> > psr_status_mask, 0,
> > -   2000))
> > -   DRM_ERROR("Timed out waiting for PSR Idle
> > State\n");
> > +   if (dev_priv->psr.psr2_enabled) {
> > +   psr_status = EDP_PSR2_STATUS;
> > +   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> > } else {
> > -   if (dev_priv->psr.psr2_enabled)
> > -   WARN_ON(I915_READ(EDP_PSR2_CTL) &
> > EDP_PSR2_ENABLE);
> > -   else
> > -   WARN_ON(I915_READ(EDP_PSR_CTL) &
> > EDP_PSR_ENABLE);
> > +   psr_status = EDP_PSR_STATUS;
> > +   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> > }
> > +
> > +   /* Wait till PSR is idle */
> > +   if (intel_wait_for_register(dev_priv, psr_status,
> > psr_status_mask, 0,
> > +   2000))
> > +   DRM_ERROR("Timed out waiting for PSR Idle State\n");
> >  }
> > 
> >  static void intel_psr_disable_locked(struct intel_dp *intel_dp)
> 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Check PSR errors instead of retrain while PSR is enabled

[Souza, Jose]

On Fri, 2018-10-19 at 14:02 -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> > When a PSR error happens sink also update the link status values
> > while source do not retrain link as required in the PSR exit
> > sequence.
> > So in the short pulse handling it was returning earlier and doing a
> > full detection and attempting to retrain but it fails because for
> > most sinks the main link is disabled while PSR is active, before
> > even
> > check PSR errors.
> > 
> > Just call intel_psr_short_pulse() before
> > intel_dp_needs_link_retrain() is also not the right fix as
> > intel_dp_needs_link_retrain() would return true and trigger a full
> > detection and trying to retrain link while PSR HW is also doing
> > that.
> > 
> > Check for PSR active is also not safe as it could be inactive due a
> > frontbuffer invalidate and still doing the PSR exit sequence.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  |  7 +++
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  drivers/gpu/drm/i915/intel_psr.c | 15 +++
> >  3 files changed, 23 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 1826d491efd7..2a21a9e29eb2 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4396,6 +4396,13 @@ intel_dp_needs_link_retrain(struct intel_dp
> > *intel_dp)
> > if (!intel_dp->link_trained)
> > return false;
> >  
> > +   /*
> > +* While PSR is enabled, HW will control main-link and retrain
> > when
> > +* exiting PSR
> > +*/
> > +   if (intel_psr_enabled(intel_dp))
> 
> You need a check for !link_standby. The link status is expected to be
> good if we are not turning the link fully off.

Even with link on while PSR is active, sink could lost sync with main
link.

> 
> -DK
> 
> > +   return false;
> > +
> > if (!intel_dp_get_link_status(intel_dp, link_status))
> > return false;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 3dea7a1bda7f..147a116cfc71 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1958,6 +1958,7 @@ void intel_psr_irq_handler(struct
> > drm_i915_private *dev_priv, u32 psr_iir);
> >  void intel_psr_short_pulse(struct intel_dp *intel_dp);
> >  int intel_psr_wait_for_idle(const struct intel_crtc_state
> > *new_crtc_state,
> > u32 *out_value);
> > +bool intel_psr_enabled(struct intel_dp *intel_dp);
> >  
> >  /* intel_runtime_pm.c */
> >  int intel_power_domains_init(struct drm_i915_private *);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index ad09130cb4ad..e4429f2f3034 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -1138,3 +1138,18 @@ void intel_psr_short_pulse(struct intel_dp
> > *intel_dp)
> >  exit:
> > mutex_unlock(>lock);
> >  }
> > +
> > +bool intel_psr_enabled(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +   bool ret;
> > +
> > +   if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
> > +   return false;
> > +
> > +   mutex_lock(_priv->psr.lock);
> > +   ret = (dev_priv->psr.dp == intel_dp && dev_priv->psr.enabled);
> > +   mutex_unlock(_priv->psr.lock);
> > +
> > +   return ret;
> > +}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915: Disable PSR when a PSR aux error happen

[Dhinakaran Pandiyan]

On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> While PSR is active hardware will do aux transactions by it self to
> wakeup sink to receive a new frame when necessary. If that
> transaction is not acked by sink, hardware will trigger this
> interruption.
> 
> So let's disable PSR as it is a hint that there is problem with this
> sink.
> 
> The removed FIXME was asking to manually train the link but we don't
> need to do that as by spec sink should do a short pulse when it is
> out of sync with source, we just need to make sure it is awaken and
> the SDP header with PSR disable will trigger this condition.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 39 
> 
>  2 files changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 3017ef037fed..e8ba00dd2c51 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -638,6 +638,7 @@ struct i915_psr {
>   u8 sink_sync_latency;
>   ktime_t last_entry_attempt;
>   ktime_t last_exit;
> + u32 irq_aux_error;
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 70d4e26e17b5..ad09130cb4ad 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -159,10 +159,16 @@ void intel_psr_irq_handler(struct
> drm_i915_private *dev_priv, u32 psr_iir)
>  BIT(TRANSCODER_C);
>  
>   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> transcoders) {
> - /* FIXME: Exit PSR and link train manually when this
> happens. */
> - if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> - DRM_DEBUG_KMS("[transcoder %s] PSR aux
> error\n",
> -   transcoder_name(cpu_transcoder));
> + if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> + DRM_WARN("[transcoder %s] PSR aux error\n",
> +  transcoder_name(cpu_transcoder));
Downgrade this to debug since the error is handled in the driver? 

> +
> + spin_lock(_priv->irq_lock);
> + dev_priv->psr.irq_aux_error |=
> BIT(cpu_transcoder);
Just ignore the non eDP bits, I don't think we want to do anything with
the information that some other bit was set.

> + spin_unlock(_priv->irq_lock);
> +
> + schedule_work(_priv->psr.work);
> + }
>  
>   if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
>   dev_priv->psr.last_entry_attempt = time_ns;
> @@ -893,11 +899,36 @@ int intel_psr_set_debugfs_mode(struct
> drm_i915_private *dev_priv,
>   return ret;
>  }
>  
> +static void intel_psr_handle_irq(struct drm_i915_private *dev_priv)
> +{
> + struct i915_psr *psr = _priv->psr;
> + u32 irq_aux_error;
> +
> + spin_lock_irq(_priv->irq_lock);
> + irq_aux_error = psr->irq_aux_error;
> + psr->irq_aux_error = 0;
A subsequent modeset will enable PSR again. I don't expect a modeset to
to be able to fix an AUX wake up failure, so might as well disable it
for good.

> + spin_unlock_irq(_priv->irq_lock);
> +
> + /* right now PSR is only enabled in eDP */
"right now" implies that PSR could be enabled for non eDP ports, but
that's not the case.


> + WARN_ON(irq_aux_error & ~BIT(TRANSCODER_EDP));
This should go away if you ignore non-EDP bits, and a stack trace isn't
particularly useful anyway.

> +
> + mutex_lock(>lock);
Is this sufficient? Don't we have to serialize against ongoing modesets
like we do for debugfs enable/disable. The disable sequence in bspec
calls out a running pipe and port as pre-requisites.

Ccing Ville and Maarten to get their opinion on this.
 
> +
> + intel_psr_disable_locked(psr->dp);
> + /* let's make sure that sink is awaken */
> + drm_dp_dpcd_writeb(>dp->aux, DP_SET_POWER,
> DP_SET_POWER_D0);
Given that the hardware initiated AUX write failed, I would recommend
reading back the sink PSR status to make sure disable worked.

> +
> + mutex_unlock(_priv->psr.lock);
> +}
> +
>  static void intel_psr_work(struct work_struct *work)
>  {
>   struct drm_i915_private *dev_priv =
>   container_of(work, typeof(*dev_priv), psr.work);
>  
> + if (READ_ONCE(dev_priv->psr.irq_aux_error))
> + intel_psr_handle_irq(dev_priv);
If psr_work() was already executing and past this check,
schedule_work() in intel_psr_irq_handler will return a failure and
disable PSR would now depend on getting an invalidate and flush
operation. We should disable PSR without any dependency on flush or
invalidate.


> +
>   mutex_lock(_priv->psr.lock);
>  
>   if (!dev_priv->psr.enabled)

___

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Avoid a full port detection in the first eDP short pulse

[Dhinakaran Pandiyan]

On Thu, 2018-10-11 at 16:21 +0300, Ville Syrjälä wrote:
> On Wed, Oct 10, 2018 at 05:41:23PM -0700, José Roberto de Souza
> wrote:
> > Some eDP panels do not set a valid sink count value and even for
> > the
> > ones that sets is should always be one for eDP, that is why it is
> > not
> > cached in intel_edp_init_dpcd().
> > 
> > But intel_dp_short_pulse() compares the old count with the read one
> > if there is a mistmatch a full port detection will be executed,
> > what
> > was happening in the first short pulse interruption of eDP panels
> > that sets sink count.
> > 
> > Instead of just skip the compasison for eDP panels, lets not read
> > the sink count at all for eDP.
> > 
> > v2: the previous version of this patch was caching the sink count
> > in intel_edp_init_dpcd() but I was pointed out by Ville a patch
> > that
> > handled a case of a eDP panel that do not set sink count
> > 
> > Cc: Ville Syrjälä 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 44 +++
> > --
> >  1 file changed, 26 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 13ff89be6ad6..1826d491efd7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4034,8 +4034,6 @@ intel_edp_init_dpcd(struct intel_dp
> > *intel_dp)
> >  static bool
> >  intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >  {
> > -   u8 sink_count;
> > -
> > if (!intel_dp_read_dpcd(intel_dp))
> > return false;
> >  
> > @@ -4045,25 +4043,35 @@ intel_dp_get_dpcd(struct intel_dp
> > *intel_dp)
> > intel_dp_set_common_rates(intel_dp);
> > }
> >  
> > -   if (drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT,
> > _count) <= 0)
> > -   return false;
> > -
> > /*
> > -* Sink count can change between short pulse hpd hence
> > -* a member variable in intel_dp will track any changes
> > -* between short pulse interrupts.
> > +* Some eDP panels do not set a valid value for sink count,
> > that is why
> > +* it don't care about read it here and in
> > intel_edp_init_dpcd().
> 
> Can't quite parse that.
> 
> "Some eDP panels do not set a valid value
>  for sink count, so we ignore it."
> 
> or something like that perhaps.
> 
> >  */
> > -   intel_dp->sink_count = DP_GET_SINK_COUNT(sink_count);
> > +   if (!intel_dp_is_edp(intel_dp)) {
> > +   u8 count;
> > +   ssize_t r;
> >  
> > -   /*
> > -* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies
> > that
> > -* a dongle is present but no display. Unless we require to
> > know
> > -* if a dongle is present or not, we don't need to update
> > -* downstream port information. So, an early return here saves
> > -* time from performing other operations which are not
> > required.
> > -*/
> > -   if (!intel_dp_is_edp(intel_dp) && !intel_dp->sink_count)
> > -   return false;
> > +   r = drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT,
> > );
> > +   if (r < 1)
> > +   return false;
> 
> My earlier suggestion was that we should keep reading this
> anyway because some cts maybe required it. Would at least
> avoid mixing in two functional changes into once patch.

Documenting the outcome of IRC discussion so that we are on the same
page -  CTS does not test eDP, hence it is okay to skip reading sink
count for eDP panels. 



> 
> > +
> > +   /*
> > +* Sink count can change between short pulse hpd hence
> > +* a member variable in intel_dp will track any changes
> > +* between short pulse interrupts.
> > +*/
> > +   intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> > +
> > +   /*
> > +* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1
> > implies that
> > +* a dongle is present but no display. Unless we
> > require to know
> > +* if a dongle is present or not, we don't need to
> > update
> > +* downstream port information. So, an early return
> > here saves
> > +* time from performing other operations which are not
> > required.
> > +*/
> > +   if (!intel_dp->sink_count)
> > +   return false;
> > +   }
> >  
> > if (!drm_dp_is_branch(intel_dp->dpcd))
> > return true; /* native DP sink */
> > -- 
> > 2.19.1
> 
> 

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

Re: [Intel-gfx] [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.

[Ville Syrjälä]

On Fri, Oct 19, 2018 at 01:29:05PM -0700, Manasi Navare wrote:
> On Fri, Oct 19, 2018 at 10:58:29PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
> > > On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> > > > > If FEC is supported, the corresponding
> > > > > DP_TP_CTL register bits have to be configured.
> > > > > 
> > > > > The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> > > > > and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
> > > > > Also add the warn message to make sure that the control
> > > > > register is already active while enabling FEC.
> > > > > 
> > > > > v2:
> > > > > - Change commit message. Configure fec state after
> > > > >   link training (Manasi, Gaurav)
> > > > > - Remove redundent checks (Manasi)
> > > > > - Remove the registers that get added automagically (Anusha)
> > > > > 
> > > > > v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
> > > > > 
> > > > > v4: rebased.
> > > > > 
> > > > > Cc: Gaurav K Singh 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Ville Syrjala 
> > > > > Cc: Manasi Navare 
> > > > > Signed-off-by: Anusha Srivatsa 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
> > > > >  drivers/gpu/drm/i915/intel_ddi.c |  2 ++
> > > > >  drivers/gpu/drm/i915/intel_dp.c  | 27 +++
> > > > >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> > > > >  4 files changed, 33 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > > index bcde78bc0027..c8d7fdcd7823 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > @@ -9093,6 +9093,7 @@ enum skl_power_gate {
> > > > >  #define _DP_TP_CTL_B 0x64140
> > > > >  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
> > > > >  #define  DP_TP_CTL_ENABLE(1 << 31)
> > > > > +#define  DP_TP_CTL_FEC_ENABLE(1 << 30)
> > > > >  #define  DP_TP_CTL_MODE_SST  (0 << 27)
> > > > >  #define  DP_TP_CTL_MODE_MST  (1 << 27)
> > > > >  #define  DP_TP_CTL_FORCE_ACT (1 << 25)
> > > > > @@ -9111,6 +9112,7 @@ enum skl_power_gate {
> > > > >  #define _DP_TP_STATUS_A  0x64044
> > > > >  #define _DP_TP_STATUS_B  0x64144
> > > > >  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, 
> > > > > _DP_TP_STATUS_B)
> > > > > +#define  DP_TP_STATUS_FEC_ENABLE_LIVE(1 << 28)
> > > > >  #define  DP_TP_STATUS_IDLE_DONE  (1 << 25)
> > > > >  #define  DP_TP_STATUS_ACT_SENT   (1 << 24)
> > > > >  #define  DP_TP_STATUS_MODE_STATUS_MST(1 << 23)
> > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > index f531900165bf..67c013ea4d39 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > @@ -2911,6 +2911,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > > > > intel_encoder *encoder,
> > > > > DP_DECOMPRESSION_EN);
> > > > >   intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
> > > > >   intel_dp_start_link_train(intel_dp);
> > > > > + intel_dp_enable_fec_state(intel_dp, crtc_state);
> > > > 
> > > > This doesn't look like the correct spot. According to the spec it
> > > > should be after stop_link_train() (where we set DP_TP_CTL to
> > > > to normal).
> > > >
> > > 
> > > Yes I see in the display port enabling sequence page of the spec, that it 
> > > says enable FEC
> > > after DP_TP_CTL is set to Normal. Also the FEC page says that this should 
> > > be enabled only after ensuring that link training
> > > completed. So according to that this call should happen after
> > > intel_dp_stop_link_train(). 
> > > So yes move this to after intel_dp_stop_link_training().
> > > 
> > > > > +
> > > > >   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > > > >   intel_dp_stop_link_train(intel_dp);
> > > > >  
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index b4e8af3142a2..b9f85502d9ff 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -3017,6 +3017,33 @@ void intel_dp_sink_set_fec_ready(struct 
> > > > > intel_dp *intel_dp,
> > > > >   DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
> > > > >  }
> > > > >  
> > > > > +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
> > > > > +const struct intel_crtc_state 
> > > > > *crtc_state)
> > > > > +{
> > > > > + struct drm_i915_private *dev_priv = 

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/intel_dsi: Read back pclk set by GOP and use that as pclk v2

[Hans de Goede]

Hi,

On 19-10-18 11:20, Jani Nikula wrote:

On Wed, 17 Oct 2018, Hans de Goede  wrote:

On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
different frequency then the pclk which we've calculated.

This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.

This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.


I assume we don't do the fast path because intel_pipe_config_compare()
returns false due to crtc_clock and port_clock mismatch. The dmesg
should tell you the reason with drm.debugs enabled.


As I think I mentioned already last time (but that was a while ago,
so I understand you cannot remember the details), the problem is these
checks from intel_pipe_config_compare():

PIPE_CONF_CHECK_X(dsi_pll.ctrl);
PIPE_CONF_CHECK_X(dsi_pll.div);


Now, the clock checks are already "fuzzy", and should account for slight
variations. I think the goal was the same as here, plus IIUC we may lose
some accuracy on the hardware roundtrip.


The check I quoted above are basically doing a non-fuzzy port_clock check,
we already do a fuzzy port_clock check, so maybe we should just drop them?


Please try adding more tolerance in intel_fuzzy_clock_check() and see if
that helps. The code looks like it allows 5% diff, but it's 2.5%.

Regardless of whether we end up changing the tolerance or adjusting the
state based on the hardware readout or what, I think doing the
adjustment in intel_dsi_vbt.c init is the wrong place. We shouldn't have
anything that depends on accessing the hardware there. I believe that's
what Ville was trying to say in [1].


If you agree with dropping these 2 in essence non-fuzzy port-clock checks:

PIPE_CONF_CHECK_X(dsi_pll.ctrl);
PIPE_CONF_CHECK_X(dsi_pll.div);

Then we won't need this state adjustment.

But in case you do want to keep these, then were should the adjustment be done?

Keep in mind that the pclk is initially calculated in intel_dsi_vbt.c
and then immediately used to calculate a bunch of other settings such as
intel_dsi->lp_byte_clk, prepare_cnt, etc. So there really is no other
place were we can reasonably do this.

Regards,

Hans






BR,
Jani.


[1] http://mid.mail-archive.com/20180706141652.GK5565@intel.com




Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/intel_dsi_vbt.c | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index ac83d6b89ae0..3387b187105c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -506,6 +506,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
+   struct drm_display_mode *curr;
u32 bpp;
u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
u32 ui_num, ui_den;
@@ -583,6 +584,23 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
} else
burst_mode_ratio = 100;
  
+	/*

+* On BYT / CRC the GOP sometimes picks a slightly different pclk,
+* read back the GOP configured pclk and prefer it over ours.
+*/
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   curr = intel_encoder_current_mode(_dsi->base);
+   if (curr) {
+   DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n",
+ pclk, curr->clock);
+   if (curr->clock >= (pclk * 9 / 10) &&
+   curr->clock <= (pclk * 11 / 10))
+   pclk = curr->clock;
+
+   kfree(curr);
+   }
+   }
+
intel_dsi->burst_mode_ratio = burst_mode_ratio;
intel_dsi->pclk = pclk;



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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/intel_dsi: Read back pclk set by GOP and use that as pclk v2

[Daniel Vetter]

On Fri, Oct 19, 2018 at 03:49:15PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 19-10-18 11:20, Jani Nikula wrote:
> > On Wed, 17 Oct 2018, Hans de Goede  wrote:
> > > On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
> > > different frequency then the pclk which we've calculated.
> > > 
> > > This commit makes the DSI code read-back the pclk set by the GOP and
> > > if that is within a reasonable margin of the calculated pclk, uses
> > > that instead.
> > > 
> > > This fixes the first modeset being a full modeset instead of a
> > > fast modeset on systems where the GOP pclk is different.
> > 
> > I assume we don't do the fast path because intel_pipe_config_compare()
> > returns false due to crtc_clock and port_clock mismatch. The dmesg
> > should tell you the reason with drm.debugs enabled.
> 
> As I think I mentioned already last time (but that was a while ago,
> so I understand you cannot remember the details), the problem is these
> checks from intel_pipe_config_compare():
> 
> PIPE_CONF_CHECK_X(dsi_pll.ctrl);
> PIPE_CONF_CHECK_X(dsi_pll.div);
> 
> > Now, the clock checks are already "fuzzy", and should account for slight
> > variations. I think the goal was the same as here, plus IIUC we may lose
> > some accuracy on the hardware roundtrip.
> 
> The check I quoted above are basically doing a non-fuzzy port_clock check,
> we already do a fuzzy port_clock check, so maybe we should just drop them?
> 
> > Please try adding more tolerance in intel_fuzzy_clock_check() and see if
> > that helps. The code looks like it allows 5% diff, but it's 2.5%.
> > 
> > Regardless of whether we end up changing the tolerance or adjusting the
> > state based on the hardware readout or what, I think doing the
> > adjustment in intel_dsi_vbt.c init is the wrong place. We shouldn't have
> > anything that depends on accessing the hardware there. I believe that's
> > what Ville was trying to say in [1].
> 
> If you agree with dropping these 2 in essence non-fuzzy port-clock checks:
> 
> PIPE_CONF_CHECK_X(dsi_pll.ctrl);
> PIPE_CONF_CHECK_X(dsi_pll.div);
> 
> Then we won't need this state adjustment.
> 
> But in case you do want to keep these, then were should the adjustment be 
> done?
> 
> Keep in mind that the pclk is initially calculated in intel_dsi_vbt.c
> and then immediately used to calculate a bunch of other settings such as
> intel_dsi->lp_byte_clk, prepare_cnt, etc. So there really is no other
> place were we can reasonably do this.

We still want to do these checks when validating a modeset afterwards, but
for the fuzzy case we need to cut them out indeed. Similar to what we do
for the some of the other fastboot registers already with the if (!adjust)
condition.

I guess the trick here is making sure we pick the right set of registers
... Maybe we want to make all the pll low-level state like that (so both
dsi_pll and dpll_hw_state)?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/1] drm/i915: Avoid initializing framebuffer without pipes

[Mika Kuoppala]

If we try to initialize a framebuffer without pipes, we get oops
as we fail to get valid crtc for a PIPE A, on trying to find
pitch limits. This is easily demonstrated by trying to init
framebuffer with displays disabled by 'i915.disable_display=1'
kernel cmdline.

Fix this by omitting framebuffer init early if there are no pipes.

Testcase: igt/kms_addfb_basic
Cc: Ville Syrjala 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fc7e3b0bd95c..c1685395c67c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14312,6 +14312,9 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
stride = i915_gem_object_get_stride(obj);
i915_gem_object_unlock(obj);
 
+   if (INTEL_INFO(dev_priv)->num_pipes == 0)
+   goto err;
+
if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
/*
 * If there's a fence, enforce that
-- 
2.17.1

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

Re: [Intel-gfx] [PULL] drm-intel-next-fixes

[Daniel Vetter]

On Fri, Oct 19, 2018 at 12:38 PM Joonas Lahtinen
 wrote:
>
> Hi Dave,
>
> Here are the promised MST fixes that were missing due to being
> in i915 tree, yet outside i915 directory.
>
> Further explanation in the previous PR's thread.

fwiw, lgtm.

Cheers, Daniel
>
> Regards, Joonas
>
> ***
>
> drm-intel-next-fixes-2018-10-19:
> - The missing 4 MST patches that tooling didn't pick from drm core/nouveau
> The following changes since commit f2bfc71aee75feff33ca659322b72ffeed5a243d:
>
>   Merge tag 'drm-intel-next-fixes-2018-10-18' of 
> git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-10-19 
> 14:28:11 +1000)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-intel 
> tags/drm-intel-next-fixes-2018-10-19
>
> for you to fetch changes up to 7b0f61e91b6056c71649efa3204112a4b6cf5fc8:
>
>   drm/nouveau: Fix nv50_mstc->best_encoder() (2018-10-19 11:46:46 +0300)
>
> 
> - The missing 4 MST patches that tooling didn't pick from drm core/nouveau
>
> 
> Lyude Paul (4):
>   drm/atomic_helper: Disallow new modesets on unregistered connectors
>   drm/atomic_helper: Allow DPMS On<->Off changes for unregistered 
> connectors
>   drm/atomic_helper: Stop modesets on unregistered connectors harder
>   drm/nouveau: Fix nv50_mstc->best_encoder()
>
>  drivers/gpu/drm/drm_atomic_helper.c | 21 +-
>  drivers/gpu/drm/drm_connector.c | 11 ++---
>  drivers/gpu/drm/i915/intel_dp_mst.c |  8 ++--
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 14 ++-
>  include/drm/drm_connector.h | 71 
> -
>  5 files changed, 103 insertions(+), 22 deletions(-)



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-fixes

[Maarten Lankhorst]

Hey Dave,

The GPF issue was serious enough to send a second pull request for 
drm-misc-fixes. :)

Cheers,
~Maarten

drm-misc-fixes-2018-10-19:
Second pull request for v4.19:
- Fix ulong overflow in sun4i
- Fix a serious GPF in waiting for flip_done from commit_tail().

The following changes since commit 9068e02f58740778d8270840657f1e250a2cc60f:

  drm/edid: VSDB yCBCr420 Deep Color mode bit definitions (2018-10-16 16:38:16 
+0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-10-19

for you to fetch changes up to e84cb605e02f1b3d0aee8d7157419cd8aaa06038:

  drm/sun4i: Fix an ulong overflow in the dotclock driver (2018-10-19 11:50:25 
+0200)


Second pull request for v4.19:
- Fix ulong overflow in sun4i
- Fix a serious GPF in waiting for flip_done from commit_tail().


Boris Brezillon (1):
  drm/sun4i: Fix an ulong overflow in the dotclock driver

Leo Li (1):
  drm: Get ref on CRTC commit object when waiting for flip_done

 drivers/gpu/drm/drm_atomic.c   |  5 +
 drivers/gpu/drm/drm_atomic_helper.c| 12 
 drivers/gpu/drm/sun4i/sun4i_dotclock.c | 12 +++-
 include/drm/drm_atomic.h   | 11 +++
 4 files changed, 35 insertions(+), 5 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add ppgtt to GVT GEM context

[Chris Wilson]

Quoting Xiong Zhang (2018-10-18 06:40:31)
> Currently the guest couldn't boot up under GVT-g environment as the
> following call trace exists:
> [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 
> 0100
> [  272.504834] Call Trace:
> [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> 
> GVT GEM context is created by i915_gem_context_create_gvt() which
> doesn't allocate ppgtt. So GVT GEM context structure doesn't have
> a valid i915_hw_ppgtt.
> 
> This patch create ppgtt table at GVT GEM context creation, then assign
> shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
> be used on GPU. So GVT GEM context has valid ppgtt address. But note
> that this ppgtt only contain valid ppgtt root table address, the table
> entry in this ppgtt structure are invalid.
> 
> Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for 
> execlists")
> 
> Signed-off-by: Xiong Zhang 
> Reviewed-by: Zhenyu Wang 

And pushed. Thanks very much for the fixup,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx